모든 Kubernetes API 데이터의 기본 봉투 암호화(Envelope Encryption)
모든 Kubernetes API 데이터의 기본 봉투 암호화(Envelope Encryption)
Amazon Elastic Kubernetes Service(Amazon EKS)는 Kubernetes 1.28 이상 버전을 실행하는 EKS 클러스터의 모든 Kubernetes API 데이터에 기본 봉투 암호화를 제공해요.
봉투 암호화는 Kubernetes API 서버에 저장하는 데이터를 보호해요. 예를 들어 봉투 암호화는 ConfigMaps 같은 Kubernetes 클러스터 구성에 적용돼요. 봉투 암호화는 노드나 EBS 볼륨의 데이터에는 적용되지 않아요. EKS는 이전에 Kubernetes 시크릿 암호화를 지원했으며, 이제 이 봉투 암호화가 모든 Kubernetes API 데이터로 확장됐어요.
이는 Kubernetes 애플리케이션에 심층 방어(defense-in-depth)를 구현하는 관리형 기본 환경을 제공하며, 여러분이 할 일이 없어요.
Amazon EKS는 AWS KMS(Key Management Service)를 Kubernetes KMS provider v2와 함께 사용해 AWS 소유 키로 이 추가 보안 계층을 제공하며, AWS KMS에서 자체 고객 관리형 키(CMK)를 가져올 수도 있어요.
출처: 문서
본문
봉투 암호화 이해하기
봉투 암호화는 일반 텍스트 데이터를 데이터 저장소(etcd)로 보내기 전에 데이터 암호화 키(DEK)로 암호화한 다음, 원격의 중앙 관리형 KMS 시스템(AWS KMS)에 저장된 루트 KMS 키로 DEK를 암호화하는 과정이에요. 이는 데이터를 암호화 키(DEK)로 보호한 다음, 그 DEK를 KEK(key encryption key)라고 하는 별도의 안전하게 저장된 암호화 키로 보호해 또 다른 보안 계층을 추가하는 심층 방어 전략이에요.
Amazon EKS가 KMS v2와 AWS KMS로 기본 봉투 암호화를 활성화하는 방식
Amazon EKS는 KMS v2를 사용해 관리형 Kubernetes 컨트롤 플레인의 모든 API 데이터가 etcd 데이터베이스에 저장되기 전에 기본 봉투 암호화를 구현해요.
- 시작 시 클러스터 API 서버가 비밀 시드(secret seed)와 무작위 생성 데이터를 결합해 데이터 암호화 키(DEK)를 생성해요.
- 또한 시작 시 API 서버가 KMS 플러그인에 호출해 AWS KMS의 원격 KEK(key encryption key)로 DEK 시드를 암호화해요. 이것은 API 서버 시작 시와 KEK 교체 시에 실행되는 일회성 호출이에요.
- 그러면 API 서버가 암호화된 DEK 시드를 캐시해요. 이후 API 서버는 KDF(Key Derivation Function)를 기반으로 캐시된 DEK 시드를 사용해 다른 일회용 DEK를 생성해요. 생성된 각 DEK는 etcd에 저장되기 전에 단일 Kubernetes 리소스를 암호화하는 데 한 번만 사용돼요. KMS v2에서 암호화된 캐시 DEK 시드를 사용하면 API 서버에서 Kubernetes 리소스를 암호화하는 과정이 더 성능이 좋고 비용 효율적이에요.
기본적으로 이 KEK는 AWS가 소유하지만, 선택적으로 AWS KMS에서 자체 키를 가져올 수 있어요.
아래 다이어그램은 API 서버 시작 시 DEK의 생성과 암호화를 나타내요. 아래 고수준 다이어그램은 Kubernetes 리소스가 etcd에 저장되기 전의 암호화를 나타내요.
자주 묻는 질문 (FAQ)
기본 봉투 암호화가 내 EKS 클러스터의 보안 태세를 어떻게 개선하나요?
이 기능은 메타데이터와 고객 콘텐츠가 암호화되지 않은 상태로 남아 있는 표면적과 시간을 줄여요. 기본 봉투 암호화를 사용하면 메타데이터와 고객 콘텐츠는 etcd에 저장되기 전에 잠시 kube-apiserver의 메모리에서만 암호화되지 않은 상태로 남아요. kube-apiserver의 메모리는 Nitro 시스템을 통해 보호돼요. Amazon EKS는 관리형 Kubernetes 컨트롤 플레인에 Nitro 기반 EC2 인스턴스만 사용해요. 이러한 인스턴스에는 어떤 시스템이나 사람도 메모리에 접근하지 못하게 하는 보안 통제 설계가 있어요.
이 기능을 사용하려면 어떤 Kubernetes 버전을 실행해야 하나요?
기본 봉투 암호화가 활성화되려면 Amazon EKS 클러스터가 Kubernetes 1.28 이상 버전을 실행해야 해요.
이 기능을 지원하지 않는 Kubernetes 버전을 실행해도 내 데이터는 여전히 안전한가요?
네. AWS에서 보안은 최우선 순위예요. 우리는 모든 디지털 전환과 혁신을 최고 수준의 보안 운영 관행에 기반하며 그 기준을 계속 높이는 데 헌신하고 있어요.
실행 중인 Kubernetes 버전과 무관하게 모든 EKS 클러스터에서 etcd에 저장된 모든 데이터는 디스크 수준에서 암호화돼요. EKS는 EKS 서비스가 관리하는 볼륨 암호화 키를 생성하는 루트 키를 사용해요. 또한 모든 Amazon EKS 클러스터는 클러스터별 가상 머신을 사용해 격리된 VPC에서 실행돼요. 이러한 아키텍처와 운영 보안 관행 덕분에 Amazon EKS는 SOC 1,2,3, PCI-DSS, ISO, HIPAA 적용 가능성 등 여러 규정 준수 등급과 표준을 달성했어요. 이러한 규정 준수 등급과 표준은 기본 봉투 암호화가 있든 없든 모든 EKS 클러스터에 대해 유지돼요.
봉투 암호화는 Amazon EKS에서 어떻게 동작하나요?
시작 시 클러스터 API 서버가 비밀 시드와 무작위 생성 데이터를 결합해 데이터 암호화 키(DEK)를 생성해요. 또한 시작 시 API 서버가 KMS 플러그인에 호출해 AWS KMS의 원격 KEK로 DEK를 암호화해요. 이것은 API 서버 시작 시와 KEK 교체 시에 실행되는 일회성 호출이에요. 그러면 API 서버가 암호화된 DEK 시드를 캐시해요. 이후 API 서버는 KDF를 기반으로 캐시된 DEK 시드를 사용해 다른 일회용 DEK를 생성해요. 생성된 각 DEK는 etcd에 저장되기 전에 단일 Kubernetes 리소스를 암호화하는 데 한 번만 사용돼요.
AWS KMS 통합의 상태와 정상 기능을 확인하기 위해 API 서버에서 추가 호출이 이루어진다는 점을 알아두는 것이 중요해요. 이러한 추가 상태 확인은 AWS CloudTrail에서 볼 수 있어요.
이 기능이 내 EKS 클러스터에서 동작하도록 뭔가 하거나 권한을 바꿔야 하나요?
아니요, 취할 조치가 없어요. Amazon EKS의 봉투 암호화는 이제 Kubernetes 1.28 이상 버전을 실행하는 모든 클러스터에서 활성화되는 기본 구성이에요. AWS KMS 통합은 AWS가 관리하는 Kubernetes API 서버가 설정해요. 즉 클러스터에서 KMS 암호화 사용을 시작하기 위해 권한을 구성할 필요가 없어요.
내 클러스터에 기본 봉투 암호화가 활성화되어 있는지 어떻게 알 수 있나요?
자체 CMK를 사용하도록 마이그레이션했다면 클러스터와 연결된 KMS 키의 ARN이 보여요. 또한 클러스터의 CMK 사용과 관련된 AWS CloudTrail 이벤트 로그를 볼 수 있어요.
클러스터가 AWS 소유 키를 사용한다면 이는 EKS 콘솔(키의 ARN 제외)에 자세히 표시돼요.
AWS가 Amazon EKS의 기본 봉투 암호화에 사용되는 AWS 소유 키에 접근할 수 있나요?
아니요. AWS는 Amazon EKS에서 엄격한 보안 통제를 적용해 어떤 사람도 etcd 데이터베이스의 데이터를 보호하는 데 사용되는 일반 텍스트 암호화 키에 접근하지 못하게 해요. 이러한 보안 조치는 AWS 소유 KMS 키에도 적용돼요.
기존 EKS 클러스터에 기본 봉투 암호화가 활성화되어 있나요?
Kubernetes 1.28 이상 버전으로 Amazon EKS 클러스터를 실행 중이라면 모든 Kubernetes API 데이터의 봉투 암호화가 활성화돼요. 기존 클러스터의 경우 Amazon EKS는 eks:kms-storage-migrator RBAC ClusterRole을 사용해 이전에 etcd에서 봉투 암호화되지 않았던 데이터를 이 새 암호화 상태로 마이그레이션해요.
EKS 클러스터에서 Secrets에 대해 이미 봉투 암호화를 활성화했다면 이것이 무엇을 의미하나요?
Kubernetes 시크릿을 봉투 암호화하는 데 사용했던 KMS의 기존 고객 관리형 키(CMK)가 있다면, 그 키가 클러스터의 모든 Kubernetes API 데이터 유형의 봉투 암호화를 위한 KEK로 사용돼요.
여전히 EncryptionConfig에서 resources 필드를 설정해야 하나요?
아니요. EncryptionConfig의 resources 필드는 더 이상 사용되지 않아요(deprecated). Kubernetes 1.28 이상 버전을 실행하는 클러스터의 경우 Amazon EKS는 모든 Kubernetes API 데이터를 기본적으로 봉투 암호화해요. 때문에 resources 필드는 더 이상 어떤 리소스가 암호화되는지에 영향을 주지 않아요. Amazon EKS는 하위 호환성을 위해 resources 필드를 여전히 수용하지만, 암호화 범위에는 영향을 주지 않아요.
이제 CreateCluster 또는 AssociateEncryptionConfig 요청에서 resources를 생략하거나 null 또는 빈 목록을 전달할 수 있어요. 이전에는 이 경우 InvalidParameterException을 반환했어요. 이제 Amazon EKS가 요청을 수용하고 필드를 ["secrets"]로 기본 설정해요. 따라서 API 응답은 계속 ["secrets"]를 반환하며 이는 이전 API 계약과 일치해요.
resources를 설정한다면 여전히 ["secrets"]여야 해요. EncryptionConfig를 제공할 때는 여전히 provider(KMS 키)를 제공해야 해요.
기본 봉투 암호화로 EKS 클러스터를 실행하는 데 추가 비용이 있나요?
기본 봉투 암호화에 Amazon Web Services 소유 키를 사용한다면 관리형 Kubernetes 컨트롤 플레인과 관련된 추가 비용이 없어요. 기본적으로 Kubernetes 1.28 이상 버전을 실행하는 모든 EKS 클러스터는 Amazon Web Services 소유 키를 사용해요. 다만 자체 AWS KMS 키를 사용한다면 일반 KMS 요금이 적용돼요.
클러스터에서 Kubernetes API 데이터를 암호화하기 위해 자체 AWS KMS 키를 사용하는 데 드는 비용은 얼마인가요?
KMS에 만들거나 가져온 모든 사용자 지정 키를 저장하는 데 월 1달러를 지불해요. KMS는 암호화 및 복호화 요청에 대해 요금을 부과해요. 계정당 월 20,000회 요청의 무료 등급이 있으며, 무료 등급을 초과한 10,000회 요청당 0.03달러를 지불해요. 이는 계정의 모든 KMS 사용량에 적용되므로, 클러스터에서 자체 AWS KMS 키를 사용하는 비용은 계정 내 다른 클러스터나 AWS 리소스에서 이 키를 사용하는 양의 영향을 받아요.
이제 고객 관리형 키(CMK)가 Secrets뿐 아니라 모든 Kubernetes API 데이터를 봉투 암호화하는 데 사용되므로 KMS 요금이 더 높아지나요?
아니요. KMS v2 구현은 AWS KMS에 대한 호출 수를 크게 줄여요. 이는 EKS 클러스터에서 암호화되거나 복호화되는 추가 Kubernetes 데이터와 무관하게 CMK와 관련된 비용을 줄여줘요.
위에서 자세히 설명했듯이 Kubernetes 리소스 암호화에 사용되는 생성된 DEK 시드는 원격 KEK로 암호화된 후 Kubernetes API 서버의 캐시에 로컬로 저장돼요. 암호화된 DEK 시드가 API 서버 캐시에 없으면 API 서버가 AWS KMS를 호출해 DEK 시드를 암호화해요. 그러면 API 서버가 암호화된 DEK 시드를 캐시해 KMS를 호출하지 않고 클러스터에서 향후 사용합니다. 마찬가지로 복호화 요청의 경우 API 서버는 첫 번째 복호화 요청에 대해 AWS KMS를 호출하며, 이후에는 복호화된 DEK 시드가 캐시되어 향후 복호화 작업에 사용돼요.
자세한 내용은 GitHub의 Kubernetes Enhancements에서 KEP-3299: KMS v2 Improvements를 참고하세요.
같은 CMK 키를 여러 Amazon EKS 클러스터에 사용할 수 있나요?
네. 키를 다시 사용하려면 생성 중에 ARN을 클러스터와 연결해 같은 리전의 클러스터에 연결할 수 있어요. 다만 같은 CMK를 여러 EKS 클러스터에 사용한다면 CMK의 임의 비활성화를 방지하기 위한 필수 조치를 마련해야 해요. 그렇지 않으면 여러 EKS 클러스터와 연결된 비활성화된 CMK는 해당 키에 의존하는 클러스터에 더 넓은 영향 범위를 가지게 돼요.
기본 봉투 암호화가 활성화된 후 내 CMK를 사용할 수 없게 되면 내 EKS 클러스터는 어떻게 되나요?
KMS 키를 비활성화하면 어떤 암호화 작업에도 사용할 수 없어요. 기존 CMK에 접근할 수 없으면 API 서버는 새로 생성된 Kubernetes 객체를 암호화하고 저장할 수 없으며, etcd에 저장된 이전에 암호화된 Kubernetes 객체도 복호화할 수 없어요. CMK가 비활성화되면 클러스터가 즉시 비정상/저하(unhealthy/degraded) 상태가 되며, 관련 CMK를 다시 활성화할 때까지 우리는 서비스 약속(Service Commitment)을 이행할 수 없게 돼요.
CMK가 비활성화되면 EKS 클러스터의 저하 상태와 Kubernetes 컨트롤 플레인 리소스를 성공적으로 복원하려면 비활성화 후 30일 이내에 CMK를 다시 활성화해야 한다는 알림을 받게 돼요.
비활성화/삭제된 CMK의 영향에서 내 EKS 클러스터를 어떻게 보호할 수 있나요?
EKS 클러스터를 그러한 상황에서 보호하려면 키 관리자가 최소 권한 원칙으로 IAM 정책을 사용해 KMS 키 작업에 대한 접근을 관리해 EKS 클러스터와 연결된 키의 임의 비활성화나 삭제 위험을 줄여야 해요. 또한 CloudWatch 알람을 설정해 CMK의 상태에 대한 알림을 받을 수도 있어요.
CMK를 다시 활성화하면 내 EKS 클러스터가 복원되나요?
EKS 클러스터를 성공적으로 복원하려면 CMK가 비활성화된 후 처음 30일 안에 다시 활성화할 것을 강력히 권장해요. 다만 EKS 클러스터의 성공적 복원은 클러스터가 비정상/저하 상태인 동안 발생할 수 있는 자동 Kubernetes 업그레이드로 인해 API 호환 변경을 겪는지 여부에도 달려 있어요.
CMK를 비활성화한 후 왜 내 EKS 클러스터가 비정상/저하 상태가 되나요?
EKS 컨트롤 플레인의 API 서버는 etcd에 저장되기 전에 create/update 작업 중 모든 객체를 암호화하기 위해 API 서버의 메모리에 암호화되어 캐시된 DEK 키를 사용해요. 기존 객체가 etcd에서 검색될 때 API 서버는 같은 캐시된 DEK 키를 사용해 Kubernetes 리소스 객체를 복호화해요. CMK를 비활성화해도 API 서버 메모리의 캐시된 DEK 키 때문에 API 서버는 즉각적인 영향을 보지 못해요. 다만 API 서버 인스턴스가 재시작되면 캐시된 DEK가 없으므로 암호화와 복호화 작업을 위해 AWS KMS를 호출해야 해요. CMK가 없으면 이 과정이 KMS_KEY_DISABLED 오류 코드로 실패해 API 서버가 성공적으로 부팅하지 못하게 돼요.
내 CMK를 삭제하면 내 EKS 클러스터는 어떻게 되나요?
EKS 클러스터와 연결된 CMK 키를 삭제하면 클러스터의 상태가 복구 불가능한 수준으로 저하돼요. 클러스터의 CMK가 없으면 API 서버는 더 이상 새 Kubernetes 객체를 암호화하고 저장할 수 없으며, etcd 데이터베이스에 저장된 이전에 암호화된 Kubernetes 객체도 복호화할 수 없어요. EKS 클러스터용 CMK 키는 더 이상 클러스터를 사용할 필요가 없다고 확신할 때만 삭제해야 해요.
CMK를 찾을 수 없거나(KMS_KEY_NOT_FOUND) 클러스터와 연결된 CMK의 권한 부여(grants)가 철회된 경우(KMS_GRANT_REVOKED) 클러스터를 복구할 수 없다는 점을 알아두세요. 클러스터 상태와 오류 코드에 대한 자세한 내용은 Cluster health FAQs and error codes with resolution paths를 참고하세요.
CMK를 비활성화하거나 삭제해 저하/비정상 EKS 클러스터에 대해 요금이 계속 부과되나요?
네. CMK가 비활성화되면 EKS 컨트롤 플레인을 사용할 수 없지만, AWS는 고객이 삭제할 때까지 EKS 클러스터에 할당된 전용 인프라 리소스를 계속 실행해요. 또한 그러한 상황에서는 EKS 클러스터의 정상 상태와 운영을 방해하는 것이 고객의 자발적인 행동 또는 부작위이므로 서비스 약속은 적용되지 않아요.
비활성화된 CMK 때문에 비정상/저하 상태인 내 EKS 클러스터를 자동 업그레이드할 수 있나요?
네. 다만 클러스터에 비활성화된 CMK가 있다면 이를 다시 활성화할 30일 기간이 주어져요. 이 30일 기간 동안 Kubernetes 클러스터는 자동 업그레이드되지 않아요. 다만 이 기간이 지나도 CMK를 다시 활성화하지 않으면 클러스터는 EKS의 Kubernetes 버전 수명 주기에 따라 표준 지원을 받는 다음 버전(n+1)으로 자동 업그레이드돼요.
영향을 받는 클러스터를 인지하면 비활성화된 CMK를 신속히 다시 활성화할 것을 강력히 권장해요. EKS가 이러한 영향받는 클러스터를 자동 업그레이드하지만, 특히 클러스터가 여러 번의 자동 업그레이드를 겪으면(Kubernetes API 변경과 API 서버 부트스트랩 과정의 예상치 못한 동작이 포함될 수 있으므로) 성공적으로 복구되리라는 보장은 없다는 점을 알아두는 것이 중요해요.
KMS 키 별칭(alias)을 사용할 수 있나요?
네. Amazon EKS는 KMS 키 별칭 사용을 지원해요. 별칭은 AWS KMS 키의 친숙한 이름이에요. 예를 들어 별칭을 사용하면 KMS 키를 1234abcd-12ab-34cd-56ef-1234567890ab 대신 my-key로 참조할 수 있어요.
자체 Kubernetes 백업 솔루션으로 클러스터 리소스를 계속 백업하고 복원할 수 있나요?
네. Kubernetes 클러스터 재해 복구, 데이터 마이그레이션, 데이터 보호에 Kubernetes 백업 솔루션(예: Velero)을 사용할 수 있어요. API 서버를 통해 클러스터 리소스에 접근하는 Kubernetes 백업 솔루션을 실행한다면 애플리케이션이 검색하는 모든 데이터는 클라이언트에 도달하기 전에 복호화돼요. 이를 통해 다른 Kubernetes 클러스터에서 클러스터 리소스를 복구할 수 있어요.