이 문서는 2021년 11월에 출시된 Azure용 GKE의 최신 버전을 대상으로 합니다. 자세한 정보는 출시 노트를 참조하세요.

이 페이지는 Cloud Translation API를 통해 번역되었습니다.

보안 개요

이 페이지에서는 암호화 및 노드 구성을 포함하여 Azure용 GKE의 보안 아키텍처에 관해 설명합니다.

GKE 클러스터는 컨테이너 이미지 콘텐츠, 컨테이너 런타임, 클러스터 네트워크, 클러스터 API 서버 액세스를 포함하여 워크로드 보안을 지원하는 기능을 제공합니다.

GKE 클러스터를 사용하는 경우 클러스터에 대한 특정 책임을 질 것에 동의하는 것으로 간주됩니다. 자세한 내용은 GKE 클러스터 공동 책임을 참조하세요.

저장 데이터 암호화

저장 데이터 암호화는 전송 중 데이터와 구분되는 저장된 데이터에 대한 암호화입니다. 기본적으로 Azure용 GKE는 Azure 플랫폼 관리 키를 사용하여 etcd 및 스토리지 볼륨의 데이터를 암호화합니다.

Azure용 GKE는 Azure Disk 볼륨에 데이터를 저장합니다. 이러한 볼륨은 항상 Azure Key Vault 키를 사용해서 저장 상태에서 암호화가 수행됩니다. 클러스터 및 노드 풀을 만들 때는 클러스터의 기본 디스크 볼륨을 암호화하도록 고객 관리 Key Vault 키를 제공할 수 있습니다. 키를 지정하지 않으면 Azure가 클러스터가 실행되는 Azure 리전 내에서 기본 Azure 관리 키를 사용합니다.

또한 모든 GKE 클러스터는 etcd에 저장되는 Kubernetes 보안 비밀 객체와 같은 민감한 정보에 애플리케이션 레이어 보안 비밀 암호화를 사용 설정합니다. 공격자가 etcd 데이터가 저장된 기본 볼륨에 대해 액세스 권한을 얻더라도 이러한 데이터가 암호화됩니다.

클러스터를 만들 때 --database-encryption-kms-key-arn 매개변수에 Azure Key Vault 키를 제공할 수 있습니다. 이 키는 애플리케이션 데이터 암호화를 위해 사용됩니다. 클러스터를 만들 때 키를 제공하지 않으면 Azure용 GKE가 사용자 클러스터에 대해 자동으로 키를 만듭니다. 이 리소스 필드는 변경되지 않으며 클러스터를 만든 후 수정할 수 없습니다.

또한 Key Vault 키를 수동으로 만들거나 하드웨어 보안 모듈(HSM)을 사용해서 키를 자체적으로 조달(BYOK)할 수 있습니다. 자세한 내용은 키 자체 조달을 참조하세요.

애플리케이션 수준 암호화 작동 방법

Kubernetes는 봉투 암호화로 알려진 기술을 지원하는 애플리케이션 수준 암호화를 제공합니다. 보안 비밀을 암호화하기 위해서는 일반적으로 데이터 암호화 키(DEK)라고 부르는 로컬 키가 사용됩니다. 그런 다음에는 키 암호화 키(KEK)라고 부르는 보조 키를 사용해서 DEK 자체를 암호화합니다. KEK는 Kubernetes에 저장되지 않습니다. 새 Kubernetes 보안 비밀을 만들 때 클러스터는 다음을 수행합니다.

Kubernetes API 서버가 난수 생성기를 사용하여 보안 비밀의 고유한 DEK를 생성합니다.
Kubernetes API 서버가 DEK를 사용해서 보안 비밀을 로컬로 암호화합니다.
Kubernetes API 서버가 암호화를 위해 DEK를 Azure Key Vault로 전송합니다.
Azure Key Vault는 사전 생성된 KEK를 사용하여 DEK를 암호화하고 암호화된 DEK를 Kubernetes API 서버의 Azure Key Vault 플러그인에 반환합니다.
Kubernetes API 서버가 암호화된 보안 비밀과 암호화된 DEK를 etcd에 저장합니다. 일반 텍스트로 된 DEK는 디스크에 저장되지 않습니다.
Kubernetes API 서버가 암호화된 DEK를 일반 텍스트 DEK에 매핑하기 위해 인메모리 캐시 항목을 만듭니다. 그러면 API 서버가 Azure Key Vault에 쿼리하지 않아도 최근에 액세스된 보안 비밀을 복호화할 수 있습니다.

