이 페이지에서는 암호화 및 노드 구성을 포함하여 AWS용 GKE의 보안 아키텍처에 관해 설명합니다.
GKE 클러스터는 컨테이너 이미지 콘텐츠, 컨테이너 런타임, 클러스터 네트워크, 클러스터 API 서버 액세스를 포함하여 워크로드 보안을 지원하는 기능을 제공합니다.
GKE 클러스터를 사용하는 경우 클러스터에 대한 특정 책임을 질 것에 동의하는 것으로 간주됩니다. 자세한 내용은 GKE 클러스터 공동 책임을 참조하세요.
AWS KMS 암호화
AWS용 GKE는 고객 관리 AWS 키 관리 서비스(KMS) 대칭 키를 사용하여 다음을 암호화합니다.
- etcd의 Kubernetes 상태 데이터
- EC2 인스턴스 사용자 데이터
- 제어 영역 및 노드 풀 데이터의 저장 데이터를 암호화하는 데 사용되는 EBS 볼륨
프로덕션 환경의 경우 구성 및 볼륨 암호화에 서로 다른 키를 사용하는 것이 좋습니다. 또한 키가 손상된 경우 위험을 최소화하려면 다음 중 하나에 대해 다른 키를 만들 수 있습니다.
추가 보안을 위해 필요한 최소 권한 집합만 할당하는 AWS KMS 키 정책을 만들 수 있습니다. 자세한 내용은 특정 권한으로 KMS 키 만들기를 참조하세요.
저장 데이터 암호화
저장 데이터 암호화는 전송 중 데이터와 구분되는 저장된 데이터에 대한 암호화입니다. 기본적으로 AWS용 GKE는 AWS 플랫폼 관리 키를 사용하여 etcd 및 스토리지 볼륨의 데이터를 암호화합니다.
AWS용 GKE는 AWS Elastic Block Storage(EBS) 볼륨에 데이터를 저장합니다. 이러한 EBS 볼륨은 항상 AWS Key Management System(AWS KMS) 키로 저장 상태에서 암호화됩니다. 클러스터 및 노드 풀을 만들 때 고객 관리 KMS 키(CMK)를 제공하여 기본 EBS 볼륨을 암호화할 수 있습니다. 키를 지정하지 않으면 AWS는 클러스터가 실행되는 AWS 리전 내에서 기본 AWS 관리 키를 사용합니다.
또한 모든 GKE 클러스터는 etcd에 저장되는 Kubernetes 보안 비밀 객체와 같은 민감한 정보에 애플리케이션 레이어 보안 비밀 암호화를 사용 설정합니다. 공격자가 etcd 데이터가 저장된 기본 볼륨에 대해 액세스 권한을 얻더라도 이러한 데이터가 암호화됩니다.
클러스터를 만들 때 AWS KMS 키를 --database-encryption-kms-key-arn 필드에 전달해야 합니다. 이 키는 애플리케이션 데이터의 봉투 암호화에 사용됩니다. 이 리소스 필드는 변경할 수 없으며 클러스터가 생성된 후에는 수정할 수 없으므로 KMS 키 별칭을 사용하는 것이 좋습니다.
키 별칭을 사용하여 클러스터 수명 주기 동안 저장 데이터 암호화에 사용되는 키를 순환할 수 있습니다.
애플리케이션 수준 암호화 작동 방법
Kubernetes는 봉투 암호화로 알려진 기술을 지원하는 애플리케이션 수준 암호화를 제공합니다. 보안 비밀을 암호화하기 위해서는 일반적으로 데이터 암호화 키(DEK)라고 부르는 로컬 키가 사용됩니다. 그런 다음에는 키 암호화 키(KEK)라고 부르는 보조 키를 사용해서 DEK 자체를 암호화합니다. KEK는 Kubernetes에 저장되지 않습니다. 새 Kubernetes 보안 비밀을 만들 때 클러스터는 다음을 수행합니다.
Kubernetes API 서버가 난수 생성기를 사용하여 보안 비밀의 고유한 DEK를 생성합니다.
Kubernetes API 서버가 DEK를 사용해서 보안 비밀을 로컬로 암호화합니다.
Kubernetes API 서버가 암호화를 위해 DEK를 AWS KMS로 전송합니다.
AWS KMS는 사전 생성된 KEK를 사용하여 DEK를 암호화하고 암호화된 DEK를 Kubernetes API 서버의 AWS KMS 플러그인에 반환합니다.
Kubernetes API 서버가 암호화된 보안 비밀과 암호화된 DEK를 etcd에 저장합니다. 일반 텍스트로 된 DEK는 디스크에 저장되지 않습니다.
Kubernetes API 서버가 암호화된 DEK를 일반 텍스트 DEK에 매핑하기 위해 인메모리 캐시 항목을 만듭니다. 그러면 API 서버가 AWS KMS에 쿼리하지 않아도 최근에 액세스된 보안 비밀을 복호화할 수 있습니다.
클라이언트가 Kubernetes API 서버에서 보안 비밀을 요청하면 다음과 같이 됩니다.
Kubernetes API 서버가 etcd에서 암호화된 보안 비밀 및 암호화된 DEK를 검색합니다.
Kubernetes API 서버가 캐시에서 기존 맵 항목을 확인하고 항목이 발견되면 보안 비밀을 복호화합니다.
일치하는 캐시 항목이 없으면 API 서버가 KEK를 사용해서 복호화를 위해 DEK를 AWS KMS로 전송합니다. 그러면 복호화된 DEK가 보안 비밀을 복호화하는 데 사용됩니다.
마지막으로, Kubernetes API 서버가 복호화된 보안 비밀을 클라이언트에 반환합니다.
키 순환
인증서 순환과 반대로 키 순환은 키 암호화 키(KEK)에 포함된 기본 암호화 자료를 변경하는 작업입니다. 예약된 순환에 따라 자동으로 또는 키가 손상되었을 수 있는 보안 사고가 발생한 후 수동으로 키 순환을 트리거할 수 있습니다. 키 순환을 수행하면 키에서 원시 암호화/복호화 키 데이터가 포함된 단일 필드만 바뀝니다.
KMS 키 순환
AWS KMS는 KMS 키의 자동 순환을 지원합니다. 사용 설정하면 AWS에서 키에 대한 새 암호화 키 자료를 1년에 한 번 자동으로 생성합니다. 직접 조치를 취할 필요는 없습니다.
자세한 내용은 키 순환을 참조하세요.
클러스터 신뢰
모든 클러스터 통신은 전송 계층 보안(TLS)을 사용합니다. 각 클러스터는 다음과 같은 기본 자체 서명된 루트 인증 기관(CA)으로 프로비저닝됩니다.
- 클러스터 루트 CA는 API 서버로 전송되는 요청을 검증하기 위해 사용됩니다.
- etcd 루트 CA는 etcd 복제본으로 전송되는 요청을 검증하기 위해 사용됩니다.
각 클러스터에는 고유한 루트 CA가 있습니다. 한 클러스터의 CA가 손상되더라도 다른 클러스터의 CA는 영향을 받지 않습니다. 모든 루트 CA는 유효 기간이 30년입니다.
노드 보안
AWS용 GKE는 AWS EC2 인스턴스의 노드 풀에 워크로드를 배포합니다. 다음 섹션에서는 노드의 보안 기능에 대해 설명합니다.
Ubuntu
노드가 최적화된 Ubuntu OS 버전을 사용하여 Kubernetes 제어 영역과 노드를 실행합니다. 자세한 내용은 Ubuntu 문서의 보안 기능을 참조하세요.
GKE 클러스터는 다음을 포함하여 여러 보안 기능을 구현합니다.
Ubuntu에는 다음과 같은 추가 보안 가이드가 제공됩니다.
워크로드 보호
사용자는 Kubernetes를 통해 컨테이너 기반 워크로드를 신속하게 프로비저닝, 확장, 업데이트할 수 있습니다. 이 섹션에서는 클러스터 및 Google Cloud 서비스에서 컨테이너를 실행할 때 발생하는 부작용을 제한하기 위해 사용할 수 있는 방법을 설명합니다.
포드 컨테이너 프로세스 권한 제한
클러스터 보안을 위해서는 컨테이너화된 프로세스의 권한을 제한하는 것이 중요합니다. 보안 컨텍스트를 사용하여 보안 관련 옵션을 설정할 수 있습니다. 이 설정을 사용하면 다음과 같은 프로세스의 보안 설정을 변경할 수 있습니다.
- 프로세스를 실행하는 사용자와 그룹
- 사용할 수 있는 Linux 기능
- 권한 에스컬레이션
AWS용 GKE 노드 기본 운영체제인 Ubuntu는 모든 컨테이너에 기본 Docker AppArmor 보안 정책을 사용합니다. GitHub에서 프로필 템플릿을 확인할 수 있습니다. 무엇보다 이 프로필은 컨테이너에 대해 다음과 같은 기능을 거부합니다.
- 프로세스 ID 디렉터리(
/proc/)에서 파일에 직접 쓰기 /proc/에 없는 파일에 쓰기/proc/sys에서/proc/sys/kernel/shm*이외의 파일에 쓰기- 파일 시스템 마운트
워크로드가 자체 수정하는 기능을 제한
특정 Kubernetes 워크로드, 특히 시스템 워크로드에는 자체 수정 권한이 있습니다. 예를 들어 일부 워크로드는 수직적으로 자동 확장됩니다. 이렇게 하면 노드를 이미 손상시킨 공격자가 클러스터에서 추가로 에스컬레이션할 수 있습니다. 예를 들어 공격자는 노드에 있는 워크로드가 동일 네임스페이스에 존재하는 권한이 높은 서비스 계정으로 실행되도록 변경할 수 있습니다.
워크로드에 자체 수정 권한이 애초에 부여되지 않는 것이 좋습니다. 자체 수정이 필요한 경우 클러스터에 정책 컨트롤러 또는 Gatekeeper를 설치하고, 몇 가지 유용한 보안 정책을 제공하는 오픈소스 Gatekeeper 라이브러리에서 NoUpdateServiceAccount와 같은 제약조건을 적용하여 권한을 제한할 수 있습니다.
정책을 배포할 때는 일반적으로 클러스터 수명 주기를 관리하는 컨트롤러가 정책을 우회할 수 있도록 해야 합니다. 이는 컨트롤러가 클러스터 업그레이드 적용과 같이 클러스터를 변경할 수 있도록 하기 위해 필요합니다. 예를 들어 AWS용 GKE에 NoUpdateServiceAccount 정책을 배포하는 경우 Constraint에 다음 매개변수를 설정해야 합니다.
parameters:
allowedGroups: []
allowedUsers:
- service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com
PROJECT_NUMBER를 클러스터를 호스팅하는 프로젝트의 번호(ID 아님)로 바꿉니다.
Binary Authorization 사용
워크로드를 보호하는 또 다른 방법은 Binary Authorization을 사용 설정하는 것입니다. Binary Authorization은 신뢰할 수 있는 컨테이너 이미지만 GKE 클러스터에 배포되도록 하는 보안 기능입니다.
절차는 다음과 같습니다.
관리자는 이미지 배포 요구사항을 정의하는 정책을 만듭니다. 여기에는 이미지에 서명할 수 있는 신뢰할 수 있고 승인된 항목(증명자) 지정이 포함되며 배포에 안전하다고 간주되려면 이미지에서 충족해야 하는 다른 기준이 포함될 수 있습니다.
증명자(예: 개발자 또는 자동화 시스템)는 암호화 알고리즘을 사용하여 키 쌍(비공개 및 공개 키)을 생성합니다.
보안 비밀로 유지되는 비공개 키는 이미지의 디지털 서명(즉, 고유한 문자 집합)을 생성하는 데 사용됩니다. 이 서명은 승인 역할을 합니다. 즉, 이미지가 필요한 모든 검사와 유효성 검사를 통과했다는 신호입니다.
그런 다음 디지털 서명이 이미지에 '연결'됩니다. 즉, 서명은 일반적으로 이미지 레지스트리의 이미지 메타데이터에 저장됩니다.
그런 다음 시스템에서 서명 확인에 공개 키를 사용할 수 있도록 공개 키가 Binary Authorization 시스템에 등록됩니다.
컨테이너 배포를 요청하면 Binary Authorization 시스템에서 레지스트리의 이미지에 연결된 디지털 서명을 검색합니다.
Binary Authorization 시스템은 등록된 공개 키를 사용하여 이미지에 연결된 디지털 서명을 확인합니다. 또한 이미지가 정책에 정의된 다른 모든 기준을 충족하는지 확인합니다. 공개 키와 이미지 데이터를 사용하여 디지털 서명을 성공적으로 확인할 수 있고 이미지가 정책에 정의된 다른 모든 기준을 충족하면 Binary Authorization 시스템에서 컨테이너 배포를 허용합니다. 공개 키와 이미지 데이터를 사용하여 디지털 서명을 성공적으로 확인할 수 없거나 이미지가 정책에 정의된 다른 기준을 충족하지 않으면 Binary Authorization 시스템에서 컨테이너 배포를 거부합니다.
Binary Authorization 작동 방식에 대한 자세한 내용은 Binary Authorization 개요를 참조하세요.
기존 클러스터에서 Binary Authorization을 사용 설정하거나 클러스터를 만들 때 Binary Authorization을 사용 설정하는 방법을 참조하세요.
전용 노드 풀에서 워크로드 격리
Kubernetes taint 및 톨러레이션(toleration)을 사용하여 특정 유형의 워크로드를 실행하도록 특정 노드 풀을 지정할 수 있습니다. 예를 들어 대부분의 시스템 관리 워크로드에서 사용자 워크로드를 예약하거나 서로 다른 노드 풀에 신뢰 수준이 다른 워크로드를 배치하도록 AWS용 GKE에 지시할 수 있습니다.
taint 및 톨러레이션(toleration)을 사용한 워크로드 격리는 보장된 보안 조치가 아닙니다. 이를 AWS용 GKE에서 제공하는 다른 강화 방법과 함께 사용하세요.
자세한 내용은 전용 노드 풀에서 워크로드 격리를 참조하세요.
다음 단계
- 키 순환에 대해 알아보기