애플리케이션 보안 체크리스트

애플리케이션 보안 체크리스트 (Application Security Checklist)

Kubernetes에서 애플리케이션 보안을 보장하기 위한 기본 지침으로, 애플리케이션 개발자를 대상으로 해요.

이 체크리스트는 개발자 관점에서 Kubernetes에서 실행되는 애플리케이션을 보호하기 위한 기본 가이드라인을 제공하는 것이 목적입니다. 이 목록이 완전한 것은 아니며, 시간이 지나면서 발전하도록 의도되었어요.

이 문서를 읽고 사용하는 방법은 다음과 같아요.

주제의 순서가 우선순위의 순서를 반영하지는 않습니다.
일부 체크리스트 항목은 각 섹션의 목록 아래 단락에서 자세히 설명됩니다.
이 체크리스트는 개발자(developer)가 네임스페이스 범위 객체와 상호작용하는 Kubernetes 클러스터 사용자라고 가정합니다.

주의 (Caution):

체크리스트만으로는 좋은 보안 상태를 달성하기에 충분하지 않습니다. 좋은 보안 상태는 지속적인 관심과 개선이 필요하지만, 체크리스트는 보안 준비를 향한 끝없는 여정의 첫걸음이 될 수 있어요. 이 체크리스트의 일부 권장 사항은 여러분의 특정 보안 요구에 비해 너무 제한적이거나 너무 느슨할 수 있습니다. Kubernetes 보안은 "하나의 크기가 모든 것에 맞는(one size fits all)" 방식이 아니므로, 체크리스트 항목의 각 범주는 그 자체의 가치에 따라 평가되어야 합니다.

기본 보안 강화 (Base security hardening)

다음 체크리스트는 Kubernetes에 배포하는 대부분의 애플리케이션에 적용되는 기본 보안 강화 권장 사항을 제공합니다.

애플리케이션 설계 (Application design)

애플리케이션을 설계할 때 올바른 보안 원칙을 따르세요.
리소스 요청(request)과 한도(limit)를 통해 적절한 QoS 클래스로 애플리케이션을 구성합니다.
- 요청과 같거나 큰 한도로 워크로드에 대한 메모리 한도가 설정됩니다.
- 민감한 워크로드에는 CPU 한도가 설정될 수 있어요.

서비스 계정 (Service account)

default ServiceAccount를 사용하지 마세요. 대신 각 워크로드 또는 마이크로서비스에 대해 ServiceAccount를 생성합니다.
파드가 작동하기 위해 Kubernetes API에 대한 접근을 특별히 요구하지 않는 한 automountServiceAccountToken을 false로 설정해야 합니다.

파드 수준 `securityContext` 권장 사항

runAsNonRoot: true를 설정합니다.
컨테이너가 덜 권한 있는 사용자로 실행되도록 구성하고(예: runAsUser와 runAsGroup 사용), 컨테이너 이미지 안의 파일이나 디렉터리에 적절한 권한을 구성해요.
선택적으로 fsGroup으로 보조 그룹을 추가해서 영구 볼륨에 접근할 수 있게 하세요.
애플리케이션은 적절한 파드 보안 표준을 강제하는 네임스페이스에 배포됩니다. 애플리케이션이 배포되는 클러스터에서 이 강제를 통제할 수 없다면, 문서화나 추가적인 방어 계층(defense in depth)을 통해 이를 고려하세요.

컨테이너 수준 `securityContext` 권장 사항

allowPrivilegeEscalation: false를 사용해서 권한 상승을 비활성화합니다.
readOnlyRootFilesystem: true로 루트 파일시스템을 읽기 전용으로 구성해요.
권한 있는(privileged) 컨테이너 실행을 피하세요(privileged: false 설정).
컨테이너에서 모든 capability를 제거하고, 컨테이너 작동에 필요한 특정 것들만 다시 추가합니다.

역할 기반 접근 통제 (Role Based Access Control, RBAC)

create, patch, update, delete 같은 권한은 필요한 경우에만 부여해야 합니다.
권한 상승으로 이어질 수 있는 역할 생성이나 업데이트를 위한 RBAC 권한을 만드는 것을 피하세요.
system:unauthenticated 그룹에 대한 바인딩을 검토하고 가능하면 제거합니다. 이 그룹은 네트워크 수준에서 API 서버에 접근할 수 있는 누구에게나 접근을 허용하기 때문이에요.
create, update, delete 동사는 신중하게 허용되어야 합니다. 네임스페이스에서 patch 동사를 허용하면 사용자가 네임스페이스나 디플로이먼트의 레이블을 업데이트할 수 있게 되어 공격 표면이 커질 수 있어요.

민감한 워크로드의 경우, 허용된 쓰기 작업을 더 제한하는 권장 ValidatingAdmissionPolicy를 제공하는 것을 고려해 보세요.

이미지 보안 (Image security)

컨테이너를 Kubernetes 클러스터에 배포하기 전에 이미지 스캐닝 도구를 사용해서 이미지를 스캔합니다.
컨테이너 서명(container signing)을 사용해서 Kubernetes 클러스터에 배포하기 전에 컨테이너 이미지 서명을 검증해요.

네트워크 정책 (Network policies)

NetworkPolicy를 구성해서 파드에서 예상되는 수신(ingress) 및 송신(egress) 트래픽만 허용하세요.
클러스터가 NetworkPolicy를 제공하고 강제하는지 확인합니다. 사용자가 다른 클러스터에 배포할 애플리케이션을 작성한다면, NetworkPolicy가 사용 가능하고 강제된다고 가정할 수 있는지 고려해 보세요.

고급 보안 강화 (Advanced security hardening)

이 가이드의 이 섹션에서는 다양한 Kubernetes 환경 구성에 따라 유용할 수 있는 몇 가지 고급 보안 강화 포인트를 다룹니다.

Linux 컨테이너 보안

파드-컨테이너에 보안 컨텍스트(Security Context)를 구성하세요.

런타임 클래스 (Runtime classes)

컨테이너에 적절한 런타임 클래스를 구성해요.

참고: 이 섹션은 Kubernetes에 필요한 기능을 제공하는 제3자 프로젝트에 연결합니다. Kubernetes 프로젝트 저자들은 알파벳순으로 나열된 이 프로젝트들에 책임을 지지 않습니다. 이 목록에 프로젝트를 추가하려면 변경을 제출하기 전에 콘텐츠 가이드를 읽어 주세요. 자세한 내용은 관련 문서를 참고하세요.

일부 컨테이너는 클러스터의 기본 런타임이 제공하는 것과 다른 격리 수준을 요구할 수 있어요. podspec에서 runtimeClassName을 사용해서 다른 런타임 클래스를 정의할 수 있습니다.

민감한 워크로드의 경우 gVisor 같은 커널 에뮬레이션 도구나 kata-containers 같은 메커니즘을 사용한 가상화된 격리를 사용하는 것을 고려해 보세요.

신뢰 수준이 높은 환경에서는 기밀 가상 머신(confidential virtual machines)을 사용해서 클러스터 보안을 더욱 개선하는 것을 고려해요.

이 페이지의 항목들은 Kubernetes에 필요한 기능을 제공하는 제3자 제품이나 프로젝트를 가리킵니다. Kubernetes 프로젝트 저자들은 그런 제3자 제품이나 프로젝트에 대해 책임을 지지 않습니다. 자세한 내용은 CNCF 웹사이트 가이드라인을 참조하세요.

제3자 링크를 추가하는 변경을 제안하기 전에 콘텐츠 가이드를 읽어야 합니다.

애플리케이션 보안 체크리스트