[AWS/EKS] EKS 인증/인가 파헤치기

이번 포스팅에서는 EKS 의 인증/인가 절차에 대해 자세하게 알아보겠습니다.

 

EKS 권한에 대해 말할 때 흔히 IAM, 인증, 인가, RBAC, RoleBinding, Role, ServiceAccount 등의 용어가 사용됩니다.
이번 포스팅을 통해 해당 용어에 대한 개념을 알아보고 인증, 인가에 대해 딥다이브하게 파헤쳐보겠습니다.

 

1. EKS 인증 / 인가 용어 정리

 

다들 아시다시피 EKS 에서는 인증과 인가 절차가 분리되어 있습니다.

인증과 인가는 세부적으로는 복잡하지만, 아래의 개념으로 이해하시면 알기 쉽습니다.

 

• 인증(Authentication) : 외부 사용자가 EKS Cluster 에 접속하는 과정 (AWS IAM 사용)
• 인가(Authorization) : EKS Cluster 내부 리소스 접근 권한 (Namespace, Pod, Deployment 등)

 

1.1. EKS 인증 관련 용어

 

EKS 인증에 사용되는 대표적인 용어를 알아보겠습니다.

 

인증은 외부 사용자가 EKS Cluster에 접속하는 과정이라고 말했습니다.
때문에, k8s 외부와 k8s 설정의 연결이 주된 내용입니다.

 

a. kubectl

- kubernetes control 의 약자로 k8s 사용자가 쿠버네티스 API Server 와 통신할 때 사용되는 cli 입니다.
- API Server 에 접속할 수 있는 사용자만 해당 명령어를 입력할 수 있습니다.

kubectl get namespace

 

 

b. kubeconfig

- kubernetes 접속에 필요한 정보가 설정되어 있는 파일입니다.

cat ~/.kube/config

 

• 기본적인 config 구성과 EKS 와의 연관 관계를 나타낸 그림입니다.

 

c. aws-auth

- AWS IAM 서비스와 EKS RBAC 을 연결시켜주는 EKS 의 인증 설정입니다.
- Kubernetes에서 API 인증을 허용하기 위해 사용하는 방법 중 EKS는 Webhook Token Authentication 을 사용하며,
   aws-iam-authenticator를 통해 이를 구현합니다.

 

• aws-auth Full Format

GitHub - kubernetes-sigs/aws-iam-authenticator: A tool to use AWS IAM credentials to authenticate to a Kubernetes cluster

kubectl get cm -n kube-system aws-auth -o yaml

 

 

1.2. EKS 인가 관련 용어

 

EKS 인가와 관련된 용어를 알아보겠습니다.

 

인가는 EKS Cluster 내부 리소스 접근 권한이라고 말했습니다.
때문에, EKS 내부의 사용자와 리소스간의 통신이 주된 내용입니다.

 

a. RBAC

- Role Based Access Control 의 약자로 아래 설명할 Role/ClusterRole 을 통해 kubernetes 사용 권한을 부여하는 방식입니다.

 

b. Namespace

- kubernetes 내부에서 리소스를 격리하는 논리적 단위입니다.
- 대부분의 kubernetes 리소스는 Namespace 에 종속되나, 그렇지 않은 리소스도 있습니다.
- 기본적으로 Namespace 가 다른 리소스들은 서로간 통신하지 않습니다. (통신 설정 가능)

 

kubectl get ns

 

 

c. Role

- kubernetes 내부에서 리소스를 사용할 수 있는 '권한'입니다.
- Role 은 특정 Namespace 에 국한되는 권한입니다.
- 특정 Region에 국한된 AWS IAM Policy 라고 생각하면 이해하기 쉽습니다.

 

d. ClusterRole

- Role 과 동일하게 kubernetes 내부에서 리소스를 사용할 수 있는 '권한'입니다.
- ClusterRole 은 Role 과는 달리 Namespace 에 국한되지 않고 Cluster 전체에 대한 권한입니다.
- 전체 Region 에 대한 AWS IAM Policy 라고 생각하면 이해하기 쉽습니다.

 

e. Role Binding / ClusterRole Binding

- Role 또는 ClusterRole 을 kubernetes 사용 주체와 연결하는 작업입니다.
- 해당 작업을 통해 RBAC 을 구현할 수 있습니다.
- Role/ClusterRole 과 연결 가능한 주체로는 Service Account, User, Group 이 있습니다.

 

f. Service Account

