1. 개념 하이퍼바이저를 활용해 가상화를 구현한 VM과 달리 컨테이너는 Host OS를 공유하는 형태이므로 컨테이너의 시스템콜이 Host OS로 요청됨 이러한 escaping을 통제하기 위해 샌드박싱 기법을 활용하게 되는데 seccomp, apparmor를 적용하는 것은 현실적으로 불가능(각 애플리케이션별로 허용 가능한 syscall을 판별하고 허용해줘야 해서) 2. gViso 이러한 문제의 현실적 대안으로서 gVisor 활용 gVisor는 컨테이너를 위한 애플리케이션 커널 역할을 수행하면서 Application(Container)의 System Call Layer 역할을 수행함으로서 Application과 Host OS의 Kernel을 분리 gVisor는 Sentry와 Gofer로 구성 Sentry A..
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
1. 개념 관리형 쿠버네티스의 Node(EC2)에서 IMDS에 접근 가능할 경우 Pod에서도 접근 가능 IMDS에 크레덴셜이 저장되어 있을 가능성이 존재하므로 NetworkPolicies를 활용해 metadata 접근제어 필요 2. NetworkPolicies 설정 (1) 모든 파드의 egress 통신은 허용하되 IMDS 접근은 차단 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: pol1 namespace: default spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 0.0.0.0/0 except: - 169.254.169.254/32 (2)..
1. TLS 인증서 생성 (Ingress는 생성되었다고 가정) openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout cert.key -out cert.crt -subj "/CN=[host_name]/O=[host_name]” 2. TLS Secret 생성 k create secret tls [name] --key cert.key --cert cert.crt 3. Ingress 수정 공식문서를 참고해 spec.tls 추가 4. 접속 테스트 curl -kv https://[host_name]:[node_port]/[path] 5. 참고 https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell
1. 개념 K8s에서 작동하는 방화벽 개념 네임스페이스 단위로 적용 Ingress / Egress 방향에 대해 정책을 설정할 수 있고 label, IP를 기준으로 세부 설정 가능 CNI(Calico, Weave)에 의해 작동하므로 CNI에서 지원하지 않을 경우 NetworkPolicie 사용 불가 동일한 pod에 여러개의 NP를 적용할 수 있고, 이러한 경우 각 NP의 순서는 영향을 미치지 않으며 모든 NP의 총합이 반영 2. 예시 3. 실습1(DNS를 제외한 모든 Egress 트래픽 기본 차단) apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-out-default spec: podSelector: {} policyTyp..
1. 개념 K8s의 보안은 On-prem 보안과는 접근방법이 다르고 Cloud 보안과도 차이가 존재 Cloud Native Security의 기본은 4C Cloud Cluster Container Code 2. K8s Attack / Security Surface 공격 표면을 반대로 이야기하면 보안 표면으로 볼 수 있음 K8s에는 3개의 공격 / 보안 표면이 존재 Host OS Security Cluster Security Application Security 3. Host OS Security K8s 클러스터가 구동되는 Host의 운영체제를 의미(EKS라면 Node가 구동되는 EC2의 AMI) Host OS를 안전하게 관리하는 방법은 일반적인 서버 보안과 동일한 층위로 접근 CCE 점검 K8s 노드 서..
