Amazon EKS Pod Identity

AWS EKS Pod Identity의 목적은 IRSA와 동일하게 Amazon EKS(Kubernetes 클러스터)에서 애플리케이션이 IAM Role을 안전하게 사용할 수 있도록 해주는 메커니즘입니다. 하지만 최소 권한 부여 원칙을 준수한다는 점에서 IRSA(IAM Role for Service Account)와 유사하지만, OIDC 자격 증명 공급자를 사용하지 않으므로 IRSA보다 구성이 쉽고 같은 Account내에 여러 EKS 클러스터에 동일한 IAM Role을 별도의 수정 없이 적용할 수 있다는 장점이 있습니다.

EKS Pod Identity와 IRSA 비교

Pod Identity
IRSA

클러스터 확장성

IAM OIDC 공급자를 설정할 필요가 없으므로 같은 IAM Role로 여러 클러스터에 사용할 수 있습니다.

IRSA를 사용하려면 IAM의 각 EKS 클러스터에 대해 OIDC 공급자를 생성해야 합니다. IRSA가 있는 각 AWS 계정에 대해 100개를 초과하는 EKS 클러스터를 보유하려는 계획인 경우 IAM OIDC 공급자 한도에 도달합니다.

역할 확장성

Amazon EKS 서비스 보안 주체 pods.eks.amazonaws.com을 IAM Role 생성 시, 신뢰 정책을 설정합니다. 한번 생성한 이후 클러스터에서 역할이 사용될 따마다 신뢰 정책을 수정할 필요가 없습니다.

새 클러스터에서 역할을 사용할 때마다 새 EKS 클러스터 OIDC 공급자 엔드포인트로 IAM 역할의 신뢰 정책을 업데이트해야 합니다. 신뢰 정책 길이 제한을 늘릴 수 있지만 일반적으로 단일 신뢰 정책 내에서 최대 8개의 신뢰 관계로 제한됩니다.

지원 환경

Only EKS

EKS, EKS Anywhere, Read Hat OpenShift Service on AWS, Self Managed Kubernetes on EC2

EKS 지원 버전

>= 1.24

All Version

EKS Pod Identity의 동작 방식

PodIdentity Steps

  1. IAM Role 생성 및 신뢰 정책 설정

특정 Pod가 사용할 수 있는 IAM Role을 생성합니다. 이 IAM Role은 AWS 리소스에 접근할 수 있는 권한을 부여하며, Amazon EKS 서비스 보안 주체 pods.eks.amazonaws.com와 신뢰 정책을 설정합니다.

  • AssumeRole을 사용하여 임시 보안 인증 정보를 Pod에 전달하기 전에 IAM Role을 맡습니다.

  • TagSession을 사용하여 세션 태그를 AWS STS 요청에 포함합니다.

아래 예시에서는 Pod에서 AWS SecretsManager를 사용할 때, 복호화를 위해 KMS와 SecertsManager에 접근하기 위한 IAM Policy를 사용하는 예시입니다. 여기 Policy에서는 특정 Cluster, Namespace, pod이름 등을 태그로 접근 제한을 할 수 있도록 지정할 수 있습니다.

  • eks-cluster-arn

  • eks-cluster-name

  • kubernetes-namespace

  • kubernetes-service-account

  • kubernetes-pod-name

  • kubernetes-pod-uid

resource "aws_iam_role" "demo" {
  name               = "demo"
  path               = "/"
  assume_role_policy = data.aws_iam_policy_document.demo_assume_role_document.json
}

data "aws_iam_policy_document" "demo_assume_role_document" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRole", "sts:TagSession"]

    principals {
      type        = "Service"
      identifiers = ["pods.eks.amazonaws.com"]
    }
  }
}

resource "aws_iam_role_policy" "demo_kms" {
  name   = "demo-kms-decryption"
  role   = aws_iam_role.demo.id
  policy = data.aws_iam_policy_document.demo_kms.json
}

