1. 개념 pod 생성 시 이미지를 public docker hub가 아닌 자체적으로 구성한 private docker registry에서 다운받도록 구성 가능 이때 private docker registry 접근 시 로그인 정보는 docker-registry 타입 secret의 imagePullSecrets 인자값으로 전달 2. 참고 https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell
1. 개념 Dockerfile을 작성할 때 RUN, COPY, ADD 명령은 레이어를 추가해 용량을 증가시키므로 최대한 지양하는 것이 좋음 도커 컨테이너의 보안을 위해서 다음의 사항을 유념하면서 Dockerfile을 작성해야 함 패키지 버전 명시 root로 실행 금지 파일시스템 read only 설정 shell 접근 삭제 구체적인 내용은 공식 문서 참고(Overview of best practices for writing Dockerfiles) 2. 실습 Dockerfile BP에 따른 예시 FROM ubuntu:20.04 # 패키지 버전 지정 RUN chmod a-w /etc RUN add group -S tmpgroup & adduser -S tmpuser -F appgroup -h /home/tmp..
1. 개념 Admission Control 단계에서 사용하는 정책 강제 도구 오픈소스 정책 적용 엔진으로서 K8s에서만 사용할 수 있는 것은 아님 OPA 정책을 K8s가 해석할 수 있도록 CRDs로 정의(ConstraintTemplate)하고, 실제 정책 실행 대상 및 조건은 Constraint에 정의 2. OPA 정책 예시 - 모든 파드 생성 차단 # ConstraintTemplate apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: k8salwaysdeny spec: crd: spec: names: kind: K8sAlwaysDeny validation: # Schema for the `paramet..
1. 개념 SecurityContext를 통해 Pod 혹은 Container의 보안 설정을 적용할 수 있음 Pod 수준의 통제와 Container 수준의 통제를 별개로 설정 가능하지만, capabilities 설정은 Container 수준에서만 설정 가능 SecurityContext로 설정할 수 있는 옵션은 공식 문서를 참고 2. 주요 옵션 privileged host OS의 root와 동일한 권한을 허용 기본 설정은 false allowPrivilegeEscalation 부모 프로세스보다 더 많은 권한을 얻도록 허용 Privileged == true or CAP_SYS_ADMIN 권한을 보유한 경우 항상 true capabilities 컨테이너에 사용 가능 / 불가능한 POSIX capabilities..
1. 개념하이퍼바이저를 활용해 가상화를 구현한 VM과 달리 컨테이너는 Host OS를 공유하는 형태이므로 컨테이너의 시스템콜이 Host OS로 요청됨이러한 escaping을 통제하기 위해 샌드박싱 기법을 활용하게 되는데 seccomp, apparmor를 적용하는 것은 현실적으로 불가능(각 애플리케이션별로 허용 가능한 syscall을 판별하고 허용해줘야 해서)2. gVisor이러한 문제의 현실적 대안으로서 gVisor 활용gVisor는 컨테이너를 위한 애플리케이션 커널 역할을 수행하면서 Application(Container)의 System Call Layer 역할을 수행함으로서 Application과 Host OS의 Kernel을 분리 gVisor는 Sentry와 Gofer로 구성 SentryApplic..
1. 개념 Secert 리소스는 이름과 다르게 값을 base64로 인코딩해 저장한다. 따라서 secret 값을 secret, 컨테이너 런타임, etcdctl 등에서 평문으로 확인할 수 있다. 이러한 특성으로 인해 ETCD를 반드시 암호화해야 하고 혹은 Vault와 같은 3rd-Party 오픈소스를 사용해 크레덴셜을 저장해야 한다. ETCD 암호화에 관한 자세한 방법은 공식 문서에 잘 설명되어 있다. 2. 실습 암호키 생성 head -c 32 /dev/urandom | base64 EncryptionConfiguration 작성 apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secre..
1. 개념 클러스터의 오브젝트 및 서비스에 접근하기 위해 유저에 대한 인증/인가를 위해 인증서를 사용 인증서를 생성하기 위한 작업의 일환으로 유저의 개인키에 대한 사이닝을 K8s의 CA에 요청할때 CertificateSigningRequests API를 사용 인증서를 사이닝하는 방법에는 매뉴얼힌 방법과 API를 활용하는 방식이 존재 대략적인 프로세스는 다음과 같음 2. 실습(CertificateSigningRequests API 활용) key 생성 openssl genrsa -out [name].key 2048 CSR 생성(Common Name에 유저 이름 입력) openssl req -new -key [name].key -out [name].csr CertificateSigningRequest 생성 및..
1. 개념 모든 네임스페이스에는 default SA가 존재 파드 생성 시 SA를 지정하지 않은 경우 default SA가 자동으로 설정 custom SA를 생성할 수 있고, custom SA 파드에 지정한 후 컨테이너 내부에서 토큰 값도 확인 가능 2. ServiceAccount 보안 automountServiceAccountToken: false 옵션을 pod 또는 SA에 추가하면 토큰이 자동으로 pod에 마운트되는 것을 방지할 수 있음 default SA의 권한을 제거 또는 최소화하고 이를 사용하는 것이 가장 좋다 SA 사용이 필요한 경우 custom SA를 생성하고 최소권한으로 ClusterRole 또는 Role 할당하여 사용 K8s 1.24 버전부터 SA 생성 후 토큰을 별도로 생성해야 함(이전에..
1. 개념 RBAC을 다양하게 조합해 리소스에 대한 권한 제어 가능 RBAC의 적용 범위는 네임스페이스 단위(role) vs 클러스터 단위(cluster role)로 나뉨 2. Role 조합 role / clusterRole / roleBinding / clusterRoleBinding 조합 가능 role + roleBinding = 유저 X에게 하나의 NS의 권한을 할당 clusterRole + clusterRoleBinding = 유저X에게 모든 NS의 권한을 할당 clusterRole + roleBinding = 유저 X에게 두 개 이상의 NS의 권한을 할당 3. 우선순위 role의 중첩이 발생하는 경우 additive한 RBAC의 특성으로 인해 아래와 같은 상황에서 유저 X는 get, delete..
1. 소개 K8s 클러스터와 Pod의 이미지에 대한 취약점을 점검하는 다양한 오픈소스가 존재 대표적인 몇 가지를 소개 kube-bench trivy kubesec 2. kube-bench 공식 레포 CIS 벤치마크를 기반으로 클러스터의 취약점을 점검 3. trivy 공식 레포 클러스터 및 pod 이미지에 대한 취약점을 점검 4. kubesec 공식 홈페이지 스코어링 기반으로 yaml 내용의 취약점을 점검 5. 참고 https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell
