Question
EKS를 생성할 때 사용한 Role 이 아닌, 새로운 role을 사용하여 해당 cluster에 접속하고 싶습니다.
다른 사용자 혹은 역할이 새로운 role을 사용하여 cluster에 접속할 수 있는 방법이 있을까요?
Answer
기존 cluster에 접속하려면, eks cluster을 생성할 때 사용한 role(혹은 생성한 user)을 통해 접속하셔야 했습니다.
하지만, 새로운 역할을 생성하여 clsuter create role을 위임해주는 방법을 이용한다면, 다른 role 으로 cluster에 접근할 수 있습니다.
동일한 계정과 교차 계정에서의 사용법에 대해 안내드리겠습니다.
동일한 계정 내에서 cluster 접속
방법을 소개해드리기 전에, 간단하게 TEST 환경을 설명드리겠습니다.
TEST를 위해 동일한 account 내에 eks 클러스터와 사용자, 역할을 생성했습니다.
아래는 TEST 환경에 대한 설명입니다.
- 모두 동일한 account(867099995276)
- 기존 클러스터
- 사용자 : hanna_key
- 역할 : hanna-eks-node-role
- 새로운 IAM
- 사용자 : hanna-access-eks
- 역할 : cts-assume-eks-role
새로운 역할을 사용하여 kubectl에 접속하는 방법을 소개해 드리겠습니다.
-
EKS 클러스터를 생성한 USER에 대해 확인CloudTrail에 접속하여 이벤트 이름 : CreateCluster 의 userIdentity 섹션을 확인해주시길 바랍니다.
-
해당 클러스터를 생성한 사용자로 접속이 되는지 확인
aws configure # 기존 사용자의 accesskey, secretkey
kubectl get svc # kubectl이 정상적으로 동작하는지 확인
-
새로운 사용자와 역할을 생성
- 역할 생성
접속할 때 사용하는 새로운 역할 (cts-assume-eks-role)을 생성합니다.
정책은 아무것도 연결하지 않아도 됩니다. -
사용자 생성hanna-access-eks 를 생성한뒤, 필수적으로 필요한 정책 2가지를 연결합니다.
-
sts policy
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::867099995276:role/cts-assume-eks-role" } ] }
위에서 생성해준 새로운 권한을 Resource에 넣어줍니다.
User는 새로운 역할에 sts:AssumeRole 을 실행할 수 있는 역할이 필요합니다. -
eks:DescribeCluster policy
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "eks:DescribeCluster", "Resource": "*" } ] }eks:DescribeCluster 정책을 추가해주셔야합니다.이는 이후 IAM Role/User가 kube config 파일을 업데이트 하기 위한 aws eks update-kubeconfig 명령어를 실행할 때 필요한 권한입니다.
-
-
기존 사용자로 로그인 되어있는 상태에서, aws-auth.yaml configmap에 cts-assume-eks-role 권한을 추가해줍니다.
apiVersion: v1 kind: ConfigMap metadata: name: aws-auth namespace: kube-system data: mapRoles: | - rolearn: arn:aws:iam::867099995276:role/hanna-eks-node-role username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: arn:aws:iam::867099995276:role/cts-assume-eks-role username: hanna_access_eks groups: - system:mastersusername은 사실상 RBAC username 이므로 어떤 것이든 상관없습니다 :)
아래 명령어를 통해, Config Map의 변경을 적용해줍니다.kubectl apply -f aws.yaml
해당 configmap 이 제대로 반영되었는지 확인합니다.kubectl describe cm -n kube-system aws-auth
아래 사진과 같이 두개의 role 이 제대로 반영된 것을 확인하실 수 있습니다. -
새로운 사용자의 accesskey와 secretkey로 접속합니다.
aws configure hanna_access_eks(새로운 사용자)의 accesskey 와 secretkey를 통해 접속합니다.
-
새로 만든 역할로 config파일을 업데이트 합니다
aws eks update-kubeconfig --name hanna-eks --role-arn arn:aws:iam::867099995276:role/cts-assume-eks-role
-
새로운 역할로 kubectl 을 사용할 수 있는지 확인합니다.
kubectl get svc
교차 계정 내에서 cluster 접속
이번에 소개드릴 방법은, 교차 계정 내에서 특정 role에게 cluster에 접속할 수 있는 role을 생성하여 접속하는 방법입니다.즉, A라는 계정에 있는 역할(dev-role), 또는 사용자에게 새로 생성한 역할(accessRole) 로 계정 B에 있는 eks cluster에 접속하는 방법입니다.
위의 내용과 유사하므로 따라하시는데 큰 어려움이 없을 것으로 보입니다 :)
그렇다면, 교차 계정 내에서 cluster에 접속하는 방법을 안내해드리겠습니다.1. 개발자가 EKS 클러스터에 액세스하는 데 사용할 역할 A 를 만듭니다.Role A : accessRole참고: 해당 Role에는 역할을 맡을 수 있는 개발자 역할(service-profile-iam-role)의 ARN과 신뢰 관계가 있습니다.✅ PolicyPolicy: ======= { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:*" ], "Resource": "*" } ] }계정 A의 사용자가 EKS 클러스터에 액세스하기 위해 생성 할 새 역할(accessRole)에는 EKS 권한 만 있습니다.생성한 accessRole은 cluster create role과는 완전히 별개의 역할로, 사용자가 새로 만들 역할이며, 전체 EKS 권한을 부여하는 정책만 이 역할에 첨부합니다.즉, 해당 역할(accessRole) 을 위임하여 사용하면, A계정의 사용자는 EKS에 대한 권한만 가질 수 있습니다.
✅ 신뢰 관계{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com", "AWS": [ "arn:aws:iam::12345678910:role/DeveloperA", "arn:aws:iam::12345678910:user/AccessUser" ] }, "Action": "sts:AssumeRole" } ] }
접속하고자 하는 사용자, 혹은 역할과의 신뢰 정책을 생성해 줍니다.코드의 부가적인 설명을 드리자면,첫 번째, ["Service": "eks.amazonaws.com"]는 역할(이 신뢰관계를 사용하는 accessRole)이 EKS 서비스와 통신할 수 있도록 하는 것입니다.예를 들어, '$kubectl get nodes' 와 같은 명령어를 실행하기 위해서는 EKS 서비스와 통신하고 출력을 검색하기 위해 해당 신뢰 관계 정책이 필수적입니다.두번째, ["arn:aws:iam:12345678910:role/Developer"A"]은(는) 우리가 만든 역할(accessRole)이 다른 계정의 역할(DeveloperA)에 의해 assume 될 수 있도록 하는 것입니다.2. 역할 A: AccessRole 을 aws-auth configmap에 매핑하여 개발자가 EKS 클러스터에 액세스할 수 있도록 합니다.
만약 사용자에 의해 assume 되려면, ["arn:aws:iam::12345678910:user/AccessUser"] 과의 신뢰 정책을 수립해주시면 됩니다.
개발자가 새로 생성한 “accessRole”을 assume하면 EKS 클러스터에 액세스 할 수 있습니다.
그 전에, cluster에 접속하셔서 aws-auth 구성 맵에 생성한 "AccessRole"을 매핑해야 합니다.
아래와 같이 ConfigMap을 변경하시고, configmap의 이름은 반드시 aws-auth 로 설정하셔야합니다.
================================== apiVersion: v1 kind: ConfigMap metadata: name: aws-auth namespace: kube-system data: mapRoles: | - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: arn:aws:iam::12345678910:role/accessRole username: accessRole groups: - system:masters ============================================위와 같이, aws-auth 구성 맵을 편집하고 “system:masters”그룹에 “AccessRole”을 추가하고 적용하시면 됩니다.
3. 개발팀이 역할로 접속하여 아래의 명령을 사용해서 “AccessRole”을 assume 합니다.
먼저 아래 명령을 사용하여 현재 로그인한 역할을 확인하십시오.
$ aws sts get-caller-identity
(a) AccessRole 을 가정하는 명령:$ aws sts assume-role --role-arn arn:aws:iam::12345678910:role/accessRole --role-session-name test
(b) 역할을 가정한 후 수신되는 임시 IAM 자격 증명을 사용하여 AWS_ACCESSO_KEY_ID, AWS_세션_토큰 및 AWS_비밀번호_ACCELET_KEY 환경 변수를 설정합니다.
예를 들면 다음과 같습니다.export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE export AWS_SESSION_TOKEN=EXAMPLETOKEN export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
❗ 주의: Linux를 사용하는 경우 export 명령어를 사용합니다. Windows를 사용하는 경우 SET 명령어를 사용하십시오.
(c) 마지막으로 kubectl 명령을 실행하여 assume된 역할이 EKS 클러스터에 대한 액세스 권한을 가지고 있는지 확인합니다.$ kubectl get nodes $ kubectl get pods
위의 작업이 완료되어 정상적으로 동작한다면, 계정 A의 사용자, 역할이 계정 B의 EKS cluster에 접속할 수 있습니다.
