클러스터 액세스 관리

Amazon EKS 클러스터의 보안 및 무결성을 유지하려면 효과적인 액세스 관리가 중요합니다. 이 가이드에서는 AWS IAM Identity Center(이전 AWS SSO) 사용에 중점을 두고 EKS 액세스 관리를 위한 다양한 옵션을 살펴봅니다. 다양한 접근 방식을 비교하고, 장단점을 설명하고, 알려진 제한 사항과 고려 사항을 강조해 보겠습니다.

EKS 액세스 관리 옵션

참고

ConfigMap 기반 액세스 관리(aws-auth ConfigMap)는 더 이상 사용되지 않으며 Cluster Access Management(CAM) API로 대체됩니다. 새 EKS 클러스터의 경우 CAM API를 구현하여 클러스터 액세스를 관리합니다. aws-auth ConfigMap을 사용하는 기존 클러스터의 경우 CAM API를 사용하여 로 마이그레이션합니다.

옵션 1: 클러스터 액세스 관리(CAM) API를 사용하는 AWS IAM Identity Center

• 중앙 집중식 사용자 및 권한 관리

• 기존 자격 증명 공급자와의 통합(예: Microsoft AD,Okta, PingId 등)

• CAM API는 액세스 항목을 사용하여 AWS IAM 보안 주체(사용자 또는 역할)를 EKS 클러스터에 연결합니다. 이러한 항목은 IAM Identity Center의 관리형 자격 증명과 함께 작동하므로 관리자가 Identity Center에 정의된 사용자 및 그룹에 대한 클러스터 액세스를 제어할 수 있습니다.

EKS 클러스터 인증 흐름:

1. 보안 주체(인간 사용자) 또는 자동화된 프로세스는 적절한 AWS 계정 권한을 제공하여 AWS IAM을 통해 인증합니다. 이 단계에서는 적절한 AWS IAM 보안 주체(역할 또는 사용자)에 매핑됩니다.

2. 다음으로 EKS 액세스 항목은 Kubernetes 권한만 포함하는 적절한 액세스 정책을 정의하여이 IAM 보안 주체를 Kubernetes RBAC 보안 주체(사용자 또는 그룹)에 매핑합니다.

3. Kubernetes 최종 사용자가 클러스터에 액세스하려고 하면 인증 요청은 aws-iam-authenticator 또는 AWS EKS CLI에서 처리되고 kubeconfig 파일의 클러스터 컨텍스트에 대해 검증됩니다.

4. 마지막으로 EKS 권한 부여자는 인증된 사용자의 액세스 항목과 연결된 권한을 확인하고 그에 따라 액세스를 부여하거나 거부합니다.

   • API는 Amazon EKS별 액세스 정책을 사용하여 각 액세스 항목에 대한 권한 부여 수준을 정의합니다. 이러한 정책을 IAM Identity Center에 설정된 역할 및 권한에 매핑하여 AWS 서비스 및 EKS 클러스터에서 일관된 액세스 제어를 보장할 수 있습니다.

ConfigMap 기반 액세스 관리의 이점:

1. 잘못된 구성의 위험 감소: 직접 API 기반 관리는 수동 ConfigMap 편집과 관련된 일반적인 오류를 제거합니다. 이렇게 하면 클러스터에서 사용자를 잠글 수 있는 실수로 인한 삭제 또는 구문 오류를 방지하는 데 도움이 됩니다.

2. 향상된 최소 권한 원칙: 클러스터 생성자 자격 증명에서 클러스터 관리자 권한이 필요하지 않으며 보다 세분화되고 적절한 권한 할당을 허용합니다. 휴지통 사용 사례에 대해이 권한을 추가하도록 선택할 수 있습니다.

3. 향상된 보안 모델: 액세스 항목을 적용하기 전에 기본적으로 검증합니다. 또한는 인증을 위해 AWS IAM과의 통합을 강화합니다.

4. 간소화된 작업: AWS 네이티브 도구를 통해 권한을 관리하는 보다 직관적인 방법을 제공합니다.

모범 사례:

