Kubernetes 서비스 계정을 사용하여 Kubernetes 워크로드에 AWS에 대한 액세스 권한 부여 - Amazon EKS
서비스 계정 토큰클러스터 추가 기능Amazon Elastic Kubernetes Service 클러스터의 워크로드에 AWS ID 및 액세스 관리 권한 부여

Kubernetes 서비스 계정을 사용하여 Kubernetes 워크로드에 AWS에 대한 액세스 권한 부여

Kubernetes 서비스 계정은 Pod에서 실행되는 프로세스의 ID를 제공합니다. 자세한 내용을 알아보려면 Kubernetes 설명서의 서비스 계정 관리를 참조하세요. Pod에 AWS 서비스에 대한 액세스 권한이 필요한 경우 서비스 계정을 AWS ID 및 액세스 관리 ID에 매핑하여 해당 액세스 권한을 부여할 수 있습니다. 자세한 내용은 서비스 계정에 대한 IAM 역할 단원을 참조하십시오.

서비스 계정 토큰

BoundServiceAccountTokenVolume 기능은 Kubernetes 버전에서 기본적으로 활성화됩니다. 이 기능은 Kubernetes에서 실행되는 워크로드가 대상, 시간 및 키 바인딩인 JSON 웹 토큰을 요청하도록 허용하여 서비스 계정 토큰의 보안을 향상시킵니다. 서비스 계정 토큰에는 1시간 만료 기간이 있습니다. 이전 Kubernetes 버전에는 토큰에 만료 기간이 없었습니다. 즉, 이러한 토큰에 의존하는 클라이언트는 1시간 이내에 토큰을 새로 고쳐야 합니다. 다음 Kubernetes 클라이언트 SDK는 필요한 시간 내에 토큰을 자동으로 새로 고칩니다.

  • Go 버전 0.15.7 이상

  • Python 버전 12.0.0 이상

  • Java 버전 9.0.0 이상

  • JavaScript 버전 0.10.3 이상

  • Ruby master 브랜치

  • Haskell 버전 0.3.0.0

  • C# 버전 7.0.5 이상

워크로드가 이전 클라이언트 버전을 사용하는 경우 업데이트해야 합니다. 클라이언트가 최신 시간 바운드 서비스 계정 토큰으로 원활하게 마이그레이션되도록 Kubernetes는 기본 1시간 서비스 계정 토큰의 만료 기간을 추가로 연장합니다. Amazon EKS 클러스터의 경우 연장 만료 기간은 90일입니다. Amazon EKS 클러스터 Kubernetes API 서버는 90일이 지난 토큰을 사용한 요청을 거부합니다. 애플리케이션 및 해당 종속성을 확인하여 Kubernetes 클라이언트 SDK가 이전에 나열된 버전과 동일하거나 이후 버전인지 확인하는 것이 좋습니다.

API 서버가 1시간 이상 된 토큰으로 요청을 수신하면 API 감사 로그 이벤트에 annotations.authentication.k8s.io/stale-token으로 주석을 추가합니다. 주석의 값은 다음 예와 유사합니다.

subject: system:serviceaccount:common:fluent-bit, seconds after warning threshold: 4185802.

클러스터에 CloudWatch Logs에 컨트롤 플레인 로그 전송컨트롤 플레인 로깅이 사용 설정되어 있는 경우 주석은 감사 로그에 있습니다. 다음과 같은 CloudWatch Logs Insights 쿼리를 사용하여 Amazon EKS 클러스터에서 오래된 토큰을 사용하는 모든 Pods를 식별할 수 있습니다.

fields @timestamp
|filter @logStream like /kube-apiserver-audit/
|filter @message like /seconds after warning threshold/
|parse @message "subject: *, seconds after warning threshold:*\"" as subject, elapsedtime

subject는 Pod가 사용한 서비스 계정을 참조합니다. elapsedtime은 최신 토큰을 읽은 후 경과 시간(초)을 표시합니다. API 서버에 대한 요청은 elapsedtime이 90일(7,776,000 초)을 초과하는 경우 거부됩니다. 이전에 나열된 버전 중 하나를 사용하여 토큰을 자동으로 새로 고치도록 하려면 애플리케이션의 Kubernetes 클라이언트 SDK를 적극적으로 업데이트해야 합니다. 사용된 서비스 계정 토큰이 90일에 가까우며 토큰 만료 전에 클라이언트 SDK 버전을 업데이트할 시간이 충분하지 않은 경우 기존 Pods를 종료하고 새 포드를 생성할 수 있습니다. 이로 인해 서비스 계정 토큰을 다시 가져와서 클라이언트 버전 SDK를 업데이트하는 데 추가로 90일이 제공됩니다.

