EKS Capabilities 보안 고려 사항
EKS Capabilities 보안 고려 사항
이 토픽은 IAM 역할 구성, Kubernetes 권한, 멀티 클러스터 배포와 교차 계정 AWS 리소스 관리를 위한 아키텍처 패턴 등 EKS Capabilities의 중요한 보안 고려 사항을 다뤄요.
EKS Capabilities는 IAM 역할, EKS access entries, Kubernetes RBAC의 조합을 사용해 AWS 서비스, 클러스터 내 Kubernetes 리소스, 그리고 AWS CodeConnections·AWS Secrets Manager·기타 AWS 서비스와의 통합에 대한 안전한 접근을 제공해요.
출처: 문서
본문
Capability IAM 역할
Capability를 만들 때 여러분을 대신해 EKS가 작업을 수행하는 데 사용하는 IAM capability 역할을 제공해요. 이 역할은 다음을 충족해야 해요.
- 클러스터 및 capability 리소스와 같은 AWS 계정에 있어야 해요
capabilities.eks.amazonaws.com서비스 보안 주체가 역할을 맡도록 허용하는 신뢰 정책이 있어야 해요- 요구 사항에 따라 capability 유형과 사용 사례에 적합한 IAM 권한을 가져야 해요. 필요한 IAM 권한에 대한 자세한 내용은 AWS CodeConnections로 Git 리포지토리 연결, AWS Secrets Manager로 애플리케이션 시크릿 관리, ACK 권한 구성을 참고하세요
특정 사용 사례에 필요한 권한 범위를 고려하고 요구 사항을 충족하는 데 필요한 권한만 부여하는 것이 모범 사례예요. 예를 들어 Kube Resource Orchestrator용 EKS Capability를 사용할 때는 IAM 권한이 전혀 필요하지 않을 수 있고, AWS Controllers for Kubernetes용 EKS Capability를 사용할 때는 하나 이상의 AWS 서비스에 대한 전체 접근을 부여할 수 있어요.
중요
일부 사용 사례는 광범위한 관리 권한이 필요할 수 있지만, 와일드카드 권한 대신 ARN과 조건 키로 특정 리소스에 대한 접근을 제한해 특정 사용 사례에 필요한 최소 IAM 권한만 부여하는 최소 권한(least privilege) 원칙을 따르세요.
capability IAM 역할 생성과 구성에 대한 자세한 내용은 Amazon EKS capability IAM 역할을 참고하세요.
EKS access entries
IAM 역할로 capability를 만들면 Amazon EKS가 해당 역할에 대한 access entry를 클러스터에 자동으로 만들어요. 이 access entry는 capability가 동작하기 위한 기본(baseline) Kubernetes 권한을 부여해요.
참고
access entries는 capability가 생성된 클러스터에 만들어져요. Argo CD 배포를 원격 클러스터로 하려면 해당 클러스터에 Argo CD capability가 애플리케이션을 배포하고 관리할 수 있는 적절한 권한의 access entries를 만들어야 해요.
access entry에는 다음이 포함돼요.
- IAM 역할 ARN(보안 주체로)
- 기본 Kubernetes 권한을 부여하는 capability별 access entry 정책
- capability 유형에 따른 적절한 범위(클러스터 전체 또는 네임스페이스 범위)
참고
Argo CD의 경우 capability 구성에 지정된 네임스페이스(기본값
argocd)에 네임스페이스 범위 권한이 부여돼요.
Capability별 기본 access entry 정책
각 capability 유형은 capability 역할에 필요한 권한을 부여하며, 다음과 같이 서로 다른 기본 access entry 정책을 설정해요.
kro
arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy(클러스터 범위)
ResourceGraphDefinitions를 watch하고 관리하며 RGD가 정의한 사용자 지정 리소스의 인스턴스를 생성할 권한을 부여해요.
ACK
arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy(클러스터 범위)
모든 네임스페이스에서 ACK 사용자 지정 리소스를 생성·읽기·업데이트·삭제할 권한을 부여해요.
Argo CD
arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy(클러스터 범위) — Argo CD가 리소스를 검색하고 클러스터 범위 객체를 관리할 수 있는 클러스터 수준 권한을 부여해요.arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy(네임스페이스 범위) — Argo CD가 애플리케이션을 배포·관리할 수 있는 네임스페이스 수준 권한을 부여해요. capability 구성에 지정된 네임스페이스(기본값argocd) 범위로 지정돼요.
자세한 내용은 access policy 권한 검토를 참고하세요.
추가 Kubernetes 권한
일부 capability는 기본 access entry 정책을 넘어 추가 Kubernetes 권한이 필요할 수 있어요. 다음 중 하나로 이러한 권한을 부여할 수 있어요.
- Access entry 정책: access entry에 추가 관리형 정책을 연결
- Kubernetes RBAC: capability의 Kubernetes 사용자에 대한
Role또는ClusterRole바인딩 생성
ACK 시크릿 읽기 권한
일부 ACK 컨트롤러는 데이터베이스 암호 같은 민감한 데이터를 검색하기 위해 Kubernetes 시크릿을 읽어야 해요. 다음 ACK 컨트롤러는 시크릿 읽기 접근이 필요해요.
acm,acmpca,documentdb,memorydb,mq,rds,secretsmanager
시크릿 읽기 권한을 부여하려면:
arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicyaccess entry 정책을 capability의 access entry에 연결- ACK 리소스가 시크릿을 참조할 특정 네임스페이스로 정책 범위를 지정하거나, 클러스터 전체 접근을 부여
중요
시크릿 읽기 권한은 access entry 정책을 연결할 때 지정한 네임스페이스 범위로 제한돼요. 이를 통해 capability가 접근할 수 있는 시크릿을 제한할 수 있어요.
kro 임의 리소스 권한
기본적으로 kro는 ResourceGraphDefinitions(RGD)와 그 인스턴스를 watch하고 관리할 수 있어요. Deployments, Services, ConfigMaps 같은 구성된 리소스(composed resources)를 관리하려면 추가 Kubernetes 권한을 구성하세요.
kro에 리소스를 생성할 권한을 부여하려면:
옵션 1: Access entry 정책
AmazonEKSAdminPolicy 또는 AmazonEKSEditPolicy 같은 미리 정의된 access entry 정책을 capability의 access entry에 연결하세요.
옵션 2: Kubernetes RBAC
capability의 Kubernetes 사용자에게 필요한 권한을 부여하는 ClusterRoleBinding을 만드세요.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kro-cluster-admin
subjects:
- kind: User
name: arn:aws:sts::111122223333:assumed-role/my-kro-role/KRO
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
참고
kro의 Kubernetes 사용자 이름은
arn:aws:sts::ACCOUNT_ID:assumed-role/ROLE_NAME/KRO패턴을 따라요. 세션 이름/KRO(대문자)는 EKS kro capability가 자동으로 설정해요.
Capability에 필요한 IAM 권한
kro (Kube Resource Orchestrator)
필요한 IAM 권한이 없어요. 연결된 정책 없이 capability 역할을 만들 수 있어요. kro는 Kubernetes RBAC 권한만 필요해요.
ACK (AWS Controllers for Kubernetes)
ACK가 생성하고 관리할 AWS 리소스를 관리할 권한이 필요해요. 요구 사항에 따라 특정 서비스, 작업, 리소스로 권한 범위를 지정해야 해요. IAM Role Selectors를 포함한 ACK 권한 구성의 자세한 내용은 ACK 권한 구성을 참고하세요.
Argo CD
기본적으로 필요한 IAM 권한이 없어요. 다음 항목에 대해 선택적 권한이 필요할 수 있어요.
- AWS Secrets Manager: Git 리포지토리 자격 증명을 Secrets Manager에 저장하는 경우
- AWS CodeConnections: Git 리포지토리 인증에 CodeConnections를 사용하는 경우
- Amazon ECR: Amazon ECR에 OCI 형식으로 저장된 Helm 차트를 사용하는 경우
보안 모범 사례
IAM 최소 권한
capability 리소스에 사용 사례에 필요한 권한만 부여하세요. 필요하다면 capability에 광범위한 관리 권한을 부여하지 못한다는 뜻은 아니에요. 그런 경우 해당 리소스에 대한 접근을 적절히 관리(govern)해야 해요.
Capability 역할:
- ACK: 가능하면 사용 사례와 요구 사항에 따라 팀이 필요한 특정 AWS 서비스와 리소스로 IAM 권한을 제한하세요
- Argo CD: 특정 Git 리포지토리와 Kubernetes 네임스페이스로 접근을 제한하세요
- kro: 신뢰 정책을 위한 capability 역할이 필요하지만 IAM 권한은 필요 없어요(클러스터 RBAC만 사용)
예를 들어 "Resource": "*" 대신 특정 리소스 또는 리소스 그룹에 대한 패턴을 지정하세요.
"Resource": [
"arn:aws:s3:::my-app-*",
"arn:aws:rds:us-west-2:111122223333:db:prod-*"
]
IAM 조건 키로 접근을 더 제한하세요.
"Condition": {
"StringEquals": {
"aws:ResourceTag/Environment": "production"
}
}
추가 IAM 구성 정보는 각 capability의 고려 사항 섹션을 참고하세요.
Argo CD 시크릿의 네임스페이스 격리
관리형 Argo CD capability는 구성된 네임스페이스(기본값: argocd) 안의 모든 Kubernetes 시크릿에 접근할 수 있어요. 최적의 보안 태세를 유지하려면 다음 네임스페이스 격리 관행을 따르세요.
- Argo CD 네임스페이스에 Argo CD 관련 시크릿만 유지하기
- Argo CD와 같은 네임스페이스에 무관한 애플리케이션 시크릿을 저장하지 않기
- Argo CD 작업에 필요하지 않은 애플리케이션 시크릿은 별도의 네임스페이스 사용하기
이 격리는 Argo CD의 시크릿 접근이 Git 리포지토리 인증과 기타 Argo CD 특정 작업에 필요한 자격 증명으로만 제한되도록 보장해요.
Kubernetes RBAC
capability 리소스를 만들고 관리할 수 있는 사용자와 서비스 계정을 제어하세요. 적절한 RBAC 정책으로 전용 네임스페이스에 capability 리소스를 배포하는 것이 모범 사례예요.
예시: app-team 네임스페이스에서 S3 버킷 리소스 관리를 허용하는 ACK 작업용 RBAC Role:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: ack-s3-manager
namespace: app-team
rules:
- apiGroups: ["s3.services.k8s.aws"]
resources: ["buckets"]
verbs: ["get", "list", "create", "update", "delete"]
감사 로깅
- CloudTrail: 모든 EKS Capability API 작업(create, update, delete)이 AWS CloudTrail에 기록돼요.
CloudTrail 로깅을 활성화해 다음을 추적하세요.
- 누가 capability를 만들거나 수정했는지
- capability 구성이 언제 변경되었는지
- 어떤 capability 역할이 사용 중인지
네트워크 접근 및 VPC 엔드포인트
프라이빗 Argo CD API 접근
호스팅된 Argo CD 엔드포인트에 하나 이상의 VPC 엔드포인트를 연결해 Argo CD API 서버에 대한 접근을 제한할 수 있어요. 이렇게 하면 공용 인터넷을 거치지 않고 VPC 안에서 프라이빗 연결이 가능해요. VPC 엔드포인트는 Argo CD 웹 UI와 Argo CD API(CLI 접근 포함) 모두에 접근을 제공해요.
참고
호스팅된 Argo CD API 엔드포인트(eks-capabilities.
region.amazonaws.com 사용)에 연결된 VPC 엔드포인트는 VPC 엔드포인트 정책을 지원하지 않아요.
프라이빗 클러스터로 배포
Argo CD capability는 완전히 프라이빗한 EKS 클러스터에도 애플리케이션을 배포할 수 있어서, VPC 피어링이나 복잡한 네트워킹 구성이 필요 없어지는 상당한 운영상 이점을 제공해요. 다만 이 아키텍처를 설계할 때 Argo CD가 Git 리포지토리(공개일 수 있음)에서 구성을 가져와 프라이빗 클러스터에 적용한다는 점을 고려하세요.
다음을 확인하세요.
- 민감한 워크로드에는 프라이빗 Git 리포지토리 사용하기
- 적절한 Git 리포지토리 접근 통제와 인증 구현하기
- 병합 전에 pull request를 통해 변경 사항 검토·승인하기
- 배포가 발생할 시점을 제어하기 위해 Argo CD의 sync windows 사용 고려하기
- 무단 구성 변경을 위해 Argo CD 감사 로그 모니터링하기
규정 준수
EKS Capabilities는 완전히 관리되며 Amazon EKS의 규정 준수 인증을 가져요.
현재 규정 준수 정보는 AWS Services in Scope by Compliance Program을 참고하세요.
다음 단계
- ACK 권한 구성 – ACK용 IAM 권한 구성
- kro 권한 구성 – kro용 Kubernetes RBAC 구성
- Argo CD 권한 구성 – Argo CD용 Identity Center 통합 구성
- EKS Capabilities 문제 해결 – 보안 및 권한 문제 해결