이 페이지 개선에 도움 주기

이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 GitHub에서 이 페이지 편집 링크를 선택합니다.

EKS 클러스터 인증 기관(CA) 교체

퍼블릭 키 인프라(PKI)에서 인증 기관(CA)은 디지털 인증서를 발행하고 이에 서명하는 신뢰할 수 있는 엔터티입니다. 이러한 인증서는 자격 증명을 설정하고 Transport Layer Security(TLS)를 사용하여 시스템 간 암호화된 통신을 활성화합니다. 클라이언트가 서버에 연결되면 서버는 CA가 서명한 인증서를 제공합니다. 클라이언트는 연결을 진행하기 전에 먼저 신뢰하는 CA에 대해 서버의 인증서를 확인합니다.

Amazon Elastic Kubernetes Service(Amazon EKS)에서는 클러스터 생성 시 각 EKS 클러스터에 대해 CA가 생성됩니다. 이때 업스트림 Kubernetes와 동일한 모델을 따릅니다. 각 EKS 클러스터에는 API 서버의 인증서에 서명하는 자체 CA가 있습니다. 이를 통해 컨트롤 플레인 구성 요소, 워커 노드 및 클라이언트가 API 서버에 인증하고 EKS 클러스터에 암호화된 연결을 설정할 수 있습니다.

이러한 인증 기관(CA)에는 유효 기간이 정의되어 있습니다. CA 교체는 만료 전에 EKS 클러스터의 인증 기관을 교체하여 클러스터가 계속 작동하고 액세스할 수 있도록 하는 프로세스입니다. 이 프로세스를 자동으로 관리하는 기본 제공 보호 장치를 제공합니다. CA 교체를 직접 시작하지 않으면 기존 CA가 만료되기 전에 후속 CA를 자동으로 추가하고 활성화하여 클러스터를 계속 사용할 수 있도록 합니다.

CA 교체 중에 후속 CA가 EKS 클러스터에 추가됩니다. EKS는 모든 AWS 관리형 구성 요소(컨트롤 플레인, EKS Auto Mode 인스턴스 및 AWS Fargate 노드)에 후속 CA를 자동으로 배포합니다. 후속 CA가 활성화되기 전에 이를 신뢰하도록 사용자가 관리하는 워커 노드(비EKS Auto Mode, 비Fargate) 및 외부 클라이언트(예: kubeconfig 파일 및 CI/CD 파이프라인)를 업데이트하는 것은 사용자의 책임입니다. 후속 CA가 활성화되면 EKS 클러스터는 후속 CA를 사용하여 인증서에 서명하도록 전환됩니다. 그러면 기존 CA가 사용 중지됩니다.

CA에는 유한한 유효 기간이 있으므로 모든 EKS 클러스터에는 CA 교체가 필요합니다. 유효 기간은 클러스터의 CA가 생성된 시점에 따라 달라집니다. 자세한 내용은 자주 묻는 질문 섹션을 참조하세요. EKS 보호 장치는 교체 수명 주기 동안 클러스터 자체를 계속 사용할 수 있도록 보장하지만, 성공적인 교체는 후속 CA가 활성화된 후 연결을 유지하도록 사용자가 관리하는 워커 노드와 외부 클라이언트를 업데이트하는지에 따라 달라집니다.

다음 섹션의 API, 콘솔 경험, 알림 및 단계별 지침은 이 프로세스를 지원하도록 설계되었습니다. 책임의 전체 범위는 공동 책임 모델 섹션에서 다룹니다.

CA 교체 작동 방식

Amazon EKS에서 CA 교체는 다단계 프로세스입니다. 사용자의 작업 여부에 관계없이 전체 교체 수명 주기 동안 EKS 클러스터 가용성을 유지하기 위한 자동 보호 장치가 마련되어 있습니다. 모든 구성 요소가 연결을 유지하는 성공적인 교체를 위해서는 다음 섹션에 설명된 단계를 수행해야 합니다.

1단계: 후속 CA 추가

후속 CA가 EKS 클러스터에 추가됩니다. 이 시점에 EKS 클러스터는 기존 CA와 후속 CA를 동시에 신뢰합니다. 인증서는 기존 CA에서 계속 발급됩니다. 중단은 발생하지 않습니다.

클러스터가 활성 상태라면 AWS CLI, EKS API, 콘솔 또는 AWS CloudFormation과 같은 코드형 인프라(IaC)를 사용하여 언제든지 후속 CA를 직접 추가할 수 있습니다. 사용자가 수행하지 않으면 자동으로 추가됩니다.

후속 CA는 AWS가 EKS의 AWS 관리형 구성 요소에 대한 배포를 완료할 때까지 활성화할 수 없습니다(2단계). 지금은 업데이트해야 하는 워커 노드와 외부 클라이언트 식별을 시작해야 할 적절한 시기입니다. EKS 클러스터의 API 서버에 연결하는 모든 시스템을 식별하려는 경우 특히 여러 팀, CI/CD 파이프라인 및 모니터링 도구가 있는 환경에서 시간이 걸릴 수 있습니다. 이 프로세스를 일찍 시작하면 자체 타임라인에서 업데이트를 조정할 수 있는 유연성이 극대화됩니다.

2단계: 후속 CA 배포

후속 CA가 추가되면 AWS가 EKS 클러스터의 관리형 구성 요소(컨트롤 플레인, EKS Auto Mode 인스턴스 및 AWS Fargate 노드)를 업데이트하여 두 CA를 모두 인식하고 신뢰하도록 합니다. CA의 배포 상태를 통해 이 진행 상황을 추적할 수 있습니다. 배포가 완료될 때까지 후속 CA를 활성화할 수 없습니다.

관리형 구성 요소에 CA 배포를 완료한 후에는 관리하는 워커 노드(비EKS Auto Mode, 비Fargate)와 후속 CA를 신뢰하는 외부 클라이언트의 두 그룹을 업데이트할 책임은 사용자에게 있습니다. 이를 통해 후속 CA가 활성화된 후에도 API 서버에 계속 연결할 수 있습니다. 후속 CA를 활성화하기 전에 구성 요소를 업데이트하지 않은 경우 나머지 업데이트를 완료하는 동안 CA 롤백을 사용하여 연결을 복원할 수 있습니다.

3단계: 후속 CA 활성화

EKS의 모든 AWS 관리형 구성 요소에 후속 CA 배포를 완료한 후 후속 CA를 활성화할 수 있습니다. 자체 타임라인에 따라 후속 CA를 활성화하는 것이 좋습니다. 사용자가 관리하는 워커 노드와 외부 클라이언트를 검색하고 업데이트하여 후속 CA를 신뢰할 수 있는 충분한 시간을 확보하세요. 후속 CA를 활성화한 후 EKS 클러스터는 후속 CA에서 서명한 인증서를 발급합니다. 기존 CA는 신뢰할 수 있지만 더 이상 서명에 사용되지 않습니다. 롤백 기간은 활성화 후 제한된 기간으로 적용되며, 이때 필요한 경우 기존 CA로 되돌릴 수 있습니다. 롤백은 이후 섹션에서 자세히 다룹니다.