1. AWS Organizations를 사용하여 여러 계정을 관리하고 서비스 제어 정책(SCPs 적용합니다.

2. 다양한 EKS 역할(예: 관리자, 개발자, 읽기 전용)에 대한 특정 권한 세트를 생성하여 최소 권한 원칙을 구현합니다.

3. ABAC(속성 기반 액세스 제어)를 활용하여 사용자 속성을 기반으로 포드에 권한을 동적으로 할당합니다.

4. 액세스 권한을 정기적으로 감사하고 검토합니다.

고려 사항/제한 사항:

1. Identity Center에서 생성한 역할 ARNs에는 임의의 접미사가 있으므로 정적 구성에서 사용하기가 어렵습니다.

2. Kubernetes 리소스 수준에서 세분화된 권한에 대한 제한된 지원. 사용자 지정 Kubernetes RBAC 역할에는 추가 구성이 필요합니다. Kubernetes 네이티브 RBAC와 함께 EKS 클러스터의 고급 권한 관리에 Kyverno를 사용하는 것이 좋습니다.

옵션 2: Kubernetes 그룹에 매핑된 AWS IAM 사용자/역할

장점:

1. IAM 권한에 대한 세분화된 제어.

2. 예측 가능한 정적 역할 ARNs

단점:

1. 사용자 계정의 관리 오버헤드 증가

2. 중앙 집중식 ID 관리 부족

3. IAM 개체의 확산 가능성

모범 사례:

1. 보안 및 관리 용이성을 높이기 위해 IAM 사용자 대신 IAM 역할 사용

2. 역할에 대한 이름 지정 규칙을 구현하여 일관성과 관리 용이성 보장

3. IAM 정책 조건을 활용하여 태그 또는 기타 속성을 기반으로 액세스를 제한합니다.

4. 액세스 키를 정기적으로 교체하고 권한을 검토합니다.

고려 사항/제한 사항:

1. 많은 수의 사용자 또는 역할 관리 시 확장성 문제

2. 기본 제공 Single Sign-On 기능 없음

옵션 3: OIDC 공급자

장점:

1. 기존 자격 증명 관리 시스템과의 통합

2. 사용자 계정의 관리 오버헤드 감소

단점:

1. 추가 구성 복잡성

2. 인증 중 지연 시간 증가 가능성

3. 외부 자격 증명 공급자에 대한 종속성

모범 사례:

1. 보안 토큰 검증을 보장하도록 OIDC 공급자를 신중하게 구성합니다.

2. 수명이 짧은 토큰을 사용하고 토큰 새로 고침 메커니즘을 구현합니다.

3. OIDC 구성을 정기적으로 감사하고 업데이트합니다.

외부 Single Sign-On 공급자를 Amazon EKS와 통합하는 참조 구현을 보려면이 가이드를 검토하세요.

고려 사항/제한 사항:

1. IAM에 비해 AWS 서비스와의 기본 통합이 제한적입니다.

2. EKS가 서명 키를 검색하려면 OIDC 공급자의 발급자 URL에 공개적으로 액세스할 수 있어야 합니다.

워크로드에 대한 AWS EKS Pod Identity와 IRSA 비교

Amazon EKS는 Amazon EKS 클러스터에서 실행되는 워크로드에 AWS IAM 권한을 부여하는 두 가지 방법, 즉 서비스 계정에 대한 IAM 역할(IRSA)과 EKS Pod Identity를 제공합니다.

IRSA와 EKS Pod Identity는 모두 최소 권한 액세스, 자격 증명 격리 및 감사 가능성의 이점을 제공하지만 EKS Pod Identity는 워크로드에 권한을 부여하는 권장 방법입니다.

EKS 포드의 자격 증명 및 자격 증명에 대한 자세한 지침은 보안 모범 사례의 자격 증명 및 자격 증명 섹션을 참조하세요.

권장 사항

IAM Identity Center와 CAM API 결합

• 간소화된 관리: 클러스터 액세스 관리 API를 IAM Identity Center와 함께 사용하면 관리자가 다른 AWS 서비스와 함께 EKS 클러스터 액세스를 관리할 수 있으므로 다른 인터페이스 간에 전환하거나 ConfigMaps 수동으로 편집할 필요가 줄어듭니다.

• 액세스 항목을 사용하여 클러스터 외부에서 IAM 위탁자의 Kubernetes 권한을 관리합니다. EKS API, AWS 명령줄 인터페이스, AWS SDKs, AWS CloudFormation 및 AWS Management Console을 사용하여 클러스터에 대한 액세스를 추가하고 관리할 수 있습니다. 즉, 클러스터를 생성할 때 사용한 것과 동일한 도구로 사용자를 관리할 수 있습니다.

• 세분화된 Kubernetes 권한은 액세스 항목 및 액세스 정책을 통해 Kubernetes 사용자 또는 그룹을 SSO 자격 증명과 연결된 IAM 보안 주체와 매핑하여 적용할 수 있습니다.

• 시작하려면 인증 모드를 액세스 항목을 사용하도록 변경에 따라 기존 aws-auth ConfigMap 항목을 액세스 항목으로 마이그레이션합니다.