data "aws_iam_policy_document" "demo_kms" {
  statement {
    sid    = "AllowToDecryptKMSKey"
    effect = "Allow"

    actions   = ["kms:Decrypt"]
    resources = ["${var.aws_kms_arn}"]
  }
}

resource "aws_iam_role_policy" "demo_secrets_manager" {
  name   = "demo-secretsmanager-get"
  role   = aws_iam_role.demo.id
  policy = data.aws_iam_policy_document.demo_secrets_manager.json
}

data "aws_iam_policy_document" "demo_secrets_manager" {
  statement {
    effect = "Allow"
    actions = [
      "secretsmanager:ListSecrets",
      "secretsmanager:GetResourcePolicy",
      "secretsmanager:GetSecretValue",
      "secretsmanager:DescribeSecret",
      "secretsmanager:ListSecretVersionIds"
    ]
    resources = ["${data.terraform_remote_state.secretsmanager.outputs.aws_secretsmanager_id}"]
  }
}

output "demo_arn" {
  value = aws_iam_role.demo.arn
}

  1. EKS Cluster와 IAM Role 연결

위에서 생성한 IAM Role을 EKS Cluster에서 Pod Identity로 사용하기 위해 Association 과정이 필요합니다. 아래와 같이 사용하려는 EKS Cluster의 이름, Namespace, ServiceAccount, 그리고 사용하려는 IAM Role을 지정해서 Association 해줍니다.

locals {
  demo_namespace = "demo"
  demo_service_account = "demo-service-account"
}

resource "aws_eks_pod_identity_association" "demo" {
  cluster_name    = data.terraform_remote_state.vpc.outputs.eks_cluster_name
  namespace       = local.demo_namespace
  service_account = local.demo_service_account
  role_arn        = data.terraform_remote_state.iam.outputs.demo_arn
}

  1. ServiceAccount와 Pod 연동

생성한 ServiceAccount를 사용하기 위해서는 배포하는 매니페스트에 ServiceAccount를 지정해주면 됩니다. 아래 Deployment.yaml과 같이 ServiceAccount를 지정해서 배포해줍니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
  namespace: demo
spec:
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      serviceAccountName: demo-service-account
      containers:
      - name: aws-cli-test
        image: amazon/aws-cli:latest
        args: ["s3", "ls"]
      restartPolicy: Never

배포를 한 후, Pod를 조회해보면 아래와 같이 Pod Identity에서 사용하는 TOKEN FILE이 환경 변수로 잡혀있는 것을 확인해 볼 수 있습니다. 이는 위 그림에서 3번 과정에서 Pod Ideneity Webhook을 통해 Pod가 Mutating된 결과입니다. 

kubectl apply -f demo-deployment.yaml

kubectl get pods | grep demo-app
> demo-app-7f4bcb9c7-nrfhk   1/1     Running   0          3m28s

kubectl describe pod demo-app-7f4bcb9c7-nrfhk | grep AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE:
> AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE:  /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token

  1. Pod가 AWS 리소스에 접근

Pod는 AWS STS에서 받은 임시 자격 증명을 사용하여 S3, DynamoDB, Secrets Manager 등 AWS 리소스에 접근합니다. IAM 역할이 부여한 권한에 따라 리소스에 대한 작업을 수행할 수 있습니다.

Pod Identity 적용 시, 고려 사항

EKS Pod Identity에는 제한 사항이 몇가지 존재합니다.

서비스 및 환경 제한 사항

  • Fargate에서 실행되는 Linux 및 Windows Pod

  • Windows 노드에서 실행되는 모든 Pod

  • KOPS

  • Sinnet에서 운영하는 중국(베이징) 리전, NWCD에서 운영하는 중국(닝샤) 리전

  • AWS GovCloud (US)

  • AWS Outposts

  • AWS EKS Anywhere

Amazon Add-On Version

  • Amazon VPC CNI plugin for Kubernetes 1.15.5-eksbuild.1 이상

  • AWS Load Balancer Controller 2.7.0 이상

어플리케이션에서 사용 시, Library 버전 제한

PreviousAWS IRSANextKubernetes RBAC

Last updated