사용자가 관리하는 워커 노드와 클라이언트가 업데이트되었다고 확신하면 직접 후속 CA를 활성화할 수 있습니다. 그렇지 않고 만료 기한이 가까워지면 후속 CA가 자동으로 활성화됩니다.

이중 신뢰 기간

후속 CA 추가(1단계)와 기존 CA 사용 중지 사이의 시간을 이중 신뢰 기간이라고 합니다. 이 기간에 EKS 클러스터는 두 CA를 동시에 신뢰합니다. 이를 통해 교체는 중단되지 않습니다. EKS 클러스터는 두 CA에서 서명한 인증서를 수락하기 때문에 구성 요소를 점진적으로 업데이트할 수 있습니다.

이러한 이중 신뢰 기간을 통해 모든 변경 사항을 동시에 조정하지 않고도 사용자가 관리하는 모든 워커 노드와 외부 클라이언트를 식별하고 업데이트할 수 있습니다.

후속 CA의 활성화가 연결에 미치는 영향을 이해하는 것이 중요합니다. 클라이언트는 API 서버에 연결할 때 서버의 인증서가 신뢰할 수 있는 CA에 의해 서명되었는지 확인하여 서버의 ID를 확인합니다.

후속 CA가 활성화되면 API 서버는 후속 CA가 서명한 인증서를 제시합니다. 후속 CA를 포함하도록 신뢰 번들을 업데이트한 클라이언트는 정상적으로 확인 및 연결을 수행합니다. 신뢰 번들을 업데이트하지 않은 클라이언트는 서버의 인증서를 인식하지 못하며 연결을 설정할 수 없습니다.

다음 다이어그램에서는 후속 CA 활성화 후 TLS 연결 흐름을 보여줍니다.

이 때문에 후속 CA를 활성화하기 전에 워커 노드와 외부 클라이언트를 업데이트하는 것이 중요합니다. API 서버의 ID를 확인하고 연결하려면 신뢰 번들에 후속 CA가 필요합니다. 이중 신뢰 기간과 CA 롤백은 이를 완료할 시간과 안전망을 제공합니다.

공동 책임 모델

Amazon EKS에서 CA 교체는 AWS에 광범위하게 적용되는 동일한 공동 책임 모델을 따릅니다. AWS는 클라우드 인프라의 보안 및 가용성을 책임지며, 사용자는 해당 인프라 내에서 워크로드의 보안 및 구성을 책임집니다. 공동 책임이 Amazon EKS에 적용되는 방법에 대한 자세한 내용은 EKS 보안 모범 사례를 참조하세요.

CA 교체의 맥락에서 다음을 의미합니다.

AWS의 책임

사용자의 책임

사용자를 대신하여 이러한 작업을 수행할 수는 없습니다. 외부 클라이언트는 AWS 운영 경계 밖에 있습니다. EKS Auto Mode 또는 Fargate에서 관리하지 않는 워커 노드에는 시작 시 또는 사용자만 제어하는 부트스트랩 프로세스를 통해 CA 신뢰 구성이 설정됩니다. 이는 클라이언트가 자체 트러스트 스토어를 보유하고 클라이언트의 관리자만 업데이트할 수 있다는 TLS 신뢰 작동 방식과 일치합니다.

다음 섹션은 각 측면을 자세히 설명합니다. 즉, AWS가 사용자를 위해 수행하는 작업과 사용자가 수행해야 하는 작업 및 이를 수행하는 방법에 대한 단계별 지침을 제공합니다.

AWS가 사용자를 위해 수행하는 작업

AWS는 EKS 클러스터에서의 CA 교체 수명 주기 동안 다음을 관리합니다.

자동 CA 생성

자체 타임라인에 따라 후속 CA를 추가하지 않으면 EKS 클러스터의 발신 CA가 만료일에 가까워질 때 자동으로 CA가 추가됩니다. 이렇게 하면 만료 기한 전에 클라이언트를 검색하고 업데이트할 수 있는 충분한 시간을 확보하여 교체 프로세스가 시작됩니다.

컨트롤 플레인 업데이트

후속 CA를 신뢰하도록 EKS 클러스터 컨트롤 플레인을 자동으로 업데이트합니다. 후속 CA를 활성화한 후 컨트롤 플레인은 후속 CA가 서명한 인증서를 발급합니다. 컨트롤 플레인에 대해서는 별도의 조치가 필요하지 않습니다.

EKS Auto Mode 및 Fargate 업데이트

후속 CA를 신뢰하도록 EKS Auto Mode 노드와 Fargate 포드를 자동으로 업데이트합니다. 이러한 구성 요소는 AWS 완전관리형 서비스이며, CA 교체 중에 사용자의 조치가 필요하지 않습니다.

EKS 기능 업데이트

후속 CA를 신뢰하도록 EKS 기능(AWS Controllers for Kubernetes(ACK), Argo CD 및 kro(Kube 리소스 오케스트레이터))을 자동으로 업데이트합니다. 이러한 관리형 리소스는 클러스터의 API 서버와 통신하며 CA 배포 프로세스의 일부로 업데이트됩니다. EKS 기능의 관리형 리소스에는 별도의 조치가 필요하지 않습니다. 자세한 내용은 EKS 기능을 참조하세요.

배포 상태 추적

EKS 클러스터에서 관리형 구성 요소를 업데이트하는 경우 CA의 배포 상태를 통해 진행 상황을 모니터링할 수 있습니다. 이를 통해 교체 중 AWS 측에서 작업 완료 여부를 사용자에게 알려줍니다. 배포가 완료될 때까지 후속 CA를 활성화할 수 없습니다.

기본 제공 보호 장치

교체 중에 EKS 클러스터를 보호하기 위한 기본 제공 보호 장치를 제공합니다.

이러한 보호 장치를 통해 사용자의 작업 여부에 관계없이 교체 수명 주기 동안 EKS 클러스터 가용성을 유지할 수 있습니다.

알림

AWS는 CA 교체 수명 주기의 각 단계에서 사용자에게 알립니다. 알림은 AWS 상태, Cluster Insights 및 이메일을 통해 전송됩니다. 각 알림에서는 현재 상황이 어떠한지, 어떤 작업(있는 경우)이 필요한지, EKS 클러스터가 교체 타임라인의 어느 지점에 있는지 알려줍니다.

CA 교체 이벤트를 기존 모니터링 및 알림 워크플로에 통합하도록 Amazon EventBridge를 사용하여 자체 알림을 구성할 수도 있습니다.

사용자가 수행해야 할 작업과 이유

CA 교체에 성공하려면 AWS가 사용자를 대신해 도달할 수 없는 구성 요소는 사용자가 업데이트해야 합니다. 다음과 같은 크게 두 가지 카테고리로 구분됩니다.

외부 클라이언트

클러스터 외부에서 EKS 클러스터의 API 서버에 연결하는 모든 시스템입니다. 여기에는 개발자 워크스테이션, CI/CD 파이프라인(Jenkins, GitHub Actions, GitLab, ArgoCD), 모니터링 및 관찰성 도구, 자동화 스크립트, kubeconfig를 사용하여 API 서버와 통신하는 모든 애플리케이션이 포함됩니다.

