AKS(Azure Kubernetes Services)의 pod 보안 모범 사례
AKS(Azure Kubernetes Service)에서 애플리케이션을 개발 및 실행할 경우 pod 보안 유지가 핵심 고려 사항입니다. 애플리케이션은 필요한 최소 권한 수 원칙에 따라 디자인해야 합니다. 프라이빗 데이터를 안전하게 유지하는 일은 고객을 위하는 마음입니다. 데이터베이스 연결 문자열, 키 또는 비밀과 인증서를 외부 세계에 노출하여 악의적인 공격 용도로 활용되는 것을 원하지 않을 것입니다. 이러한 항목을 코드에 추가하거나 컨테이너 이미지에 포함하지 않도록 합니다. 이러한 방식은 노출 위험을 초래하며, 컨테이너 이미지를 다시 작성해야 할 때 해당 자격 증명을 순환하는 기능을 제한합니다.
이 모범 사례 문서는 AKS에서 Pod를 보호하는 방법에 중점을 둡니다. 다음 방법에 대해 설명합니다.
- Pod 보안 컨텍스트를 사용하여 프로세스 및 서비스나 권한 상승에 대한 액세스 제한
- Microsoft Entra 워크로드 ID를 사용하여 다른 Azure 리소스로 인증
- Azure Key Vault와 같은 디지털 자격 증명 모음에서 자격 증명 요청 및 검색
클러스터 보안 및 컨테이너 이미지 관리에 대한 모범 사례를 참조할 수도 있습니다.
리소스에 대한 pod 액세스 보안 유지
모범 사례 지침 - 다른 사용자 또는 그룹 권한으로 실행하고 기본 노드 프로세스 및 서비스에 대한 액세스를 제한하려면 pod 보안 컨텍스트 설정을 정의합니다. 필요한 최소 권한 수를 할당합니다.
애플리케이션이 제대로 실행되려면 pod를 루트 권한이 아닌 정의된 사용자 또는 그룹 권한으로 실행해야 합니다. pod 또는 컨테이너에 대한 securityContext
를 사용하여 runAsUser 또는 fsGroup와 같은 설정을 정의함으로써 해당 권한을 가정할 수 있습니다. 필요한 사용자 또는 그룹 권한만 할당하고, 추가 권한을 가정하는 수단으로 보안 컨텍스트를 사용하지 않도록 합니다. runAsUser, 권한 상승 및 기타 Linux 기능 설정은 Linux 노드 및 Pod에서만 사용할 수 있습니다.
루트가 아닌 사용자 권한으로 실행하면 컨테이너는 1024 미만의 권한 있는 포트에 바인딩할 수 없습니다. 이 시나리오에서는 Kubernetes 서비스를 사용하여 앱이 특정 포트에서 실행되고 있는 것처럼 가장할 수 있습니다.
또한 pod 보안 컨텍스트는 프로세스 및 서비스에 액세스하기 위한 추가 기능 또는 권한을 정의할 수도 있습니다. 다음과 같은 일반적인 보안 컨텍스트 정의를 설정할 수 있습니다.
- allowPrivilegeEscalation은 pod가 루트 권한을 가정할 수 있는지를 정의합니다. 이 설정이 항상 false로 설정되도록 애플리케이션을 디자인합니다.
- Linux 기능을 사용하여 pod가 기본 노드 프로세스에 액세스하도록 할 수 있습니다. 이러한 기능을 할당할 때는 주의해야 합니다. 필요한 최소 권한 수를 할당합니다. 자세한 내용은 Linux 기능을 참조하세요.
- SELinux 레이블은 서비스, 프로세스 및 파일 시스템 액세스에 대한 액세스 정책을 정의할 수 있는 Linux 커널 보안 모듈입니다. 마찬가지로 필요한 최소 권한 수를 할당합니다. 자세한 내용은 Kubernetes의 SELinux 옵션을 참조하세요.
다음 예제 pod YAML 매니페스트는 정의할 보안 컨텍스트 설정을 지정합니다.
- Pod는 사용자 ID 1000과 그룹 ID 2000의 일부로 실행됩니다.
root
를 사용하도록 권한을 에스컬레이션할 수 없습니다.- Linux 기능이 네트워크 인터페이스 및 호스트의 실시간(하드웨어) 클록에 액세스할 수 있도록 허용합니다.
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
fsGroup: 2000
containers:
- name: security-context-demo
image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
securityContext:
runAsUser: 1000
allowPrivilegeEscalation: false
capabilities:
add: ["NET_ADMIN", "SYS_TIME"]
클러스터 운영자와 함께 필요한 보안 컨텍스트 설정을 확인합니다. pod에 필요한 추가 권한 및 액세스 권한을 최소화하도록 애플리케이션을 디자인합니다. AppArmor 및 seccomp(보안 컴퓨팅)를 사용하여 액세스를 제한하는 추가 보안 기능이 있습니다. 이러한 보안 기능은 클러스터 운영자가 구현할 수 있습니다. 자세한 내용은 리소스에 대한 컨테이너 액세스 보호를 참조하세요.
자격 증명 노출 제한
모범 사례 지침 - 애플리케이션 코드에서 자격 증명을 정의하지 않도록 합니다. Azure 리소스에 대해 관리 ID를 사용하여 pod가 다른 리소스에 대한 액세스를 요청하도록 합니다. 또한 Azure Key Vault와 같은 디지털 자격 증명 모음을 사용하여 디지털 키 및 자격 증명을 저장하고 검색하는 것이 좋습니다. Pod 관리 ID는 Linux Pod 및 컨테이너 이미지에만 사용됩니다.
애플리케이션 코드에 자격 증명이 노출될 위험을 제한하려면 고정 또는 공유 자격 증명을 사용하지 않도록 합니다. 자격 증명 또는 키를 코드에 직접 포함하면 안 됩니다. 이러한 자격 증명이 노출되면 애플리케이션을 업데이트하고 다시 배포해야 합니다. 더 나은 방법은 pod에 고유한 ID를 부여하고 스스로 인증을 받는 방법을 제공하거나 디지털 자격 증명 모음에서 자격 증명을 자동으로 검색하는 것입니다.
Microsoft Entra 워크로드 ID 사용
워크로드 ID는 Pod에서 실행되는 애플리케이션에서 사용하는 ID로, 이를 지원하는 다른 Azure 서비스(예: Storage 또는 SQL)에 대해 인증할 수 있습니다. Kubernetes에 기본 제공된 기능과 통합하여 외부 ID 공급자와 페더레이션합니다. 이 보안 모델에서 AKS 클러스터는 토큰 발급자 역할을 하며, Microsoft Entra ID는 OpenID Connect를 사용하여 퍼블릭 서명 키를 검색하고 서비스 계정 토큰의 신뢰성을 확인한 후 Microsoft Entra ID 토큰으로 교환합니다. 워크로드는 Azure SDK 또는 MSAL(Microsoft 인증 라이브러리)을 사용하여 Azure ID 클라이언트 라이브러리를 통해 볼륨에 프로젝션된 서비스 계정 토큰을 Microsoft Entra 토큰으로 교환할 수 있습니다.
워크로드 ID에 대한 자세한 내용은 애플리케이션과 함께 Microsoft Entra 워크로드 ID를 사용하도록 AKS 클러스터 구성을 참조하세요.
비밀 저장소 CSI 드라이버와 함께 Azure Key Vault 사용
Microsoft Entra 워크로드 ID를 사용하면 Azure 서비스 지원에 대한 인증이 가능합니다. Azure 리소스에 대한 관리 ID가 없는 사용자 고유의 서비스 또는 애플리케이션의 경우 자격 증명 또는 키를 사용하여 계속 인증할 수 있습니다. 이러한 비밀 콘텐츠를 저장하는 데 디지털 자격 증명 모음을 사용할 수 있습니다.
애플리케이션에 자격 증명이 필요한 경우 디지털 자격 증명 모음과 통신하고 최신 비밀 콘텐츠를 검색한 다음, 필요한 서비스에 연결합니다. Azure Key Vault는 이러한 디지털 자격 증명 모음일 수 있습니다. pod 관리 ID를 사용하여 Azure Key Vault에서 자격 증명을 검색하기 위한 간소화된 워크플로가 다음 다이어그램에 나와 있습니다.
Key Vault를 사용하여 자격 증명, 스토리지 계정 키 또는 인증서와 같은 암호를 저장하고 정기적으로 순환합니다. 비밀 저장소 CSI 드라이버용 Azure Key Vault 공급자를 사용하여 Azure Key Vault를 AKS 클러스터와 통합할 수 있습니다. 비밀 저장소 CSI 드라이버를 사용하면 AKS 클러스터가 기본적으로 Key Vault에서 비밀 콘텐츠를 검색하여 요청 Pod에만 안전하게 제공할 수 있습니다. 클러스터 운영자와 협력하여 비밀 저장소 CSI 드라이버를 AKS 작업자 노드에 배포합니다. Microsoft Entra 워크로드 ID를 사용하여 Key Vault에 대한 액세스를 요청하고 비밀 저장소 CSI 드라이버를 통해 필요한 비밀 콘텐츠를 검색할 수 있습니다.
다음 단계
이 문서에서는 pod를 보호하는 방법을 중점적으로 설명했습니다. 이러한 일부 영역을 구현하려면 다음 문서를 참조하세요.
Azure Kubernetes Service