• 신뢰할 수 없는 레지스트리의 코드. 신뢰할 수 없는 코드에는 의도치 않게 악성 행위자에게 액세스 권한을 부여할 수 있는 멀웨어나 백도어가 포함될 수 있습니다.
• 과도한 기본 이미지. 컨테이너화된 애플리케이션은 적을수록 좋으므로 개발자는 손상될 수 있는 불필요한 패키지, 라이브러리 및 셸을 제거해야 합니다.
  

• 불필요한 권한 부여. 가능한 경우 권한을 최소한으로 유지하고 작업에 필요한 기밀 정보만 제공하여 공격 표면을 줄입니다.
• 클러스터에서 애플리케이션 격리 실패. 네임스페이스를 사용하여 리소스와 팀을 서로 분리해야 합니다.
• 클러스터 내부의 측면 이동. 네트워크를 세분화하는 정책을 사용하여 클러스터 내에서 공격의 수평 이동을 방지하십시오.
• 무단 액세스. 역할 기반 액세스 제어(RBAC)가 액세스를 제한하도록 올바르게 구성되어 있는지 확인하십시오.
  

• 인프라 공격. 런타임 중에 API 서버, etcd, 컨트롤러를 포함한 Kubernetes 인프라의 모든 요소는 각자의 공격 표면을 드러냅니다.
• 복잡성. Kubernetes 클러스터의 지속적인 상태에는 변화하는 부분이 많습니다. 공격의 원인을 찾아 문제를 해결하는 동안 손상된 컨테이너를 신속하게 격리 및 중지하고 정상적인 컨테이너로 교체해야 합니다.
  

모범 사례 권장 사항은 배포가 없는 최소한의 이미지로 시작하여 꼭 필요한 항목만 추가하는 것입니다. 작을수록 안전합니다.

• 최소 호스트 OS를 사용하고, 읽기 전용 마운트를 종료하고, SELinux 옵션 사용으로 제어를 강화합니다.
• OS 이미지 및 모든 유형의 외부 이미지를 포함하여 이미지에서 하향식으로 취약점을 검사합니다. 신뢰할 수 있는 외부 출처는 없습니다.
• 네임스페이스 및 RBAC를 사용하여 논리적 방식으로 클러스터와 사용자를 세분화합니다. 필요하지 않은 경우 표시되어서는 안 됩니다.
• Kubernetes 네트워킹의 기본값은 any-to-any 통신을 허용하므로 운영하기 전에 네트워크 세분화를 구현해야 합니다. 수신 및 송신 정책을 신중하게 정의하여 연결이 올바르게 라우팅되도록 합니다.
• 권한을 최소한으로 유지하고 애플리케이션 프로세스를 루트로 실행하지 않습니다. 읽기 전용 루트 파일 시스템을 사용하면 소프트웨어 설치 또는 파일 시스템 수정을 이용하는 모든 공격을 방지할 수 있습니다.
• 이미지 스캐닝과 같은 보안을 CI/CD 파이프라인에 통합합니다. 더 좋은 방법은 CIS 벤치마크 보안 테스트를 실행하는 것입니다.
• 클러스터 자체를 보호합니다. API 서버에 대한 액세스를 제한하도록 RBAC를 구성하고 모든 etcd 통신을 TLS 암호화로 보호합니다. 마찬가지로 kubelet에 대한 RBAC를 구성하여 kubelet 사용 권한을 잠급니다.
• 보안 컨텍스트를 구성하여 포드 액세스를 제한하는 등 Kubernetes에 내장된 제어 기능을 활용합니다.
• 사전 예방적 보안에는 프로세스 활동 모니터링, 서비스 간 통신 및 클러스터 외부 통신이 포함되어야 합니다.