이러한 시스템은 각각 자체 신뢰 구성을 유지 관리합니다. 후속 CA가 활성화되면 API 서버는 후속 CA가 서명한 인증서를 제시합니다. 후속 CA를 활성화하기 전에 후속 CA를 신뢰하도록 이러한 클라이언트를 업데이트하면 연결을 유지할 수 있습니다. 클라이언트가 누락된 경우 CA 롤백을 통해 사용자가 업데이트를 완료하는 동안 액세스를 복원할 수 있습니다.

워커 노드(비EKS Auto Mode, 비Fargate)

EKS Auto Mode 또는 Fargate에서 관리하지 않는 워커 노드에는 시작 시 또는 kubelet 부트스트랩 프로세스를 통해 CA 신뢰 구성이 설정됩니다. 이러한 노드는 후속 CA를 신뢰하도록 새로 고쳐야 합니다. 필요한 작업은 워커 노드 유형에 따라 다릅니다.

관리형 노드 그룹

노드 그룹 버전 업데이트를 수행합니다. 그러면 노드의 롤링 교체가 트리거됩니다. 새 노드는 업데이트된 CA 신뢰 구성으로 자동 부트스트랩됩니다.

Karpenter 제어 노드

드리프트 감지가 활성화된 경우 Karpenter는 구성된 드리프트 기간에 노드를 순환하고 새 노드는 수동 작업 없이 후속 CA를 선택합니다. 드리프트 감지가 비활성화되거나 긴 기간으로 설정된 경우 이러한 노드를 자체 관리형 노드와 동일하게 취급합니다.

자체 관리형 노드

노드가 업데이트된 CA 신뢰 구성으로 부트스트랩되도록 노드를 교체합니다. 이때 일반적으로 업데이트된 CA 데이터로 시작 템플릿을 업데이트하고 Auto Scaling 그룹을 통해 롤링 교체를 트리거하는 작업이 포함됩니다.

하이브리드 노드

후속 CA를 포함하도록 각 하이브리드 노드에서 신뢰 구성을 업데이트합니다. 특정 프로세스는 하이브리드 노드가 부트스트랩되는 방식과 신뢰 구성이 관리되는 방식에 따라 달라집니다.

Cluster Insights를 사용하여 EKS 클러스터에서 실행 중인 워커 노드 유형을 식별할 수 있습니다. 각 유형을 업데이트하기 위한 단계별 지침은 이후 섹션에 나와 있습니다.

워커 노드가 누락된 경우를 대비해 CA 롤백을 안전망으로 제공합니다. 그러나 후속 CA를 활성화하기 전에 모든 워커 노드를 업데이트하면 연결 중단을 완벽하게 방지합니다. 후속 CA가 활성화되기 전에 업데이트되지 않은 노드는 교체되거나 CA 롤백이 수행될 때까지 EKS 클러스터의 API 서버와의 연결이 해제됩니다.

사용자만 이 작업을 수행할 수 있는 이유

외부 클라이언트는 AWS 운영 경계 밖에 있습니다. 회사 네트워크에서 실행되는 CI/CD 파이프라인, 개발자의 노트북, 온프레미스에서 호스팅되는 모니터링 도구: AWS에는 이러한 시스템에 접근하여 신뢰 구성을 업데이트할 수 있는 메커니즘이 없습니다.

비EKS Auto Mode 워커 노드에서는 사용자가 소유한 시작 템플릿, 사용자 데이터 스크립트 또는 부트스트랩 프로세스를 통해 신뢰 구성을 제어합니다. 노드를 업데이트하려면 노드를 교체하거나 구성을 수정해야 합니다. 둘 다 인프라 내 작업입니다.

이는 현재 Kubernetes에서 사용하는 TLS 신뢰 모델의 제약 조건입니다. API 서버가 클라이언트의 신뢰 번들 업데이트 여부를 쿼리할 수 있는 프로토콜 수준 메커니즘이 없습니다. 서버는 클라이언트가 연결된 경우에만 인증서를 제시할 수 있습니다. 클라이언트가 서명하는 CA를 신뢰하면 연결에 성공합니다. 그렇지 않으면 실패합니다. AWS가 사용자를 대신하여 구성 요소의 준비 상태를 확인할 수 있는 사전 활성화 확인 경로가 없습니다.

시작하는 시점

가능한 한 빨리 외부 클라이언트를 식별하기 시작합니다. 이는 CA 교체에서 가장 시간이 많이 걸리는 부분으로, 특히 EKS 클러스터에 워크로드를 독립적으로 배포하는 여러 팀이 있는 환경에서 더욱 그렇습니다. 클라이언트 검색을 일찍 시작할수록 부담 없이 팀 간에 업데이트를 조정할 수 있는 시간이 늘어납니다.

각 유형의 클라이언트 및 워커 노드를 업데이트하는 방법에 대한 자세한 지침은 다음 섹션에 나와 있습니다.

사전 조건

CA 교체를 시작하기 전에 다음을 확인합니다.

EKS 클러스터를 관리하는 데 필요한 권한 외에는 추가 IAM 권한이 필요하지 않습니다. 현재 EKS 클러스터에 대해 EKS API를 직접 호출할 수 있는 경우 CA 교체를 수행할 수 있습니다.

시작하기

AWS CLI 또는 Amazon EKS 콘솔을 사용하여 CA 교체를 수행할 수 있습니다. AWS CLI 버전 2.x 이상을 실행 중인지 확인합니다(aws --version으로 확인).

AWS CLI 사용

다음 연습에서는 AWS CLI 및 EKS API를 사용하는 포괄적인 CA 교체 프로세스를 다룹니다.

1단계: 활성 CA 확인

EKS 클러스터에서 활성 인증 기관을 확인하세요.

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

예상 결과:

{
    "certificateAuthorities": [
        {
            "id": "a1b2c3d4-5678-90ab-cdef-example11111",
            "createdAt": "2024-01-15T10:30:00-07:00",
            "createdBy": "EKS",
            "activatedAt": "2024-01-15T10:30:00-07:00",
            "activatedBy": "EKS",
            "signingStatus": "IN_USE",
            "distributionStatus": "COMPLETE"
        }
    ]
}

그러면 EKS 클러스터가 생성될 때 생성된 CA를 표시합니다. 현재 사용 중(인증서 서명)이며 배포가 완료되었습니다(EKS의 모든 AWS 관리형 구성 요소가 신뢰함).

2단계: CA 세부 정보 및 만료일 보기

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id a1b2c3d4-5678-90ab-cdef-example11111 --region us-west-2

예상 결과:

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example11111",
        "createdAt": "2024-01-15T10:30:00-07:00",
        "createdBy": "EKS",
        "activatedAt": "2024-01-15T10:30:00-07:00",
        "activatedBy": "EKS",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "validity": {
            "notBefore": "2024-01-15T10:30:00-07:00",
            "notAfter": "2029-01-14T10:30:00-07:00"
        },
        "rollbackAvailable": false
    }
}

validity 블록은 CA가 생성된 시점(notBefore)과 CA가 만료되는 시점(notAfter)을 표시합니다. rollbackAvailable은 후속 CA를 활성화한 후 이전 CA로 되돌릴 수 있는지를 나타냅니다. EKS 클러스터에서 생성된 첫 CA의 경우 되돌릴 이전 CA가 없기 때문에 false입니다.