클라이언트가 Kubernetes API 서버에서 보안 비밀을 요청하면 다음과 같이 됩니다.

Kubernetes API 서버가 etcd에서 암호화된 보안 비밀 및 암호화된 DEK를 검색합니다.
Kubernetes API 서버가 캐시에서 기존 맵 항목을 확인하고 항목이 발견되면 보안 비밀을 복호화합니다.
일치하는 캐시 항목이 없으면 API 서버가 KEK를 사용해서 복호화를 위해 DEK를 Azure Key Vault로 전송합니다. 그러면 복호화된 DEK가 보안 비밀을 복호화하는 데 사용됩니다.
마지막으로, Kubernetes API 서버가 복호화된 보안 비밀을 클라이언트에 반환합니다.

Key Vault 방화벽으로 암호화 구성

암호화를 위해 공개 키를 전달하는 경우 서비스 주 구성원은 암호화할 수 있는 권한이 없어도 되지만, 역할 할당을 관리할 수 있는 권한이 필요합니다. 가장 쉬운 방법은 Azure User Access Administrator 기본 제공 역할을 서비스 주 구성원에 부여합니다.

Azure Key Vault를 추가로 보호하려면 Azure Key Vault 방화벽을 사용 설정할 수 있습니다. 그러면 Azure용 GKE가 암호화를 위해 공개 키를 사용하고 키 저장소에 대한 네트워크 액세스를 방지할 수 있습니다.

방화벽을 구성하려면 Azure CLI로 Key Vault 키를 다운로드합니다. Google Cloud CLI로 클러스터를 만들 때 키를 --config-encryption-public-key에 전달합니다.

여전히 클러스터에 사용되는 모든 서브넷에서 키 저장소에 대해 서비스 엔드포인트를 사용 설정해야 합니다. 자세한 내용은 Azure Key Vault에 대한 가상 네트워크 서비스 엔드포인트를 참조하세요.

키 순환

인증서 순환과 반대로 키 순환은 키 암호화 키(KEK)에 포함된 기본 암호화 자료를 변경하는 작업입니다. 예약된 순환에 따라 자동으로 또는 키가 손상되었을 수 있는 보안 사고가 발생한 후 수동으로 키 순환을 트리거할 수 있습니다. 키 순환을 수행하면 키에서 원시 암호화/복호화 키 데이터가 포함된 단일 필드만 바뀝니다.

자세한 내용은 키 순환을 참조하세요.

클러스터 신뢰

모든 클러스터 통신은 전송 계층 보안(TLS)을 사용합니다. 각 클러스터는 다음과 같은 기본 자체 서명된 루트 인증 기관(CA)으로 프로비저닝됩니다.

클러스터 루트 CA는 API 서버로 전송되는 요청을 검증하기 위해 사용됩니다.
etcd 루트 CA는 etcd 복제본으로 전송되는 요청을 검증하기 위해 사용됩니다.

각 클러스터에는 고유한 루트 CA가 있습니다. 한 클러스터의 CA가 손상되더라도 다른 클러스터의 CA는 영향을 받지 않습니다. 모든 루트 CA는 유효 기간이 30년입니다.

노드 보안

AWS용 GKE는 Azure VM 인스턴스의 노드 풀에 워크로드를 배포합니다. 다음 섹션에서는 노드의 보안 기능에 대해 설명합니다.

Ubuntu

노드가 최적화된 Ubuntu OS 버전을 사용하여 Kubernetes 제어 영역과 노드를 실행합니다. 자세한 내용은 Ubuntu 문서의 보안 기능을 참조하세요.

GKE 클러스터는 다음을 포함하여 여러 보안 기능을 구현합니다.

최적화된 패키지 세트
Google Cloud 맞춤형 Linux 커널
제한된 사용자 계정 및 루트 로그인 사용 중지