Pod가 배포의 일부인 경우 고가용성을 유지하면서 Pods를 종료하라고 제안된 방법은 다음 명령으로 롤아웃을 수행하는 것입니다. my-deployment를 배포 이름으로 바꿉니다.

kubectl rollout restart deployment/my-deployment

클러스터 추가 기능

다음 클러스터 추가 기능은 Kubernetes 클라이언트 SDK를 사용하여 서비스 계정 토큰을 자동으로 다시 가져오도록 업데이트되었습니다. 나열된 버전 또는 이후 버전이 클러스터에 설치되었는지 확인하는 것이 좋습니다.

Amazon Elastic Kubernetes Service 클러스터의 워크로드에 AWS ID 및 액세스 관리 권한 부여

Amazon EKS는 서비스 계정에 대한 IAM 역할 및 EKS Pod Identity를 통해 Amazon EKS 클러스터에서 실행되는 워크로드에 AWS ID 및 액세스 관리 권한을 부여합니다.

서비스 계정에 대한 IAM 역할

서비스 계정에 대한 IAM 역할(IRSA)은 세분화된 IAM 권한으로 AWS에서 실행되는 Kubernetes 애플리케이션을 구성하여 Amazon S3 버킷, Amazon DynamoDB 테이블 등과 같은 다양한 기타 AWS 리소스에 액세스할 수 있도록 합니다. 동일한 Amazon EKS 클러스터에서 여러 애플리케이션을 함께 실행하고 각 애플리케이션이 필요한 최소 권한 집합만 갖도록 할 수 있습니다. IRSA는 Amazon EKS, Amazon EKS Anywhere, AWS의 Red Hat OpenShift Service, Amazon EC2 인스턴스의 자체 관리형 Kubernetes 클러스터 등 AWS에서 지원하는 다양한 Kubernetes 배포 옵션을 지원하도록 구축되었습니다. 따라서 IRSA는 IAM과 같은 기본 AWS 서비스를 사용하여 빌드되었으며 Amazon EKS 서비스 및 EKS API에 대한 직접적인 종속성을 갖지 않았습니다. 자세한 내용은 서비스 계정에 대한 IAM 역할 단원을 참조하십시오.

EKS Pod Identity

EKS Pod Identity는 클러스터 관리자에게 Amazon S3 버킷, Amazon DynamoDB 테이블 등과 같은 다양한 기타 AWS 리소스에 액세스할 수 있도록 간소화된 애플리케이션 인증 워크플로를 제공합니다. EKS Pod Identity는 EKS 전용이므로 클러스터 관리자가 IAM 권한을 획득하도록 Kubernetes 애플리케이션을 구성하는 방법이 간소화됩니다. 이제 AWS Management Console, EKS API, AWS CLI를 통해 직접 몇 단계만 거치면 이러한 권한을 쉽게 구성할 수 있으며, 임의의 Kubernetes 객체에 있는 클러스터 내에서 별도의 조치를 취하지 않아도 됩니다. 클러스터 관리자는 EKS와 IAM 서비스 간에 전환하거나 권한이 있는 IAM 작업을 사용하여 애플리케이션에 필요한 권한을 구성할 필요가 없습니다. 이제 새 클러스터를 생성할 때 역할 신뢰 정책을 업데이트할 필요 없이 여러 클러스터에서 IAM 역할을 사용할 수 있습니다. EKS Pod Identity에서 제공하는 IAM 보안 인증 정보에는 클러스터 이름, 네임스페이스, 서비스 계정 이름 등의 속성이 포함된 역할 세션 태그가 포함됩니다. 관리자는 역할 세션 태그를 사용하여 일치하는 태그를 기반으로 AWS 리소스에 대한 액세스를 허용하여 여러 서비스 계정에서 작업할 수 있는 단일 역할을 작성할 수 있습니다. 자세한 내용은 EKS Pod Identity가 포드에 AWS 서비스에 대한 액세스 권한을 부여하는 방법 알아보기 단원을 참조하십시오.