3단계: 후속 CA 추가

aws eks create-certificate-authority --cluster-name my-cluster --region us-west-2

그러면 EKS 클러스터에 후속 CA가 추가됩니다. 응답에는 진행 상황을 추적하는 데 사용할 수 있는 updateId가 포함됩니다.

4단계: 업데이트 추적

aws eks describe-update --name my-cluster --update-id a1b2c3d4-update-id --region us-west-2

업데이트 상태가 Successful이 될 때까지 기다리세요.

5단계: 배포 상태 확인

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

이제 두 개의 CA가 표시됩니다. 후속 CA의 상태는 signingStatus: NOT_USED이며, AWS가 EKS 클러스터의 모든 관리형 구성 요소를 업데이트한 후 distributionStatus는 IN_PROGRESS에서 COMPLETE으로 진행됩니다.

후속 CA의 배포 상태가 COMPLETE가 될 때까지 진행하지 마세요.

6단계: kubeconfig 업데이트

aws eks update-kubeconfig --name my-cluster --region us-west-2

그러면 두 CA를 모두 신뢰하도록 로컬 kubeconfig가 업데이트됩니다. 이후 kubectl 명령은 후속 CA가 활성화된 후에도 계속 작동합니다.

7단계: 사용자가 관리하는 워커 노드 및 외부 클라이언트 업데이트

자세한 내용은 다음 섹션에서 다룹니다. 사용자가 관리하는 모든 워커 노드와 외부 클라이언트가 후속 CA를 신뢰하도록 업데이트된 후 활성화를 진행하세요.

8단계: 후속 CA 활성화

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <successor-ca-id> --region us-west-2

후속 CA를 활성화한 후 EKS 클러스터는 후속 CA에서 서명한 인증서를 발급합니다. 연결을 확인하여 모든 구성 요소가 예상대로 작동하는지 확인하세요.

Amazon EKS 콘솔 사용

Amazon EKS 콘솔은 CA 교체를 위한 안내형 환경을 제공합니다. 콘솔에서 직접 CA 상태를 보고, 후속 CA를 추가하며, 배포 진행 상황을 모니터링하고, 후속 CA를 활성화할 수 있습니다.

다음 이미지에서는 활성 교체 중 Amazon EKS 콘솔의 인증 기관 세부 정보 보기를 보여줍니다. 활성 CA와 후속 CA는 모두 서명 상태, 만료 날짜 및 만료까지의 일수와 함께 표시됩니다.

다음 이미지에서는 Amazon EKS 콘솔의 교체 진행 상황 보기를 보여줍니다. 교체 프로세스의 각 단계는 현재 상태와 함께 기존 CA의 추가, 배포, 워커 노드 및 외부 클라이언트 업데이트, 활성화 및 삭제를 포함합니다.

Kubernetes 클라이언트 업데이트

후속 CA가 추가되고 AWS가 EKS 클러스터(distributionStatus: COMPLETE)의 관리형 구성 요소에 대한 배포를 완료하면 사용자가 후속 CA를 신뢰하도록 자체 구성 요소를 업데이트해야 합니다. 이 컨텍스트에서 '클라이언트'는 EKS 클러스터의 API 서버에 연결하는 모든 시스템입니다. 여기에는 로컬 kubectl 구성, CI/CD 파이프라인, 모니터링 도구, 자동화 스크립트 및 워커 노드가 포함됩니다.

EKS 클러스터(현재 및 후속 CA 모두 포함)에 대해 업데이트된 CA 데이터는 다음을 사용하여 검색할 수 있습니다.

aws eks describe-cluster --name my-cluster --region us-west-2 --query 'cluster.certificateAuthority.data' --output text

이 값을 사용하여 다음 하위 섹션에서 각 클라이언트 유형의 신뢰 구성을 업데이트합니다.

Kubeconfig(개발자 워크스테이션, CI/CD 파이프라인, 자동화)

다음을 실행하여 로컬 kubeconfig를 업데이트합니다.

aws eks update-kubeconfig --name my-cluster --region us-west-2

그러면 최신 CA 데이터가 자동으로 검색되고 kubeconfig가 업데이트됩니다. 이 kubeconfig를 사용하는 모든 시스템은 두 CA를 신뢰합니다.

자체 kubeconfig를 생성하는 CI/CD 파이프라인 및 자동화의 경우(예: EKS API를 직접 사용하거나 kubeconfig를 시크릿으로 저장) certificate-authority-data 필드를 describe-cluster에서 검색된 값으로 업데이트합니다.

관리형 노드 그룹

노드의 롤링 교체를 트리거하도록 노드 그룹 버전 업데이트를 수행합니다.

aws eks update-nodegroup-version --cluster-name my-cluster --nodegroup-name my-nodegroup --region us-west-2

새 노드는 업데이트된 CA 데이터로 자동 부트스트랩됩니다. 롤링 교체를 통해 실행 중인 워크로드를 중단하지 않고 노드를 한 번에 하나씩 교체할 수 있습니다.

사용자가 Terraform 또는 CloudFormation을 통해 노드 그룹을 관리하는 경우 CA 교체는 IaC 상태에서 드리프트를 생성하지 않습니다. CA 수명 주기는 클러스터 리소스 구성과 별도의 전용 EKS API를 통해 관리됩니다. CA 교체가 코드형 인프라와 상호 작용하는 방법에 대한 자세한 내용은 코드형 인프라 섹션을 참조하세요.

사용자 지정 AMI가 포함된 사용자 지정 시작 템플릿

노드 그룹이 사용자 지정 AMI와 함께 배포된 경우 AWS는 사용자 데이터를 병합하지 않습니다. 사용자는 업데이트된 CA 신뢰 번들을 포함하여 올바른 부트스트랩 구성을 제공해야 합니다. CA 교체 시 사용자 데이터를 업데이트하지 않으며, 후속 CA가 없는 노드는 클러스터에 조인하지 못합니다.

노드가 업데이트된 시작 템플릿에서 실행 중인지 확인

활성화를 진행하기 전에 관리형 노드 그룹의 모든 노드가 최신 시작 템플릿 버전에서 실행 중인지 확인합니다. 이 버전에는 업데이트된 CA 신뢰 번들이 포함되어야 합니다.

Karpenter 제어 노드

Karpenter NodePool에서 드리프트 감지가 활성화된 경우 Karpenter는 오래된 CA 데이터로 노드가 실행되고 있음을 자동으로 감지하고 구성된 중단 기간에 노드를 순환합니다. 새 노드는 수동 작업 없이 후속 CA를 선택합니다.

NodePool 구성에서 드리프트 감지가 활성화되어 있는지 확인하세요.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    budgets:
      - nodes: "10%"
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default

disruption이 통합 정책으로 구성된 경우 기본적으로 드리프트 감지가 활성화됩니다. Karpenter는 CA 데이터 변경을 포함하여 원하는 상태에서 드리프트된 노드를 대체합니다.

드리프트 감지가 활성화된 경우 중단 예산에서 후속 CA 활성화 날짜 이전에 모든 Karpenter 제어 노드를 교체하도록 허용하는지 확인합니다. 예산이 너무 제한적인 경우(예: 교체 비율이 낮은 짧은 유지 관리 기간) 모든 노드가 제시간에 교체되지 않을 수 있습니다.

