서비스 계정용 KIAM 대 AWS IAM 역할 (IRSA)

Kubernetes의 채택이 클라우드 네이티브 환경에서 증가함에 따라, Kubernetes 클러스터 내에서 AWS IAM 역할을 안전하게 관리하는 것은 인프라 관리의 중요한 측면이 되었습니다. KIAM과 AWS IAM Roles for Service Accounts (IRSA)는 이 요구사항을 처리하는 두 가지 인기 있는 접근 방식입니다.

이 기사에서는 두 도구의 미세한 차이를 논의하며, 기능, 아키텍처, 장점 및 단점을 비교하여 Kubernetes 환경에 대한 정보에 입각한 결정을 내리는 데 도움을 드립니다.

소개

• KIAM: AWS IAM 역할을 Kubernetes 포드에 동적으로 할당하도록 설계된 오픈 소스 솔루션으로, 포드 자체에 AWS 자격 증명을 저장하지 않습니다. KIAM은 프록시 기반 아키텍처를 사용하여 AWS 메타데이터 API 요청을 가로챕니다.
• IRSA: Kubernetes 서비스 계정을 활용하고 OpenID Connect (OIDC)를 사용하여 IAM 역할을 Kubernetes 포드와 안전하게 연관시키는 AWS의 공식 솔루션입니다. IRSA는 외부 프록시의 필요성을 없앱니다.

아키텍처 및 워크플로우

KIAM

구성 요소

• 에이전트 – 작업 노드에서 DaemonSet으로 실행되며, 포드의 AWS 메타데이터 API 호출을 가로챕니다.
• 서버 – IAM 역할 검증 및 AWS API 상호 작용을 처리하는 중앙 구성 요소입니다.

워크플로우

1. 포드 메타데이터에는 IAM 역할 주석이 포함되어 있습니다.
2. 에이전트는 메타데이터 API 호출을 가로채 서버로 전달합니다.
3. 서버는 역할을 확인하고 STS를 통해 일시적인 AWS 자격 증명을 가져옵니다.
4. 에이전트는 자격 증명을 팟의 메타데이터 응답에 삽입합니다.

IRSA

구성 요소

• IAM 역할 ARN으로 주석이 달린 Kubernetes 서비스 계정입니다.
• AWS IAM에 구성된 OIDC 식별 공급자입니다.

워크플로우

1. 서비스 계정에 IAM 역할이 주석 처리됩니다.
2. 서비스 계정을 사용하는 팟에는 프로젝트된 서비스 계정 토큰이 발급됩니다.
3. AWS STS는 OIDC 식별 공급자를 통해 토큰을 확인합니다.
4. 팟은 연관된 IAM 역할을 가정합니다.

기능 비교

장점과 단점

KIAM의 장점

1. 유연성. EKS가 아닌 Kubernetes 클러스터에서 작동합니다.
2. 입증된 유틸리티. IRSA가 소개되기 전에 널리 사용되었습니다.

KIAM의 단점

1. 성능 병목 현상. 메타데이터 가로채기는 특히 대규모 클러스터에서 지연 문제를 야기할 수 있습니다.
2. 확장성 제한. 중앙 집중형 서버가 병목 현상이 될 수 있습니다.
3. 보안 위험. 추가 프록시 계층은 공격 표면을 증가시킵니다.
4. 유지보수 부담. KIAM 구성 요소를 관리하고 업데이트해야 합니다.

IRSA의 장점

1. AWS 네이티브 통합. 네이티브 AWS 기능을 활용하여 원활한 작동이 가능합니다.
2. 개선된 보안. 인증 정보는 중개 없이 AWS STS를 통해 직접 발급됩니다.
3. 더 나은 성능. 프록시 오버헤드 없이 직접 STS 상호작용이 가능합니다.
4. 확장 가능. 분산 구조로 대규모 클러스터에 이상적입니다.

IRSA의 단점