EKS Pod Identity와 IRSA 비교

대략적으로 EKS Pod Identity와 IRSA 모두 Kubernetes 클러스터에서 실행되는 애플리케이션에 IAM 권한을 부여할 수 있도록 합니다. 하지만 구성 방법, 지원되는 제한 사항, 활성화된 기능 등이 근본적으로 다릅니다. 아래에서는 두 솔루션의 몇 가지 주요 측면을 비교합니다.

속성 EKS Pod Identity IRSA

역할 확장성

새로 도입된 Amazon EKS 서비스 보안 주체 pods.eks.amazonaws.com과의 신뢰를 구축하려면 각 역할을 한 번 설정해야 합니다. 이 한 번의 단계를 거친 후에는 새 클러스터에서 역할이 사용될 때마다 역할의 신뢰 정책을 업데이트할 필요가 없습니다.

새 클러스터에서 역할을 사용할 때마다 새 EKS 클러스터 OIDC 공급자 엔드포인트로 IAM 역할의 신뢰 정책을 업데이트해야 합니다.

클러스터 확장성

EKS Pod Identity의 경우 사용자가 IAM OIDC 공급자를 설정할 필요가 없으므로 이 제한은 적용되지 않습니다.

각 EKS 클러스터에는 OpenID Connect(OIDC) 발급자 URL이 연결되어 있습니다. IRSA를 사용하려면 IAM의 각 EKS 클러스터에 대해 고유한 OpenID Connect 공급자를 생성해야 합니다. IAM의 기본 글로벌 제한은 각 AWS 계정에 대해 100개의 OIDC 공급자입니다. IRSA가 있는 각 AWS 계정에 대해 100개를 초과하는 EKS 클러스터를 보유하려는 계획인 경우 IAM OIDC 공급자 한도에 도달합니다.

역할 확장성

EKS Pod Identity의 경우 사용자가 신뢰 정책에서 IAM 역할과 서비스 계정 간의 신뢰 관계를 정의할 필요가 없으므로 이 제한은 적용되지 않습니다.

IRSA에서는 역할의 신뢰 정책에서 IAM 역할과 서비스 계정 간의 신뢰 관계를 정의합니다. 기본적으로 신뢰 정책 크기의 길이는 2048입니다. 즉, 일반적으로 단일 신뢰 정책에서 4개의 신뢰 관계를 정의할 수 있습니다. 신뢰 정책 길이 제한을 늘릴 수 있지만 일반적으로 단일 신뢰 정책 내에서 최대 8개의 신뢰 관계로 제한됩니다.

역할 재사용 가능성

EKS Pod Identity에서 제공하는 AWS STS 보안 인증 정보에는 클러스터 이름, 네임스페이스, 서비스 계정 이름 등과 같은 역할 세션 태그가 포함됩니다. 역할 세션 태그를 사용하면 관리자는 연결된 태그를 기반으로 AWS 리소스에 대한 액세스를 허용함으로써 유효 권한이 다른 여러 서비스 계정에서 사용할 수 있는 단일 IAM 역할을 작성할 수 있습니다. 이를 속성 기반 액세스 제어(ABAC)라고 합니다. 자세한 내용은 태그를 기반으로 AWS 리소스에 대한 pods 액세스 제어 단원을 참조하십시오.

AWS STS 세션 태그는 지원되지 않습니다. 클러스터 간에 역할을 재사용할 수 있지만 모든 포드는 해당 역할의 모든 권한을 받습니다.

지원되는 환경

EKS Pod Identity는 Amazon EKS에서만 사용할 수 있습니다.

IRSA는 Amazon EKS, Amazon EKS Anywhere, AWS의 Red Hat OpenShift Service, Amazon EC2 인스턴스의 자체 관리형 Kubernetes 클러스터 등에서 사용할 수 있습니다.

지원되는 EKS 버전

EKS Kubernetes 버전 1.24 이상. 특정 플랫폼 버전은 EKS Pod Identity 클러스터 버전 섹션을 참조하세요.

지원되는 모든 EKS 클러스터 버전.