드리프트 감지가 비활성화되거나 중단 예산에서 교체 타임라인을 초과하는 기간으로 교체를 제한하는 경우 노드를 차단 및 드레이닝하여 노드 교체를 수동으로 트리거할 수 있습니다.

kubectl cordon <node-name>
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

Karpenter는 업데이트된 CA 데이터로 부트스트랩하는 대체 노드를 프로비저닝합니다.

자체 관리형 노드

자체 관리형 노드의 경우 부트스트랩 중에 노드가 사용하는 시작 템플릿 또는 사용자 데이터 스크립트에서 CA 데이터를 업데이트해야 합니다.

새 노드는 업데이트된 CA 데이터로 부트스트랩되고 현재 및 후속 CA를 모두 신뢰합니다.

AWS Fargate 포드(EKS Fargate 시작 유형)

EKS 클러스터의 AWS Fargate 포드는 다른 EKS 데이터 플레인 시작 모드(관리형 노드 그룹, 자체 관리형 노드, Karpenter 제어 노드)와 다르게 작동합니다.

포드가 API 서버에 연결되면 두 가지 상황이 진행됩니다. 포드는 서비스 계정 토큰(API 서버에 대한 자격 증명)을 사용하여 자체 인증하고, 서버의 인증서가 신뢰할 수 있는 CA에 의해 서명되었는지 확인하여 API 서버의 자격 증명을 확인합니다. 포드의 환경에 저장된 CA 데이터를 통해 이 확인을 수행할 수 있습니다. API 서버가 포드에서 신뢰하지 않는 후속 CA에서 서명한 인증서를 제시하기 시작하면 포드는 연결을 거부합니다.

다른 EKS 데이터 플레인 시작 모드(관리형 노드 그룹, 자체 관리형 노드, Karpenter 제어 노드)에서는 CA 데이터가 노드에 상주합니다. 노드를 교체하면 새 노드가 업데이트된 CA 데이터로 부트스트랩됩니다. 새 노드에 예약된 포드는 업데이트된 CA 데이터를 수신하여 인증서에 서명한 CA에 관계없이 API 서버를 확인할 수 있습니다.

Fargate에서 각 포드는 자체 kubelet 프로세스를 사용하여 자체 전용 컴퓨팅 환경에서 실행됩니다. 이 kubelet은 포드가 생성될 때 CA 데이터로 부트스트랩됩니다. 아래에 공유 노드는 없으며, 기본 컴퓨팅에 직접 액세스할 수 없습니다.

CA 교체 중에 EKS의 AWS Fargate 노드에 대해 고객 측 작업이 필요하지 않습니다. AWS가 패치 프로세스를 통해 Fargate 노드의 포드를 자동으로 재활용합니다. 후속 CA가 추가되면 이 프로세스의 일부로 기존 Fargate 포드가 재활용됩니다. 사용자의 조치 없이도 후속 CA를 신뢰합니다. AWS는 EKS에서 AWS가 시작한 CA 활성화 타임라인보다 훨씬 앞서 후속 CA를 추가하므로, AWS가 후속 CA를 활성화할 때까지 Fargate 포드는 재활용되고 후속 CA를 신뢰하게 됩니다. Fargate 포드가 재활용을 완료할 때까지 후속 CA의 활성화를 방지하는 기본 제공 보호 장치가 있습니다.

즉, EKS 클러스터에 대한 두 관리형 데이터 플레인 옵션(EKS Auto Mode 및 Fargate) 모두 CA 교체에 대해 동일한 사용자 환경을 제공합니다. 워커 노드에 대해 고객 측 작업은 필요하지 않습니다. API 서버에 연결하는 외부 클라이언트를 업데이트하는 것은 여전히 사용자의 책임입니다.

엣지 사례입니다. 교체 타임라인(만료되기 몇 년 전에 추가된 후속 CA)을 고려할 때 대부분의 시나리오에서는 후속 CA를 활성화하기 전에 자동 패치 적용 주기가 완료됩니다. 이 보호 장치는 고객이 조기 활성화를 시도하는 드문 경우를 대비한 예방 조치로 존재합니다.

외부 클라이언트(모니터링 도구, 서드 파티 통합)

kubeconfig 또는 인증서 신뢰 구성을 사용하여 EKS 클러스터의 API 서버에 연결하는 모든 애플리케이션 또는 도구는 업데이트된 CA 데이터로 업데이트되어야 합니다. 여기에는 다음이 포함됩니다.

각각에 대해 저장된 CA 데이터를 describe-cluster의 업데이트된 값으로 바꿉니다.

클라이언트가 업데이트되었는지 확인하는 방법

클라이언트를 업데이트한 후에 여전히 API 서버와 통신할 수 있는지 확인합니다.

kubectl get nodes

명령이 성공하면 kubeconfig는 활성 CA 데이터를 신뢰합니다. 후속 CA를 활성화한 후 동일한 명령을 실행하여 지속적인 연결을 확인합니다.

코드형 인프라

드리프트를 생성하거나 IaC 구성을 변경하지 않고도 기존 코드형 인프라(IaC)에서 CA 교체를 수행할 수 있습니다.

CA 교체가 IaC 상태에 영향을 주지 않는 이유

CA 수명 주기는 EKS 클러스터 리소스 구성과 완전히 별개인 전용 EKS API(create-certificate-authority, activate-certificate-authority, delete-certificate-authority)를 통해 관리됩니다. CA 교체가 사용자에 의해 시작되는지 아니면 AWS에 의해 자동으로 시작되는지에 관계없이 EKS 클러스터 리소스의 IaC 도구로 추적되는 속성은 수정되지 않습니다.

이는 다음을 의미합니다.

describe-cluster에서 반환되는 certificateAuthority.data 필드는 읽기 전용 출력입니다. 현재 결합된 신뢰 번들(이중 신뢰 기간 중 두 CA 모두)을 반영하지만 구성 가능한 속성은 아닙니다. IaC 도구는 이를 조정 대상으로 추적하지 않습니다.

각 CA 레코드의 속성 필드(createdBy, activatedBy)를 통해 사용자가 시작한 작업과 AWS가 자동으로 시작한 작업(감사 및 변경 관리 워크플로를 지원함)을 구분할 수 있습니다.

CA 교체와 함께 CloudFormation 사용

CA 교체는 CloudFormation을 통해 AWS::EKS::Cluster 리소스의 WriteOnly 속성을 사용하여 트리거할 수 있습니다. 이 속성은 활성화를 트리거하지만 스택의 상태에 저장되지 않으므로, 이 속성 없이 수행되는 후속 스택 업데이트는 되돌리거나 비활성화하려고 시도하지 않습니다.

# Phase 1: Add to existing stack that manages your cluster
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster

이 첫 번째 스택 업데이트는 후속 CA를 클러스터에 추가합니다. 계속하기 전에 후속 CA의 배포 상태가 COMPLETE가 될 때까지 기다립니다.

# Phase 2: After distribution completes, update your existing Cluster resource to activate
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    # Update your existing Cluster resource to activate
    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster
            ActiveCertificateAuthorityId: !GetAtt NewCA.Id