- kubernetes 내부에서 리소스를 사용하는 '주체' 입니다.
- Service Account 리소스는 Namespace에 종속됩니다.
- 리소스를 사용하는 주체는 Pod 같은 쿠버네티스의 오브젝트가 될 수 있습니다.
- AWS IAM Role 이라고 생각하면 이해하기 쉽습니다.

 

g. User / Group

- kubernetes 내부에서 리소스를 사용하는 '주체' 입니다.
- 해당 리소스는 kubernetes API 로 존재하지 않습니다.
- AWS IAM User, Group 이라고 생각하면 이해하기 쉽습니다.

모두 Clusterrolebinding 이지만, 주체는 각각 Service Account, User, Group 으로 구성된 것을 알 수 있습니다.

 

2. EKS 인증 과정

 

EKS 인증 과정에 대해 자세하게 알아보겠습니다.

EKS 인증을 위해 발생하는 일련의 과정을 나타낸 그림입니다.

 

아래는 상기 과정을 도식화한 그림입니다.

스터디원 한 분께서 고생해주셨습니다.

해당 스터디원분의 블로그!

[6주차] AEWS Amazon EKS 워크숍 스터디 (23.05.28)

 

이제부터 위 인증 과정을 하나씩 파헤쳐보겠습니다.

 

2.1. 사용자의 kubectl 명령 수행 (aws eks get-token)

 

EKS 사용자가 kubectl 명령어를 수행했을 때, 앞서 설명했던 kubeconfig 파일의 설정을 바라보게 됩니다.

cat ~/.kube/config

 

해당 config 파일을 보면 kubectl 사용자에 대해 AWS CLI 명령어를 수행하도록 설정되어 있습니다.

 

해당 명령어를 풀어서 입력하면, 다음과 같은 토큰을 확인할 수 있습니다.

aws eks get-token --cluster-name $CLUSTER_NAME --region ap-northeast-2 | jq

 

 

2.2. Pre-Signed URL 토큰 전달

 

해당 토큰은 Pre-Signed URL 입니다.
JWT 사이트에서 해당 토큰을 Decode 해보면 EKS API Server 에 전송하는 API 가 나타납니다.

JWT.IO

 

 

Payload 에 나온 값을 다시 한 번, URL Decode 로 변경하면 아래와 같은 정보가 나타납니다.

URL Decode Online - Encode / Decode URL

 

 

해당 값을 풀어보면 다음과 같습니다.

https://sts.ap-northeast-2.amazonaws.com/?

Action=GetCallerIdentity&

Version=2011-06-15&

X-Amz-Algorithm=AWS4-HMAC-SHA256&

X-Amz-Credential=AAAAA.../20230602/ap-northeast-2/sts/aws4_request&

X-Amz-Date=20230602T124400Z&

X-Amz-Expires=60&

X-Amz-SignedHeaders=host;x-k8s-aws-id&

X-Amz-Signature=d09053be5679fe........

 

2.3. Pre-Signed URL Token 확인

 

EKS API Server 에서는 위에서 나온 값을 전달 받아 AWS STS 서비스에 유효한 값인 지 물어보는 과정을 수행합니다.

해당 수행 과정은 실제 CloudTrail 에서 확인이 가능합니다.

 

2.4. aws-auth 파일 확인

 

EKS API Server 는 그 후, STS 에서 받아온 Role/User ARN 값을 aws-auth 에 매핑된 ARN 값과 비교합니다.

kubectl get cm aws-auth -n kube-system -o yaml

 

EKS 생성 유저는 aws-auth 상에 확인할 수 없습니다.

휴먼 에러로 인한 EKS 접속 인증 권한이 모두 사라질 경우를 대비해, AWS 에서 고의적으로 숨겨둡니다.
다만, 어떤 사용자가 EKS 생성 유저인지 확인하기 위해서는 rbac-tool 을 사용하여 확인이 가능합니다.

 

rbac-tool 은 설치하여 사용하는 kubernetes plug-in 입니다.

kubectl rbac-tool whoami

 

AWS ARN 값을 비교하여 일치한 유저에게는 EKS API Server 에 접근할 수 있는 권한이 주어집니다.
다만 명령어를 수행할 수 있는 권한이 아직 주어지지 않았다면 kubectl 명령어는 실패합니다.

 

명령어를 수행할 수 있는 권한은 다음 인가 절차에서 알아보겠습니다.

 

3. EKS 인가 과정

 

kubernetes 상에서 인가는 인증과 별개의 권한입니다.
kubernetes 인가를 위해서는 RBAC 처리가 필요합니다.

 

 

3.1. IAM - k8s Role Mapping

 

