- EKS cluster의 내부에 구성되어 있는 kubernetes 자원들은 AWS의 자원들을 CRUD할 수 없고, AWS의 계정 또한 kubernetes 자원들을 보거나 조작할 수 없습니다.
즉, kubernetes 자원과 AWS 자원은 서로 다른 영역에 있습니다. 그렇기 때문에 서로에게 접근하기 위해서는 특별한 추가 작업이 필요합니다.
AWS -> Kubernetes
- 먼저, AWS 계정에서 k8s 자원에 접근하기 위해서는 k8s에서 aws-auth라는 Configmap에 AWS 계정을 추가해야 합니다.
aws-auth는 다음과 같은 형식이며, ${}에 알맞은 값을 넣어주면 됩니다.
data.mapUser에 AWS IAM user를 넣고 groups에 원하는 만큼의 권한을 부여해주면 AWS console에서 EKS의 내부 자원들에 접근할 수 있습니다.
IAM user가 아니라 EC2를 통해 EKS 내부 자원에 접근하고자 하는 경우에는 data.mapRoles에 EC2에 할당된 instance profile(IAM Role)을 넣으면 됩니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ kubectl get configmap aws-auth -n kube-system -o yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- rolearn: arn:aws:iam::${AWS_ACCOUNT}:role/${ROLE_NAME}
username: system:node: // 변경 X
groups:
- system:bootstrappers
- system:nodes
- rolearn: arn:aws:iam::${AWS_ACCOUNT}:role/${ROLE_NAME}
username: karpenter
groups:
- system:masters
mapUsers: |
- userarn: arn:aws:iam::${AWS_ACCOUNT}:user/${USER_NAME}
username: ${USER_NAME}
groups:
- system:masters
Kubernetes -> AWS
- EKS 내부에서는 auto scaling 또는 load balancer 생성을 위해 AWS의 자원에 접근할 필요가 있습니다.
이 경우에 aws의 자원을 생성하는 주체는 pod가 되며, aws 자원의 생성 권한은 pod가 가지고 있는 service account로부터 얻습니다. 이를 IRSA(IAM Role for Service Account)라 합니다.
kubernetes도 role은 내부 kubernetes 자원을 조작하기 위한 권한입니다. - service account가 aws에 접근하여 자원을 생성할 권한을 부여받기 위해서는 EKS Cluster에 oidc 공급자를 생성해야 합니다.
- kubernetes 자원은 service account를 통해 AWS 자원에 접근하는데, 이 때 EKS Cluster에서 생성한 oidc provider에서 ID token을 발급 받습니다.
OIDC(OpenID Connect) with AWS IAM
- OIDC는 authorization(인가) 규약인 OAuth(Open Authorization)를 이용해 만든, authentication(인증) 방식입니다.
EKS 1.14 이상의 cluster를 생성하면 EKS IdP(Identity Provider)가 자동으로 생성되고, 이 EKS IdP를 통해 k8s가 발급한 ID token의 유효성을 검증합니다.
일시적으로 특정 권한을 허가 받은 access token을 발급하는 OAuth와 달리 oidc는 authentication(인증)을 위해서 ID Token을 발급합니다.
Example
- k8s의 s3 echoer app이 s3에 접근하려고 합니다.
- s3-echoer-job.yaml manifest가 EKS pod identity webhook과 함께 api 서버에 제출됩니다.
- job s3-echoer는 default namespace 안에 있고, pod의 serviceAccountName 속성은 s3-echoer로 설정되어 있습니다.
- service account는 eks.amazonaws.com/role-arn이 annotation에 추가되어 있으므로 webhook은 필요한 환경변수와 id token을 받습니다.
- S3 Echoer app이 s3에 요청을 보낼 때, oidc를 통해 인증된 IRSA로 요청합니다. 해당 service account의 token에는 s3에 접근할 수 있는 정책이 부여되어 있으므로 s3에 접근할 수 있게 됩니다.
참고