이 두 번째 스택 업데이트는 후속 CA의 활성화를 트리거합니다. ActiveCertificateAuthorityId는 WriteOnly 속성이므로 읽을 때 반환되지 않으며 활성 CA가 CloudFormation 외부에서 변경되면(예: AWS에 의한 자동 활성화를 통해) CloudFormation은 드리프트를 감지하지 못합니다.

중요: CA 교체 CloudFormation 통합은 일반적인 CloudFormation 리소스와 다른 패턴을 따릅니다. EKS의 인증 기관은 자체 ARN이 설정된 독립 리소스가 아닙니다. 이는 클러스터의 인증서 수명 주기 중 일부로 존재하며, IAM 역할 정책이 상위 역할(AWS::IAM::RolePolicy)을 통해 승인되거나 EIP 연결이 인스턴스(AWS::EC2::EIPAssociation)를 통해 승인되는 방식과 마찬가지로 클러스터 자체를 통해 승인됩니다. CloudFormation을 통해 CA 교체를 관리하는 고객은 이러한 차이점을 알고 있어야 합니다.

관리형 노드 그룹 및 IaC

업데이트된 CA 신뢰 구성을 사용하여 노드를 새로 고치도록 노드 그룹 버전 업데이트를 수행하는 것은 운영 작업입니다. 새 노드는 클러스터의 활성 CA 신뢰 데이터로 자동 부트스트랩됩니다. IaC 템플릿이 시작 템플릿 또는 사용자 데이터에서 CA 데이터를 하드코딩하지 않는 경우 템플릿을 변경할 필요가 없습니다.

CA 롤백

후속 CA를 활성화한 후 사용자가 관리하는 워커 노드(비EKS Auto Mode, 비Fargate) 또는 외부 클라이언트에서 연결 문제가 발견되면 이전 CA로 롤백할 수 있습니다. 롤백하면 이전 CA가 EKS 클러스터의 서명 기관으로 다시 활성화됩니다.

CA 롤백을 사용할 수 있는 경우

CA 롤백은 다음과 같은 경우에 한해 CA 활성화 이후에 사용할 수 있습니다.

describe-certificate-authority에서 반환한 rollbackAvailable 필드를 사용하여 언제든지 CA 롤백을 사용할 수 있는지 확인할 수 있습니다.

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example22222",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "rollbackAvailable": true
    }
}

CA 롤백을 사용할 수 없는 경우

최종 자동 활성화 후에는 CA 롤백을 사용할 수 없습니다. AWS가 최종 시간(CA 만료 45일 전)에 후속 CA를 활성화하는 경우 교체를 진행해야 합니다. 최종 자동 활성화는 이전에 첫 번째 자동 활성화가 롤백된 경우에만 수행됩니다. 유효한 CA가 없는 상태에서 EKS 클러스터가 CA 만료일에 도달하지 않도록 하기 위한 최후의 수단 보호 장치로 존재합니다.

롤백 방법

롤백하려면 이전 CA를 다시 활성화합니다.

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <previous-ca-id> --region us-west-2

CA 롤백 중에 진행되는 상황

CA 롤백을 고려해야 하는 경우

CA 롤백은 후속 CA 활성화에서 이전에 포착하지 못한 연결 문제가 드러나는 상황에 대한 안전 장치입니다.

롤백 후 후속 CA를 다시 활성화하기 전에 문제를 식별하고 해결하기 위해 전체 이중 신뢰 기간을 유지합니다.

CA 롤백 없이 복구

관리형 노드 그룹을 업데이트하기 전에 후속 CA를 활성화하고, CA 롤백 기간을 더 이상 사용할 수 없는 경우(예: 최종 자동 활성화 기한 이후) 영향을 받는 노드 그룹에 대해 롤링 업데이트를 수행하여 복구할 수 있습니다. 그러나 연결 해제된 노드는 API 서버에서 포드 제거 명령을 수신할 수 없기 때문에 초기 롤링 업데이트 시도에 실패합니다.

복구 단계

고려 사항 및 제한

리전별 가용성

CA 교체는 Amazon EKS가 지원되는 모든 AWS 상용 리전에서 사용할 수 있습니다.

최대 2개의 CA

EKS 클러스터는 언제든지 최대 두 개의 CA(활성 CA와 후속 CA)를 보유할 수 있습니다. 이전 교체가 완료될 때까지 두 번째 후속 CA를 추가할 수 없습니다.

인증서 해지 없음

CA 교체는 개별 인증서 해지를 지원하지 않습니다. 이는 인증서 해지(CRL 또는 OCSP)를 구현하지 않는 업스트림 Kubernetes와 일치합니다. 교체 시 전체 CA를 대체하며, 신뢰 번들에서 제거된 후 기존 CA가 서명한 모든 인증서를 자연스럽게 무효화합니다.

AWS가 추가한 CA는 삭제할 수 없음

AWS가 자동으로 후속 CA를 추가한 경우 사용자가 이를 삭제할 수 없습니다. 이 보호 장치은 실수로 CA를 삭제하여 교체 프로세스가 중단되는 일이 발생하지 않도록 합니다. 고객이 추가한 CA는 활성 서명 CA가 아닌 한 삭제 가능합니다.

CA 유효 기간

클러스터에서 생성된 원래 CA의 유효 기간은 10년입니다. 교체 프로세스를 통해 생성된 후속 CA의 유효 기간은 5년입니다. 클러스터의 향후 모든 CA는 5년 유효 기간을 따릅니다. describe-certificate-authority를 사용하여 CA의 만료를 확인합니다.

이중 신뢰 기간의 EC2 사용자 데이터 크기

이중 신뢰 기간에 두 개의 CA 인증서(합한 크기가 약 2.8KB 또는 gzip 압축 시 약 1.9KB)가 포함되어 있기 때문에 클러스터의 신뢰 번들 크기가 증가합니다. EC2 시작 템플릿에 사용자 지정 사용자 데이터가 제공되는 워커 노드의 경우 총 사용자 데이터 크기가 EC2 사용자 데이터 제한인 16KB를 초과하지 않는지 확인합니다. 기존 사용자 데이터가 이 제한에 근접한 상황에서 두 번째 CA를 추가하면 시작 템플릿 생성이 실패하고 새 노드가 프로비저닝되지 않을 수 있습니다. 크기를 줄이려면 gzip을 사용하여 사용자 데이터 콘텐츠를 압축하는 것이 좋습니다.

CA 교체 중 버전 업그레이드

EKS 클러스터 버전 업그레이드 및 CA 교체는 독립된 작업입니다. 그러나 둘 다 동시에 수행할 수는 없습니다. CA 교체 작업이 진행 중인 경우 CA 작업이 완료될 때까지 버전 업그레이드가 거부되고 그 반대의 경우도 마찬가지입니다.

Bring Your Own CA(BYOCA)

자체 AWS 프라이빗 CA를 사용하여 EKS 클러스터의 인증서를 백업하는 작업은 현재 지원되지 않습니다.

자주 묻는 질문(FAQ)

CA 교체를 시작하려면 어떻게 해야 하나요?

