AWS EKS 의 OIDC와 IRSA 란?

1. OIDC (OpenID Connect)란?

OIDC는 OAuth 2.0 위에 구축된 인증 프로토콜입니다.
AWS에서는 EKS 클러스터를 OIDC Provider로 등록하여, Kubernetes 서비스 계정이 IAM 역할 Assume (STS:AssumeRoleWithWebIdentity)을 할 수 있도록 합니다.

-  AWS에서 OIDC가 사용되는 이유

• AWS IAM은 기본적으로 EC2나 EKS Node 단위의 권한 부여만 가능
• Pod 단위 권한 분리가 불가능 → Over-privileged risk
• 이를 해결하기 위해, Pod가 사용하는 ServiceAccount에 IAM Role을 매핑하기 위한 브릿지로 OIDC를 사용

---

2. IRSA (IAM Roles for Service Accounts)

IRSA는 Kubernetes의 ServiceAccount와 AWS IAM Role을 OIDC 기반으로 연동하여, 특정 Pod에게 AWS 리소스에 접근할 수 있는 권한을 부여하는 방법입니다.

- 동작 흐름

1. EKS 클러스터에 OIDC Provider 등록
   • AWS IAM 콘솔 또는 Terraform을 통해 EKS의 OIDC 엔드포인트를 IAM Provider로 등록
   • 예: https://oidc.eks.ap-northeast-2.amazonaws.com/id/ABCD1234EFGH
2. IAM Role 생성 + 신뢰 관계 설정
   • sts:AssumeRoleWithWebIdentity 허용
   • 조건: sub = system:serviceaccount:<namespace>:<serviceaccount_name>
     

     {
       "Effect": "Allow",
       "Principal": {
         "Federated": "arn:aws:iam::<account_id>:oidc-provider/..."
       },
       "Action": "sts:AssumeRoleWithWebIdentity",
       "Condition": {
         "StringEquals": {
           "<oidc_url>:sub": "system:serviceaccount:logging:fluent-bit"
         }
       }
     }

3. ServiceAccount에 IAM Role 연결
   • Kubernetes ServiceAccount에 다음과 같은 annotation 추가:
     

     apiVersion: v1
     kind: ServiceAccount
     metadata:
       name: fluent-bit
       namespace: logging
       annotations:
         eks.amazonaws.com/role-arn: arn:aws:iam::<account_id>:role/fluentbit-role

4. Pod가 해당 SA를 사용하면
   • OIDC 토큰이 자동 마운트되고
   • AWS SDK or CLI는 Web Identity Token을 사용해 STS를 통해 IAM Role을 Assume
   • 임시 AWS 자격증명으로 S3, CloudWatch 등 AWS 서비스에 접근

 

 

---

3. 사용 예시

예: fluent-bit가 CloudWatch Logs에 로그를 전송할 수 있도록 설정

• Pod → SA (fluent-bit)
• SA → IAM Role (fluentbit-role)
• IAM Role → logs:PutLogEvents 등 권한 포함

---

4. Terraform 예시

resource "aws_iam_role" "fluentbit" {
  name = "fluentbit-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = {
        Federated = "arn:aws:iam::${var.account_id}:oidc-provider/${module.eks.cluster_oidc_issuer}"
      }
      Action = "sts:AssumeRoleWithWebIdentity"
      Condition = {
        StringEquals = {
          "${module.eks.cluster_oidc_issuer}:sub" = "system:serviceaccount:logging:fluent-bit"
        }
      }
    }]
  })
}

resource "kubernetes_service_account" "fluentbit" {
  metadata {
    name      = "fluent-bit"
    namespace = "logging"
    annotations = {
      "eks.amazonaws.com/role-arn" = aws_iam_role.fluentbit.arn
    }
  }
}

---

5. 장점

•  Pod 단위 IAM 권한 제어 (least privilege)
•  EC2 Instance Profile 필요 없음 (보안 강화)
•  Temporary Credential 기반 → 자동 만료됨 → 보안 강화
•  서비스 분리 시 권한 격리 용이

---

6. 주의 사항

 

