전공공부

File System /var/lib/docker 폴더에 모두 이미지든 도커 파일들이 쌓입니다. 그리고, Layer 구조로 저장이 되는데요. Dockerfile을 열어서 보면 이미 Ubuntu image가 설치 되었다고 치면 이미 마주치면서 있는 계층의 것들을 다운로드하지 않습니다. 필요한 부분만 변경해서 업데이트가 될 뿐이죠. 그리고, 이러한 Dockerfile의 처리들은 Image Layer로 처리가 되고 이를 컨테이너 레이어를 만들고 글을 쓸 수 있는 레이러를 하나 더 올려서 처리 할 수 있습니다. Container Layer가 RW를하죠. 이해하기 쉽게 예제를 들겠습니다 docker build Dockerfile -t username/custom-app #이미지 레이어 생성 위 명령어로 이미지 레..

Traffic (Ingress)Web -> :80 -> API :5000 -> DB :3306 API -> Web (Egress) Ingress Role : 웹 서버로 부터 들어오는 요청 Driving Egress Role : DB 응답 웹 서버로 들어온 요청의 응답 Driven Network Security 쿠버 네티스는 기본적으로 All Allowed 됩니다. 클러스터 내부 Pod 간 통신이든 뭐든요. 그래서 우리는 Web -> API -> DB 이런것이 바로 가능한 이유가 이런 이유인데요 만일, Web -> DB는 막고 싶다면 어떻게 해야 할까요? Netwok Policy를 이때 적용 합니다. Network Policy - Rules Allow Ingress Traffic From API Pod o..

Docker Security docker run ubuntu sleep 3600 Container는 Namespace 단위로 격리되고 실행된다. 그래서, 프로세서에 직접 접근해서 들어가서 ps aux 하면 PID는 1이 나올 것이고 이에 대해서 Host 범위에서 ps aux 시 그저 실행되는 하나의 컨테이너 작업으로 표시되어서 PID 31157 이런식으로 랜덤 ID가 나올 것이다. 어쨌든 말하고 싶은 것은 host의 일반 유저와 Container의 접근 권한이 다르다는걸 말하고 싶었다. docker run --privileged ubuntu 그래서, 이렇게 유저가 달라서 일반 Docker 유저는 권한을 모두 부여 받지 못한다. 따라서, 특정 명령어를 쓰기 위해서는 위와 같이 root 권한을 부여한다던지 ..

Image image는 무엇이고 이미지는 어디서 나온 것일까요? 이미지는 도커로 부터 온 것이고 library/nginx 이 사실 nginx image로 저장되는 건데 보통 유저 계정 이름이 없이 라이브러리 형태로 바로 따라오는 이미지 형태는 도커에서 공식으로 지원하기 때문에 image: nginx 처럼 쓸 수 있었습니다. 보통의 도커 패스는 이렇습니다. // Private Repository 자 그럼 도커 허브에서 내 프라이빗 레지스트리에 등록한 도커 이미지를 가져 올 수 있겠네요. docker login private-registry.io docker run private-registry.io/apps/internal-app 위와 같이 내 프라이빗 레지스트리로 부터 가져온 도커 이미지를 쓸 수 있습니..

정확하지는 않으나 ServiceAccount는 token을 생성하고 생성된 토큰 정보를 이용해서 각 pod에 도달 할 수 있는 역할을 수행한다. 예를 들어서 ca.crt 등 요청으로 curl 날려서 API 요청을 일일이 했던 것을 serviceaccount를 이용해서 연결을 하는데 ServiceAccounts만들고 k create token SECRET_ACCOUNT_NAME 을 하면 해당 정보로 도달 할 수 있는 토큰을 주고 이를 사용하여도 되고 아니면 아래와 같이 RoleBinding에 설정해서 접근 권한의 대한 허가를 주고 이때에 Deployments에도 해당 ServiceAccount로 접근 가능하게 설정을 하면 된다. apiVersion: v1 kind: Pod metadata: name: my..

이전 내용에서는 사용자를 네임스페이스 리소스(Pod,Deployments,...)에 인증하는 방법을 알아보았습니다. 우리는 그것에 Roles 및 RoleBindings을 사용했구요. 그러나, 사용자에게 Node 또는 PV와 같은 클러스터 범위의 리소스에 권한을 부여하려면 어떻게 해야 할까요? 해결법은 Cluster Roles 및 Cluster Role Bindings을 쓰면 됩니다. 클러스터 롤 (Cluster Roles) 클러스터 롤은 롤과 매우 유사하지만 클러스터 범위의 리소스를 위한 것입니다. 예를 들어 클러스터 관리자 롤을 만들어 클러스터 관리자에게 클러스터 내의 노드를 보거나 만들거나 삭제할 수 있는 권한을 부여할 수 있습니다. 마찬가지로 스토리지 관리자 롤을 만들어 스토리지 관리자에게 PV, ..

우리는 전에 ABAC 방식이나 Node 방식등을 알아 봤습니다. 그때, 저희는 Role에 따라서 주는것이 좋은 걸 알았죠. 그리고, core 그룹과 named API 그룹에 대해서 알아봤습니다. 아래와 같이 설정을 하고 Role을 아래와 같이 만들 수 있습니다. 이때, 이렇게 만들어지면 pods 리소스에 대해서는 get 요청 및 list,create,update,delete의 요청이 가능합니다. 또한, 이후에 아래 명령어로 Role 개채 생성 한 후 Role을 각 유저에 바인딩 해줍시다. RoleBinding apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: developer rules: - apiG..

쿠버네티스에서 권한 부여는 어떻게 이루어 질 수 있는지 알아봅시다. ABAC - 특성 베이스 각 특성에 맞는 권한을 일일이 부여해야 하고 이는 Kube API 서버를 다시 시작하게 끔한다. 그런데 이는 매우 비효율적인 방법이다. 개발자 한 명이 추가 될 때마다 그에 맞는 특성을 개발자 1에게 모두 직접 부여하고 API SERVER를 껐다 키는게 정상은 아니니 말이다. RBAC - Rule 베이스 개발자는 개발자 권한을 부여한다. 보안 담당자는 보안 담당 권한을 부여한다. 즉, 자신의 권한에 맞는 권한 부여 셋팅을 미리 내려주고 이는 API SERVER가 읽어서 바로 적용 될 수 있게 한다. 일반적인 방법이다. Authorization Mode 인증에는 모드가 존재한다. 아래는 모드의 종류임 NODE는 노..