시작하려면 aws eks list-certificate-authorities --cluster-name my-cluster를 실행하여 활성 CA와 만료를 확인하세요. 교체를 시작할 준비가 되면 aws eks create-certificate-authority --cluster-name my-cluster를 실행하여 후속 CA를 추가하세요. 전체 단계별 프로세스는 시작하기 섹션에서 다룹니다. Amazon EKS 콘솔을 통해 CA 교체를 수행할 수도 있습니다.

CA 교체와 관련된 비용이 있나요?

아니요. CA 교체는 모든 EKS 클러스터에서 추가 비용 없이 사용할 수 있습니다.

CA가 만료되기 전에 교체하지 않으면 어떻게 되나요?

유효한 CA가 없는 상태에서 EKS 클러스터가 CA 만료에 도달하지 못하도록 하는 자동 보호 장치가 있습니다. CA 교체를 직접 시작하지 않은 경우 AWS는 만료 전에 후속 CA를 자동으로 추가하고 활성화하여 클러스터를 계속 사용할 수 있도록 보장합니다.

그러나 성공적으로 교체하려면 사용자가 관리하는 워커 노드(비EKS Auto Mode, 비Fargate) 및 외부 클라이언트가 후속 CA를 신뢰하도록 업데이트해야 합니다. 후속 CA가 활성화되기 전에 이러한 구성 요소가 업데이트되지 않으면 API 서버에 대한 연결이 끊어집니다.

Kubernetes의 경우 CA가 만료되기 전에 교체되지 않으면 해당 CA에서 서명한 모든 인증서가 무효화됩니다. 클라이언트가 더 이상 API 서버에 연결할 수 없으며 클러스터를 사용할 수 없게 됩니다.

CA 교체를 완료하는 데 얼마나 걸리나요?

CA 교체를 완료하는 데 걸리는 전체 시간은 AWS의 자동 보호 장치와 자체 업데이트 프로세스에 따라 달라집니다.

AWS는 관리하는 항목에 대한 최종 타임라인을 제공합니다. 후속 CA는 기존 CA가 만료되기 약 2년 전에 추가됩니다. 사용자가 후속 CA를 직접 활성화하지 않으면 AWS에서 만료 약 6개월 전에 자동으로 활성화합니다. 자동 활성화 후 롤백하는 경우 만료 45일 전에 최종 자동 활성화를 수행합니다. 이러한 보호 장치를 통해 사용자의 작업 여부에 관계없이 EKS 클러스터를 계속 사용할 수 있습니다.

또한 성공적인 CA 교체는 후속 CA를 활성화하기 전에 후속 CA를 신뢰하도록 사용자가 관리하는 워커 노드(비EKS Auto Mode, 비Fargate)와 외부 클라이언트를 업데이트하는 작업에 달려 있습니다. 소요 시간은 데이터 플레인의 워커 노드 구성, 외부 클라이언트 공간, 이러한 구성 요소의 검색 및 업데이트를 수행하는 데 걸리는 시간에 따라 달라집니다.

CA 교체로 인해 클러스터 가동 중지 시간이 발생하나요?

아니요. EKS 클러스터는 전체 CA 교체 수명 주기 동안 계속 사용할 수 있습니다. 컨트롤 플레인은 모든 단계에서 요청을 계속 처리합니다. 이중 신뢰 기간에는 기존 CA와 후속 CA가 동시에 신뢰되므로 클러스터 작업을 중단하지 않고 구성 요소를 점진적으로 업데이트할 수 있습니다. 클라이언트 측 문제를 발견하여 이전 CA로 롤백한 경우 AWS는 안전 장치로 기존 CA가 만료되기 약 45일 전에 최종 롤포워드를 수행합니다.

EKS 클러스터(컨트롤 플레인)와 데이터 플레인 구성 요소를 구별하는 것이 중요합니다. 컨트롤 플레인은 AWS의 완전관리형 기능이며, 전체 교체 기간에 계속 사용할 수 있습니다.

EKS Auto Mode 및 Fargate의 경우 AWS가 워커 노드를 자동으로 업데이트합니다. 이러한 데이터 플레인 시작 모드에서 워커 노드의 연결 손실 위험은 없습니다. API 서버에 연결하는 외부 클라이언트를 업데이트하는 것은 여전히 사용자의 책임입니다.

관리형 노드 그룹, 자체 관리형 노드, Karpenter 제어 인스턴스(드리프트 감지가 활성화되지 않음) 및 하이브리드 노드의 경우 후속 CA를 활성화하기 전에 해당 노드를 교체하거나 업데이트하는 것은 사용자의 책임입니다. 교체하지 않으면 컨트롤 플레인 자체가 완전히 작동하더라도 후속 CA가 활성화된 후 해당 노드의 컨트롤 플레인 연결이 끊어집니다.

CA 교체 중에 워크로드가 중단되나요?

실행 중인 워크로드(포드)는 CA 교체 자체에 의해 중단되지 않습니다. 포드는 CA 변경의 영향을 받지 않는 클러스터 네트워크를 통해 서로 통신합니다. CA는 포드 간 트래픽이 아닌, 구성 요소와 API 서버 간 통신에 사용됩니다.

후속 CA를 신뢰하도록 워커 노드를 업데이트하는 과정에서 워커 노드를 교체해야 하는 경우(예: 롤링 업데이트를 수행하는 관리형 노드 그룹 또는 드리프트된 노드를 교체하는 Karpenter) 해당 노드의 포드는 일반 노드 교체 프로세스의 일부로 다시 예약됩니다. 이는 CA 교체의 부작용이 아니라, 노드 교체 중 표준 Kubernetes 동작입니다. 노드 교체 중에 포드가 제거되는 방식을 제어하기 위해 중요한 워크로드에서 포드 중단 예산(PDB)이 구성되어 있는지 확인합니다.

클러스터의 CA는 언제 만료되나요?

AWS CLI, EKS API 또는 Amazon EKS 콘솔을 사용하여 클러스터의 CA가 만료되는 시기를 확인할 수 있습니다. 예를 들어 다음을 실행할 수 있습니다.

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2 --query 'certificateAuthority.validity.notAfter'

aws eks list-certificate-authorities --cluster-name my-cluster를 실행하여 CA의 ID를 찾을 수 있습니다.

클러스터 CA의 유효 기간은 어떻게 되나요?

클러스터에서 생성된 원래 CA의 유효 기간은 10년입니다. 교체 프로세스를 통해 생성된 후속 CA의 유효 기간은 5년입니다. 클러스터의 향후 모든 CA는 5년 유효 기간을 따릅니다. describe-certificate-authority를 사용하여 CA의 만료를 확인할 수 있습니다.

AWS가 자동으로 시작하기 전에 직접 CA 교체를 시작할 수 있나요?

예. aws eks create-certificate-authority --cluster-name my-cluster를 사용하여 언제든지 후속 CA를 추가할 수 있습니다. AWS가 교체를 시작할 때까지 기다리지 않아도 됩니다. 일찍 시작하면 일정에 따라 워커 노드와 외부 클라이언트를 식별하고 업데이트할 수 있는 시간이 늘어납니다.

후속 CA를 활성화한 후 롤백할 수 있나요?

