AWS re:Invent 2022 — How to address Kubernetes attack vectors 세션 후기

안녕하세요, KCD 정보보안팀 Chan 입니다.

AWS re:Invent 2022에서는 기조 연설, 리더쉽 세션을 포함하여 100여개의 비지니스/기술 트랙에 총 2천 여개가 넘은 강연 세션이 제공 되었습니다.

수 많은 세션 중 어떤 세션을 들어야 할까 고민 중에 Kubernetes 환경을 고려 중인 시점에서 Securing Kubernetes: How to address Kubernetes attack vectors (CON318) 세션에 관심이 생겨 듣게 되었습니다.

해당 세션에서는 Kubernetes 환경에서 발생 할 수 있는 몇 가지 Attack vectors에 대한 사례를 소개하고 있습니다.

Secrets leak

• EKS Endpoint에 대한 외부 접근이 허용되어 Secrets이 노출 된 사례를 소개하고 있습니다.
• Secrets은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를 포함하는 오브젝트 이며, 중요한 정보가 Pod manifests나 Container image에 포함되지 않도록 하기 위해 사용되고 있습니다.
• Secrets에 저장되는 데이터는 암호화 되는 것이 아니며, Base64로 인코딩 되는 것이기 때문에 노출 될 경우에 쉽게 디코딩이 가능합니다.
  
  

출처: AWS re:Invent 2022 — Securing Kubernetes: How to address Kubernetes attack vectors (CON318)

Violation of least privilege

• CSI(Container Storage Interface) Driver 사용 시 serviceaccounts/token에 대한 create 권한을 부여한 사례를 소개하고 있습니다.
• serviceaccounts/token에 대한 create 권한이 있는 사용자는 TokenRequests를 생성하여 기존 Service account에 대한 Token을 발행 할 수 있습니다.
  
  

출처: AWS re:Invent 2022 — Securing Kubernetes: How to address Kubernetes attack vectors (CON318)

Privilege escalation

• users와 groups에 대한 impersonate 권한을 부여한 사례를 소개하고 있습니다.
• 특정 User 또는 Group에 대한 권한을 부여받아 기존 권한이 없는 Resource에 접근 할 수 있습니다.
• 부여받은 User 또는 Group이 ACK(AWS Controllers for Kubernetes)에 대한 권한을 가지고 있는 경우에는 해당 AWS 서비스에도 접근 할 수 있습니다.
  
  

출처: AWS re:Invent 2022 — Securing Kubernetes: How to address Kubernetes attack vectors (CON318)

Security misconfiguration

• system:anonymous Group에 cluster-admin Role을 부여한 사례를 소개하고 있습니다.
• 인가되지 않는 Anonymous User가 system:master와 동일한 Role을 가지게 되어, 모든 Resource에 대한 모든 Verbs가 가능하게 됩니다.
  
  

출처: AWS re:Invent 2022 — Securing Kubernetes: How to address Kubernetes attack vectors (CON318)

Insecure defaults

• kubelet 기본 설정을 사용한 사례를 소개하고 있습니다.
• anonymous-auth가 true인 경우에는 인가되지 않는 Anonymous User도 요청이 허용 됩니다.
• authorization-mode가 AlwaysAllow인 경우에는 별도의 제한없이 모든 요청이 허용 됩니다.
  
  

출처: AWS re:Invent 2022 — Securing Kubernetes: How to address Kubernetes attack vectors (CON318)

Vulnerable or outdated components

• 최근 5년간 Amazon Linux 2 Kernel과 Kubernetes에 대한 CVE 현황을 소개하고 있습니다.
• 취약점은 꾸준히 발견되고 있으며, 매년 증가하는 추세를 보이고 있습니다.
  
  

출처: AWS re:Invent 2022 — Securing Kubernetes: How to address Kubernetes attack vectors (CON318)

Server side request forgery

• Kubernetes에서 발견 되었던 SSRF 취약점 사례를 소개하고 있습니다.
• kubectl proxy를 통하여 특정 Pod에 대한 podIP를 임의의 공격 대상 IP로 변경 합니다.
• 기존 Pod가 port-forward 중인 상태라면, 변경 된 podIP로 외부에서 접근이 가능하게 됩니다.
  
  

출처: AWS re:Invent 2022 — Securing Kubernetes: How to address Kubernetes attack vectors (CON318)

Attack vectors에 대한 Mitigation 방안에 대해서도 소개하고 있습니다.

Secrets leak mitigation

• EKS cluster endpoint 외부 접근 차단 (참고: Amazon EKS cluster endpoint access control)
• Secrets에 저장된 데이터에 대한 AWS KMS 암호화 사용 (참고: Enabling secret encryption)

Broken access control mitigation

• 최소 권한 RBAC Role 사용 (참고: Generate policies from audit logs)
• 클러스터 전체 권한을 DaemonSets로 제한
• TokenReques를 지원하는 CSI 드라이버 사용
• RBAC 정책에서 Verbs 및 Resources를 명시적으로 열거
• IRSA(IAM Roles for Service Account) 사용 (참고: Set up IAM roles for service accounts)

Security misconfiguration mitigation

• aws-auth ConfigMap에서 system:masters 그룹 사용자 미 사용
• Pods에서 호스트 엑세스 제한
• Kubernetes 구성 요소에 대해 EKS 제공 기본값 사용

Vunerability component mitigation

• Machine, Container Image, Application를 최신 상태로 유지
• Kubernetes Cluster를 최신 상태로 유지 (참고: Amazon EKS Kubernetes versions)

Logging and monitoring failure mitigation

• 모든 Control plane 구성 요소에 대해 Kubernetes 로깅 활성화
• Kubelet 로그를 CloudWatch로 전송

Server side request forgery mitigation

• Kubernetes 감사 로깅 활성화
• Kubernetes API 아웃바운드 액세스 제한

위에 언급된 방안 외에도 추가적인 Pod 보호 방안에 대해서도 소개하고 있습니다.

• Pod Security Policy로 Pod Security Admission 사용 (Kubernetes &gt= v1.23)
• OPA(Open Policy Agent) 및 Gatekeeper 설치
• EKS Security Best Practices Guide 참고

Kubernetes 환경으로 전환 시 어떤 위협이 존재하는지 어떻게 예방해야 하는지 어떻게 모니터링해야 하는지에 대해 고민 할 수 있는 유익한 시간 이였습니다.

소개 된 사례 외 추가적인 Attack vectors 대한 지속적인 리서칭과 운영환경에 맞는 보안대책 준비가 필요하고 생각 됩니다.