1. AWS 전용. 멀티 클라우드 또는 혼합 환경에는 적합하지 않습니다.
2. 초기 학습 곡선. OIDC 및 서비스 계정 설정을 이해해야 합니다.

사용 사례

KIAM을 사용하는 시기

• EKS가 아닌 Kubernetes 클러스터.
• 기존 시스템이 KIAM의 특정 기능에 의존하는 시나리오.

IRSA를 사용할 때

• AWS에서 실행되는 EKS 클러스터 또는 Kubernetes 환경.
• 확장성, 높은 성능 및 유지 관리 오버헤드 감소가 필요한 사용 사례.
• 최소한의 공격 표면을 요구하는 보안 민감한 환경.

KIAM에서 IRSA로의 마이그레이션

현재 KIAM을 사용 중이고 IRSA로 마이그레이션하려는 경우, 단계별 접근 방법은 다음과 같습니다:

1. 클러스터에 OIDC 활성화

EKS에서 AWS 관리 콘솔 또는 CLI를 사용하여 OIDC 공급자를 활성화합니다.

2. 서비스 계정 주석 추가

파드의 IAM 역할 주석을 서비스 계정의 주석으로 교체합니다.

3. IAM 역할 업데이트

OIDC ID 공급자를 IAM 역할의 신뢰 정책에 추가합니다.

4. 테스트 및 검증

IRSA를 통해 역할이 올바르게 수임되는지 확인하기 위해 테스트 작업을 배포합니다.

5. KIAM 비활성화

성공적인 마이그레이션 이후 KIAM 구성 요소를 점진적으로 단계적으로 제거합니다.

마이그레이션을 위한 모범 사례

• 중요하지 않은 작업부터 시작하여 마이그레이션을 점진적으로 수행합니다.
• 생산 환경에 적용하기 전에 변경 사항을 검증하기 위해 스테이징 환경을 사용합니다.
• AWS CloudWatch 메트릭 및 로그를 모니터링하여 전환 중 잠재적인 문제를 식별합니다.
• 자동화 도구인 Terraform이나 AWS CDK와 같은 도구를 활용하여 설정 및 구성을 간소화하세요.

실제 사례

실전에서의 KIAM

• 레거시 시스템 – KIAM이 다양한 환경과 호환성을 유지하며 여전히 관련성을 가지는 비-EKS 클러스터를 사용하는 조직
• 하이브리드 워크로드 – 온프레미스 및 클라우드 플랫폼 전체에 걸쳐 워크로드를 실행하는 기업

IRSA 성공 사례

• 현대 애플리케이션 – AWS EKS 환경에서 신속한 확장 및 향상된 보안을 위해 IRSA를 활용하는 스타트업
• 기업 채택 – 네이티브 AWS 통합 및 유지보수 부담 감소를 누리는 대규모 쿠버네티스 클러스터를 보유한 기업

결론

KIAM이 과거에 혁신적인 도구였던 것과는 달리, AWS IAM 서비스 계정용 역할(IRSA)이 AWS에서 실행되는 쿠버네티스 환경에서 IAM 역할을 관리하기 위한 선호되는 솔루션으로 등장했습니다. IRSA는 네이티브 지원, 더 나은 성능, 향상된 보안 및 확장성을 제공하여 현대 클라우드 네이티브 아키텍처에 더 우수한 선택지가 되었습니다. 

AWS의 쿠버네티스 클러스터의 경우, IRSA를 기본 옵션으로 사용해야 합니다. 그러나 AWS 외부에서 작업하거나 하이브리드 환경에서 작업하는 경우에는 KIAM이나 대체 도구가 여전히 관련성이 있을 수 있습니다.

인프라 아키텍트, 데브옵스 엔지니어 및 쿠버네티스 애호가들을 위해, 이 비교 분석은 환경에 가장 적합한 솔루션을 선택하기 위해 필요한 통찰력을 제공하고 있습니다. 더 깊은 기술적 통찰력이나 실용적인 안내가 필요하다면 언제든지 연락해 주세요.