예, 롤백 기간이 만료되지 않은 한, 후속 CA를 활성화한 후 CA 롤백을 사용할 수 있습니다. CA 롤백은 이전 CA를 서명 기관으로 다시 활성화합니다. 최종 자동 활성화(CA 만료 45일 전) 후에는 사용할 수 없습니다. describe-certificate-authority를 사용하여 CA에서 rollbackAvailable 필드를 확인할 수 있습니다. 자세한 내용은 CA 롤백 섹션을 참조하세요.

언제 후속 CA를 활성화해도 안전한지 어떻게 알 수 있나요?

사용자가 관리하는 모든 워커 노드(비EKS Auto Mode, 비Fargate)와 외부 클라이언트가 후속 CA를 신뢰하도록 업데이트된 경우에 후속 CA를 활성화하는 것이 안전합니다. 각 클라이언트가 업데이트된 신뢰 구성을 사용하여 API 서버와 성공적으로 통신할 수 있는지 확인함으로서 이를 검증할 수 있습니다. AWS는 사용자의 외부 시스템을 볼 수 없으므로 모든 클라이언트가 준비되었다는 단일 지표를 제공하지 않습니다. 검색 프로세스를 조기에 시작하여 모든 클라이언트를 식별할 시간을 확보할 수 있습니다.

여러 클러스터에서 CA 교체 진행 상황을 모니터링하려면 어떻게 해야 하나요?

AWS CLI 또는 EKS API를 사용하여 프로그래밍 방식으로 이 작업을 수행할 수 있습니다. 각 클러스터에 대해 aws eks list-certificate-authorities를 사용합니다. 다음 필드는 플릿 수준 모니터링을 위한 상황 인식을 제공합니다.

다음 예제 스크립트에서는 클러스터 목록에서 CA 교체 상태를 확인합니다.

#!/bin/bash
CLUSTERS=("cluster-1" "cluster-2" "cluster-3")
REGION="us-west-2"

for CLUSTER in "${CLUSTERS[@]}"; do
  echo "--- $CLUSTER ---"
  aws eks list-certificate-authorities \
    --cluster-name "$CLUSTER" \
    --region "$REGION" \
    --query 'certificateAuthorities[].{Id:id,Signing:signingStatus,Distribution:distributionStatus,Expiry:validity.notAfter}' \
    --output table
done

여러 리전 및 계정을 포괄하도록 이를 확장하고, 후속 CA가 추가되었거나 작업을 기다리고 있거나 자동 활성화 기한에 근접한 클러스터를 필터링할 수 있습니다.

또한 교체 수명 주기의 각 단계에서 AWS 상태 및 이메일을 통해 클러스터별로 알림이 전송됩니다.

모든 클라이언트를 업데이트하기 전에 후속 CA를 활성화하면 어떻게 되나요?

후속 CA를 신뢰하도록 업데이트되지 않은 모든 클라이언트는 EKS 클러스터와의 연결이 끊어집니다. 후속 CA를 활성화한 후 API 서버는 후속 CA가 서명한 인증서를 제시합니다. 신뢰하지 않는 클라이언트는 TLS 확인에 실패하여 연결할 수 없습니다. 이 경우 이전 CA로 롤백하여(롤백 기간을 계속 사용할 수 있는 경우) 나머지 클라이언트를 수정하는 동안 연결을 복원할 수 있습니다.

CA 만료 기한을 놓치면 어떻게 되나요?

AWS는 이러한 일이 발생하지 않도록 방지합니다. 자동 보호 장치를 통해 유효한 CA가 없는 상태에서도 EKS 클러스터가 CA 만료에 도달하지 않습니다. 사용자가 수행하지 않은 경우 AWS는 후속 CA를 추가하고 만료 약 6개월 전에 자동으로 활성화합니다. 사용자가 첫 번째 자동 활성화 후 롤백한 경우 AWS는 만료 45일 전에 최종 롤포워드를 수행합니다. 클러스터는 계속 사용 가능합니다.

그러나 자동 활성화가 수행될 때까지 사용자가 관리하는 워커 노드(비EKS Auto Mode, 비Fargate)와 외부 클라이언트가 후속 CA를 신뢰하도록 업데이트되지 않은 경우 해당 구성 요소에서 API 서버에 대한 연결이 끊어집니다.

CA 교체 중에 클러스터에 대한 액세스 권한을 잃을 수 있나요?

EKS 클러스터(컨트롤 플레인)는 전체 CA 교체 수명 주기 동안 계속 사용할 수 있습니다. AWS 보호 장치를 통해 클러스터 자체를 사용할 수 없게 되는 상황은 발생하지 않습니다.

그러나 사용자가 관리하는 개별 클라이언트의 경우 후속 CA를 활성화하기 전에 후속 CA를 신뢰하도록 업데이트되지 않은 경우 액세스 권한을 잃을 수도 있습니다. 예를 들어 kubeconfig, CI/CD 파이프라인 또는 모니터링 도구가 여전히 기존 CA만 참조하는 경우 후속 CA가 활성화된 후 해당 클라이언트를 연결할 수 없습니다. 이 경우 CA 롤백을 통해 영향을 받는 클라이언트를 업데이트하는 동안 액세스를 복원할 수 있습니다.

포드를 다시 시작해야 하나요?

실행 중인 워크로드 포드는 CA 교체의 직접적인 영향을 받지 않습니다. 각 노드의 kubelet에서 API 서버 통신을 처리하므로 노드가 업데이트되는 한, 워크로드 포드는 중단 없이 계속 실행됩니다. 그러나 client-go는 CA 신뢰 번들을 동적으로 다시 읽지 않으므로 API 서버와 통신하는 데 client-go를 사용하는 클러스터 내 컨트롤러 및 운영자는 후속 CA를 활성화한 후 다시 시작해야 할 수도 있습니다. 특히 AWS Fargate 노드의 경우 AWS는 자동 포드 재활용 프로세스를 통해 업데이트를 자동으로 처리합니다.

교체 중에 신뢰 번들이 변경되나요?

예. CA 교체 중에 클러스터의 신뢰 번들에는 기존 CA와 후속 CA라는 두 개의 인증 기관이 동시에 포함됩니다. 이는 이중 신뢰 기간에 예상되는 동작이며, 교체 프로세스에서 모든 구성 요소에 대한 연결을 유지하는 방법입니다.

애플리케이션과 클라이언트는 단일 CA 인증서에 고정되지 않고 CA 번들을 신뢰하도록 구성되어야 합니다. CA 고정(단일 CA에 대한 엄격한 검증)은 권장되지 않습니다. 신뢰 번들이 업데이트될 때 오류가 발생하기 때문입니다. 이는 EKS 클러스터의 API 서버에 연결되는 모든 클라이언트 측 TLS 구성에 적용됩니다.

알림 타임라인이 이 설명서에서 설명하는 것과 다른 이유는 무엇인가요?

클러스터가 2018~2019년에 생성된 경우 클러스터는 조정된 타임라인에 따라 자동 알림을 수신합니다. 첫 번째 알림에는 클러스터와 관련된 날짜와 다음 단계가 포함됩니다. 표준 알림 마일스톤은 클러스터의 CA 만료 날짜를 기준으로 계산됩니다. 이 범위 내 클러스터의 경우 계산된 날짜가 이 기능의 가용성보다 앞서므로 조정된 일정이 적용됩니다.