EKS에서 Cluster의 IAM role과 Service account IAM role

EKS 사용시 적용할 수 있는 권한체계는 2가지가 있다. 하나는 Cluster에 적용하는 리소스 기반 정책과 IAM Role Service Account(IRSA)를 사용해 Cluster 내 Service Account에 IAM Role을 연동하는 OIDC 방식이 존재한다.

 

Cluster에 적용해서 AWS 리소스에 접근하든, Service Account로 접근하든 AWS 리소스에 액세스 하는 것은 마찬가지인데 왜 둘이 나눠져 있는 것인지 의문이 들어 확인해보고 정리한다.

EKS cluster를 생성할 때, Cluster가 AWS에 액세스 할 수 있도록 Cluster에 role을 지정할 수 있다.

아래 문서를 보면 Cluster 생성 시 AmazonEKSClusterPolicy 정책이 포함된 role을 지정하도록 되어있다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/getting-started-console.html

 

AmazonEKSClusterPolicy에 포함되어 있는 권한 목록은 다음과 같다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:UpdateAutoScalingGroup",
                "ec2:AttachVolume",
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:CreateRoute",
                "ec2:CreateSecurityGroup",
                "ec2:CreateTags",
                "ec2:CreateVolume",
                "ec2:DeleteRoute",
                "ec2:DeleteSecurityGroup",
                "ec2:DeleteVolume",
                "ec2:DescribeInstances",
                "ec2:DescribeRouteTables",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSubnets",
                "ec2:DescribeVolumes",
                "ec2:DescribeVolumesModifications",
                "ec2:DescribeVpcs",
                "ec2:DescribeDhcpOptions",
                "ec2:DescribeNetworkInterfaces",
                "ec2:DetachVolume",
                "ec2:ModifyInstanceAttribute",
                "ec2:ModifyVolume",
                "ec2:RevokeSecurityGroupIngress",
                "ec2:DescribeAccountAttributes",
                "ec2:DescribeAddresses",
                "ec2:DescribeInternetGateways",
                "elasticloadbalancing:AddTags",
                "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
                "elasticloadbalancing:AttachLoadBalancerToSubnets",
                "elasticloadbalancing:ConfigureHealthCheck",
                "elasticloadbalancing:CreateListener",
                "elasticloadbalancing:CreateLoadBalancer",
                "elasticloadbalancing:CreateLoadBalancerListeners",
                "elasticloadbalancing:CreateLoadBalancerPolicy",
                "elasticloadbalancing:CreateTargetGroup",
                "elasticloadbalancing:DeleteListener",
                "elasticloadbalancing:DeleteLoadBalancer",
                "elasticloadbalancing:DeleteLoadBalancerListeners",
                "elasticloadbalancing:DeleteTargetGroup",
                "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
                "elasticloadbalancing:DeregisterTargets",
                "elasticloadbalancing:DescribeListeners",
                "elasticloadbalancing:DescribeLoadBalancerAttributes",
                "elasticloadbalancing:DescribeLoadBalancerPolicies",
                "elasticloadbalancing:DescribeLoadBalancers",
                "elasticloadbalancing:DescribeTargetGroupAttributes",
                "elasticloadbalancing:DescribeTargetGroups",
                "elasticloadbalancing:DescribeTargetHealth",
                "elasticloadbalancing:DetachLoadBalancerFromSubnets",
                "elasticloadbalancing:ModifyListener",
                "elasticloadbalancing:ModifyLoadBalancerAttributes",
                "elasticloadbalancing:ModifyTargetGroup",
                "elasticloadbalancing:ModifyTargetGroupAttributes",
                "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
                "elasticloadbalancing:RegisterTargets",
                "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
                "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
                "kms:DescribeKey"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "iam:CreateServiceLinkedRole",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:AWSServiceName": "elasticloadbalancing.amazonaws.com"
                }
            }
        }
    ]
}

요약하면 다음과 같다.

• Auto-Scaling 정보가져오기/구성 업데이트
• EC2 Volume 편집
• Security Group 편집
• 라우팅 테이블에 라우팅 편집
• EC2 태그 추가
• ELB 태그/보안그룹/서브넷/상태확인/리스너/타겟그룹/정책 편집
• ELB 편집
• KMS 정보 가져오기
• ELB에 연결된 역할 생성

아래 네트워크 및 보안드룹 사전조건을 보면 Cluster 생성 시 Cluster와 VPC간 통신을 위해 네트워크 인터페이스를 생성하고 소스를 자신으로 하는 전체허용 Ingress 규칙과 전체 아웃바운드 허용 규칙이 포함된 보안그룹을 하나 생성한다.

• https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/network_reqs.html
• https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/sec-group-reqs.html

또한 In-tree Service Controller에 의해 로드밸런서가 생성될 경우 Cluster에 의해 ELB가 생성되어야 하므로 AmazonEKSClusterPolicy 내의 ELB 권한이 필요하고, 노드 그룹(Auto-Scaling)이나 노드(EC2)도 Cluster에 의해 생성되어야 하기 때문에 EC2 및 Autoscaling 권한이 필요하다.

 

위 정책은 이 정도까지의 작업을 수행할 수 있는 정책인데 이 작업들은 EKS 컨트롤 플레인 내에 위치한 Cloud-Controller-Manager의 컨트롤러들이 수행할 수 있는 작업들이다.

• https://kubernetes.io/docs/concepts/architecture/cloud-controller/#functions-of-the-ccm

즉, Cloud-Controller-Manager를 통해 접근하는 작업들은 EKS Cluster의 role을 사용하며, 위 정책은 Cloud-Controller-Manager내 컨트롤러가 작업을 수행할 수 있도록 하는 최소권한만 포함된 정책이다.

그리고 Cloud-Controller-Manager에 포함되어 있지 않은 Controller가 AWS에 액세스하려면 Service Account를 필요로 하게 된다.

 

이와 관련해 AWS에 Case를 남겨 받은 답변들이 있는데 참고하면 좋을 것 같아 첨부파일로 남깁니다. (내용이 너무 길어서 파일로 첨부)

eks_role_qna.txt

0.01MB