AWS IAM Role/User 와 Kubernetes Role/ClusterRole 을 연동은 eksctl 명령어로 쉽게 해결할 수 있습니다.

참고로, eksctl 을 통해 생성하지 않은 EKS 에서도 eksctl 명령어 수행이 가능합니다.

 

eksctl create iamidentitymapping \
    --cluster $CLUSTER_NAME \
    --region=ap-northeast-2 \
  --arn <연동하고자하는 AWS ROLE / USER ARN 값> \
    --username <EKS 내에서 사용하는 Username> \
    --group <Role 사용 주체가 Group일 경우, 해당 Group Name> \
  --no-duplicate-arns

 

저는 테스트를 위해 cluster-admin 권한이 부여된 system:masters Group에 IAM User 를 연결하겠습니다.

 

 

혼동을 방지하기 위해 기존의 kubeconfig 를 삭제하고 다시 실행하겠습니다.

rm ~/.kube/config

aws eks --region ap-northeast-2 update-kubeconfig --name myeks

kubectl get pods -A

 

kubectl 명령어에 대한 응답이 반환되는 것을 알 수 있습니다.

 

4. EKS ReadOnly User 생성하기

 

앞에서 설명한 EKS 인증 / 인가에 대해 이해를 했다면 EKS ReadOnly 권한을 가진 IAM User 를 생성할 수 있습니다.

 

4.1. IAM User 생성

 

test-user 라는 IAM User 를 생성하겠습니다.

EKS ReadOnly 에 필요한 권한을 아래와 같이 부여합니다. (EKS Dashboard 기준입니다.)

 

IAM User Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowEKSClusterAccess",
            "Effect": "Allow",
            "Action": [
                "eks:ListNodegroups",
                "eks:DescribeFargateProfile",
                "eks:DescribeAddonConfiguration",
                "eks:ListTagsForResource",
                "eks:ListAddons",
                "eks:DescribeAddon",
                "eks:ListFargateProfiles",
                "eks:DescribeNodegroup",
                "eks:DescribeIdentityProviderConfig",
                "eks:ListUpdates",
                "eks:DescribeUpdate",
                "eks:AccessKubernetesApi",
                "eks:DescribeCluster",
                "eks:ListClusters",
                "eks:DescribeAddonVersions",
                "eks:ListIdentityProviderConfigs"
            ],
            "Resource": "*"
        }
    ]
}

 

4.2. ClusterRole 생성

 

다음은 EKS 리소스를 조회할 수 있는 ClusterRole 을 생성하겠습니다.
EKS 에 접속하여 다음의 yaml 파일을 생성 후 배포합니다.

EKS 리소스에 대해 get, list, watch 권한을 가진 역할입니다.

cat << EOT > clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kimalarm:cluster-readonly
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch
EOT

 

kubectl apply -f clusterrole.yaml

 

4.3. ClusterRoleBinding 생성

 

다음은 생성한 ClusterRole 을 test-user 가 사용할 수 있도록 Role Binding 을 해줍니다.
다음의 yaml 파일을 생성 후 배포합니다.

 

cat << EOT > clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: readonly
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kimalarm:cluster-readonly
subjects:
- kind: Group
  name: kimalarm:cluster-readonly
  apiGroup: rbac.authorization.k8s.io
EOT

 

kubectl apply -f clusterrolebinding.yaml

 

4.4. IAM Mapping

 

다음은 AWS IAM User 와 생성한 ClusterRole 이 부여된 Group 에 대한 연동을 실행하는 과정입니다.

eksctl create iamidentitymapping \
    --cluster myeks \
    --region=ap-northeast-2 \
  --arn <TEST_USER_ARN> \
    --username test-user \
    --group kimalarm:cluster-readonly \
  --no-duplicate-arns

 

명령어가 정상적으로 수행되었다면 aws-auth 에서 확인할 수 있습니다.

kubectl get cm aws-auth -n kube-system -o yaml

 

 

4.5. EKS 확인

 

해당 사용자로 EKS 리소스를 확인해봅니다.

 

kubectl get pods -A

 

 

읽기 전용 사용자가 생성된 것을 확인할 수 있습니다.

 

---

참고 문서

1. EKS 인증

• k8s 인증 방식
  https://coffeewhale.com/kubernetes/authentication/http-auth/2020/05/03/auth02/

 

• AWS Webhook Token Authentication
  https://github.com/kubernetes-sigs/aws-iam-authenticator
  https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication

 

2. EKS 인가

• k8s namespace , dns
  https://kubernetes.io/ko/docs/concepts/services-networking/dns-pod-service/