Ubuntu에는 다음과 같은 추가 보안 가이드가 제공됩니다.

워크로드 보호

사용자는 Kubernetes를 통해 컨테이너 기반 워크로드를 신속하게 프로비저닝, 확장, 업데이트할 수 있습니다. 이 섹션에서는 클러스터 및 Google Cloud 서비스에서 컨테이너를 실행할 때 발생하는 부작용을 제한하기 위해 사용할 수 있는 방법을 설명합니다.

포드 컨테이너 프로세스 권한 제한

클러스터 보안을 위해서는 컨테이너화된 프로세스의 권한을 제한하는 것이 중요합니다. 보안 컨텍스트를 사용하여 보안 관련 옵션을 설정할 수 있습니다. 이 설정을 사용하면 다음과 같은 프로세스의 보안 설정을 변경할 수 있습니다.

프로세스를 실행하는 사용자와 그룹
사용할 수 있는 Linux 기능
권한 에스컬레이션

Azure용 GKE 노드 기본 운영체제인 Ubuntu는 모든 컨테이너에 기본 Docker AppArmor 보안 정책을 사용합니다. GitHub에서 프로필 템플릿을 확인할 수 있습니다. 무엇보다 이 프로필은 컨테이너에 대해 다음과 같은 기능을 거부합니다.

프로세스 ID 디렉터리(/proc/)에서 파일에 직접 쓰기
/proc/에 없는 파일에 쓰기
/proc/sys에서 /proc/sys/kernel/shm* 이외의 파일에 쓰기
파일 시스템 마운트

워크로드가 자체 수정하는 기능을 제한

특정 Kubernetes 워크로드, 특히 시스템 워크로드에는 자체 수정 권한이 있습니다. 예를 들어 일부 워크로드는 수직적으로 자동 확장됩니다. 이렇게 하면 노드를 이미 손상시킨 공격자가 클러스터에서 추가로 에스컬레이션할 수 있습니다. 예를 들어 공격자는 노드에 있는 워크로드가 동일 네임스페이스에 존재하는 권한이 높은 서비스 계정으로 실행되도록 변경할 수 있습니다.

워크로드에 자체 수정 권한이 애초에 부여되지 않는 것이 좋습니다. 자체 수정이 필요한 경우 클러스터에 정책 컨트롤러 또는 Gatekeeper를 설치하고, 몇 가지 유용한 보안 정책을 제공하는 오픈소스 Gatekeeper 라이브러리에서 NoUpdateServiceAccount와 같은 제약조건을 적용하여 권한을 제한할 수 있습니다.

정책을 배포할 때는 일반적으로 클러스터 수명 주기를 관리하는 컨트롤러가 정책을 우회할 수 있도록 해야 합니다. 이는 컨트롤러가 클러스터 업그레이드 적용과 같이 클러스터를 변경할 수 있도록 하기 위해 필요합니다. 예를 들어 Azure용 GKE에 NoUpdateServiceAccount 정책을 배포하는 경우 Constraint에 다음 매개변수를 설정해야 합니다.

parameters:
  allowedGroups: []
  allowedUsers:
  - service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com

PROJECT_NUMBER를 클러스터를 호스팅하는 프로젝트의 번호(ID 아님)로 바꿉니다.

전용 노드 풀에서 워크로드 격리

Kubernetes taint 및 톨러레이션(toleration)을 사용하여 특정 유형의 워크로드를 실행하도록 특정 노드 풀을 지정할 수 있습니다. 예를 들어 대부분의 시스템 관리 워크로드에서 사용자 워크로드를 예약하거나 서로 다른 노드 풀에 신뢰 수준이 다른 워크로드를 배치하도록 Azure용 GKE에 지시할 수 있습니다.

taint 및 톨러레이션(toleration)을 사용한 워크로드 격리는 보장된 보안 조치가 아닙니다. 이를 Azure용 GKE에서 제공하는 다른 강화 방법과 함께 사용하세요.

자세한 내용은 전용 노드 풀에서 워크로드 격리를 참조하세요.

다음 단계

키 순환에 대해 알아보기