악분의 블로그

EKS란? EKS는 AWS Managed Kubernetes입니다. AWS가 쿠버네티스 클러스터를 생성하고 수정, 삭제를 전부 담당하므로 “Managed”라는 키워드가 있습니다. 사용자는 비용을 지불하고 비지니스 로직을 쿠버네티스로 어떻게 관리할까만 고민하면 됩니다. 쿠버네티스만 아는 사람이 바라보는 EKS 쿠버네티스를 직접 설치하는 것과 EKS를 사용하는 것은 2가지 차이가 있습니다. 쿠버네티스가 AWS환경에서 실행된다. control-plane은 AWS가 직접 관리한다. AWS에 쿠버네티스에 동작하기 때문에 쿠버네티스는 AWS리소스가 활용됩니다. 워커노드는 EC2 Instance 또는 Fargate를 사용하고 네트워크는 VPC영향을 받습니다. LoadBalancer타입 서비스를 생성하면 AWS ELB..

5주차 여섯번째 주제는 pod securityContext.allowPrivilegeEscalation입니다. allowPrivilegeEscalation이란? allowPrivilegeEscalation은 컨테이너가 실행 된 후, 컨테이너 유저 권한보다 높은 권한을 제어합니다. 공식문서 allowPrivilegeEscalation설명을 보면 부모 프로세스보다 높은 권한을 얻는 것을 제어한다고 되어 있습니다. 컨테이너에서 부모(최초) 프로세스는 entrypoint로 실행된 프로세스입니다. entrypoint는 Dockerfile에서 USER로 설정된 사용자로 실행됩니다. 결국, 컨테이너 유저보다 높은 권한을 제어한다는 의미와 같습니다. 예제 예제는 allowPrivilegeEscalation를 false..

5주차 다섯번째 주제는 pod securityContext.capability입니다. readOnlyRootFilesystem이란? 쿠버네티스 컨테이너 내부 파일을 수정하지 못하게 하려면 어떻게 해야할까요? 파일 읽기권한만 설정하면 됩니다. 쿠버네티스에서 파일읽기권한만 설정하는 것을 readOnlyRootFilesystem이라고 합니다. securitycontext.readOnlyRootFilesystem필드에 bool값으로 설정할 수 있습니다. apiVersion: v1 kind: Pod metadata: name: rootfile-readonly spec: containers: - name: busybox image: busybox command: ["tail"] args: ["-f", "/dev/n..

5주차 네번째 주제는 pod securityContext.capability입니다. Linux capability 리눅스는 capability라는 기능으로 커널권한을 분리합니다. 리눅스 초창기에는 root계정이 모든 권한이 있었고 커널 2.2부터 capability로 커널권한을 분리했습니다. 그래서 root계정이라도 capability설정이 없다면 작업이 제한됩니다. capability에 대한 자세한 내용은 man명령어로 볼 수 있습니다. man capabilities capability는 계정과 프로세스에 설정됩니다. 계정은 capsh명령어로 확인할 수 있습니다. capsh --print 프로세스 capability는 프로세스 정보에서 비트마스크로 표현됩니다. cat /proc/1/status | eg..

5주차 세번째 주제는 pod securityContext.privileged입니다. 사전지식 컨테이너는 프로세스로서 노드 커널 위에 실행됩니다. 그러므로 컨테이너가 커널에 접근할 수 있습니다. 쿠버네티스와 같은 컨테이너 오케스트레이션 도구는 pod가 노드 커널에 접근하지 못하도록 보안설정을 합니다. privileged란? 부득이하게 pod가 커널 접근이 꼭 필요한 상황이 있습니다. 네트워크 설정을 해야 하는 Calico CNI가 대표적인 예입니다. 이런 상황을 대비하여 쿠버네티스는 pod가 커널에 접근할 수 있는 설정을 제공합니다. 그 설정이 바로 securityContext.privileged입니다. spec.containers.securityContext.privileged를 true로 설정하면 po..

5주차에서는 두 번째 주제는 pod에서 EC2 인스턴스 메타데이터를 사용가능하면 어떤 위험이 있는지 설명합니다. 사전지식 이 글은 EC2 인스턴스 메타데이터를 알고있다는 전제로 설명합니다. 제 블로그 이전 글에 인스턴스 메타데이터에 정리했습니다. 노드에서 인스턴스 메타데이터 조회하도록 설정 스터디에서 생성한 kops클러스터 기본 설정으로는 IMDS API호출이 불가능합니다. 그러므로 인스턴스 메타데이터도 조회하지 못합니다. 토큰을 발급하더라도 호출을 실패합니다. IMDS API호출이 실패하는 이유는 httpPutResponseHopLimit설정이 1로 설정되어 있기 때문입니다. 네트워크 hop수만큼 httpPutResponseHopLimit를 설정해야하는데 기본으로 1로 설정되어 있습니다. 검증을 위해 ..