항목	주의할 점
OIDC Provider	EKS 삭제해도 자동 삭제되지 않음 (수동 제거 필요)
Role Condition	sub 경로 틀리면 Assume 실패
Token Mount	automountServiceAccountToken: true 설정 확인
IAM Role 재사용	하나의 Role을 여러 SA에 할당 시 sub 조건으로 제한 필요
OIDC URL	프로토콜(https://) 포함 안 하면 오류 발생

 

---

7. 확인 명령어

aws eks describe-cluster --name <cluster-name> --query "cluster.identity.oidc.issuer"

 

kubectl describe sa fluent-bit -n logging

 

kubectl exec <pod-name> -n logging -- env | grep AWS

---

요약

 

구성	요소역할
OIDC Provider	EKS가 IAM과 연동하기 위한 인증 브릿지
IAM Role	AWS 리소스 접근 권한을 정의
ServiceAccount	Pod에서 사용할 계정
IRSA	ServiceAccount와 IAM Role을 연결하는 방법

 

 

 

Cluster에 OIDC를 인증하면 node나 pod가 인증이 되는것일까?

OIDC 인증을 사용해도, EKS 클러스터의 Node나 Pod는 자동으로 인증되지 않습니다.

다시 말해, OIDC는 Kubernetes Control Plane(즉, API Server)와 AWS IAM 사이의 연결을 위한 것이지, EKS의 Node 또는 Pod 자체가 자동으로 IAM 인증을 받는 것은 아닙니다. 아래에 자세히 설명드릴게요.

---

 OIDC 인증의 대상은 "Kubernetes ServiceAccount"입니다.

 OIDC는 무엇을 인증하나?

• AWS IAM Role이 sts:AssumeRoleWithWebIdentity를 통해 OIDC Token을 가진 **Kubernetes Pod (정확히는 ServiceAccount)**가 IAM Role을 Assume할 수 있도록 허용합니다.
• 즉, Kubernetes 내부에서 실행되는 Pod가 IAM Role을 사용할 수 있게 해주는 방식입니다.

---

 그렇다면 Node나 Pod도 인증 대상인가?

 [1] Node (EC2 인스턴스)

• Node는 EC2 Role (Instance Profile)을 사용해서 AWS 리소스에 접근합니다.
• OIDC와는 무관하게 EC2 인스턴스에 할당된 IAM Role을 따릅니다.

 즉, OIDC는 Node에는 영향이 없습니다.

 [2] 일반적인 Pod

• 기본적으로 Pod는 Kubernetes default ServiceAccount를 사용하며,
  특별히 OIDC Role이 매핑되어 있지 않으면 IAM 권한을 갖지 않습니다.
• IRSA를 통해 명시적으로 OIDC 기반 Role을 연결한 Pod만 IAM 인증 가능합니다.

 다시 말해, IRSA로 연결한 Pod만 IAM 인증을 받을 수 있습니다.

---

 구조 요약

 

구성 요소	IAM 인증 방식	OIDC 관련 여부
EC2 Node	EC2 Instance Profile (IAM Role)	❌ 무관
일반 Pod	없음 (기본 SA)	❌ 무관
IRSA Pod	ServiceAccount → IAM Role (OIDC 기반)	✅ 관련 있음

 

---

 그림으로 이해하면:

[EKS Cluster]
   |
   ├── Control Plane
   |     └── <OIDC Provider 등록>
   |
   ├── Node (EC2)
   |     └── EC2 Role (별도 IAM 인증)
   |
   ├── Pod A (default SA)
   |     └── IAM 권한 없음
   |
   ├── Pod B (IRSA 사용 SA)
         └── OIDC 토큰 → STS → IAM Role Assume → AWS 접근 가능

 

 

---

 예를 들어 이런 질문이 있을 수 있습니다:

“EKS에서 OIDC Provider 설정하면 모든 Pod가 AWS 리소스를 사용할 수 있는 건가요?”

→ 아니요. OIDC는 가능한 통로만 열어주는 것이고, 실제로 **Pod에 어떤 IAM Role을 연결할지 여부는 사용자(ServiceAccount 설정)**가 결정합니다.

---

 결론

 

질문	답변
OIDC를 설정하면 Node가 인증받나요?	❌ Node는 EC2 Role로 인증
모든 Pod가 인증되나요?	❌ IRSA로 연결된 Pod만 인증
IRSA 없이 OIDC만 등록하면 뭐가 되나요?	아무 변화 없음. 권한 연결 없으면 Pod는 AWS 자원 접근 불가
ServiceAccount를 만들고 IRSA로 Role 연결해야 인증되나요?	맞음