AEWS 스터디에서는 AWS의 관리형 Kubernetes인 Elastic Kubernetes의 다양한 기능들을 실습해보면서 익혀본다. 이 글은 스터디를 참여하면서 학습한 내용을 정리하는 연재 글이다. 스터디 진도에 맞춰 글을 작성한다.
이 글에서는 EKS Security - K8S 및 EKS의 인증/인가 에 대해서 알아본다.
1. K8S 인증/인가
마스터 노드 (컨트롤 플래인)에 접근하기 위해서는 무조건 API를 서버를 통해 접근해야 한다. 이를통해 클러스터의 조회 변경등의 작업을 할 수 있다. 접근 방법들을 나열해 보면 다음과 같다.
- Kubectl 내부 설치
- 클러스터 내부에서 접근
- 클러스터 외부에서 접근
- https: API 직접 접근
- http: kubectl - Proxy를 통해 접근
- Kubectl 외부 설치
- config 활용하여 contaxt 변경하여 여러 클러스터에 접근
클러스터 내부에서는 kubectl로 API서버를 직접 접근한다. 외부에서는 API 접근하기 위해서는 인증서로 https로 보안 접근을 해야한다. 관리자가 내부 kubectl이 설치되어 있는 곳에 프록시를 열어두면 http로도 접근 가능하다.
아예 외부 PC에 kubectl을 설치한 후에 접근할 수도 있다. kubectl을 외부에 설치하고 config 활용하여 contaxt를 변경하면 여러 클러스터에 접근할 수 있다.
RBAC(Role, RoleBinding)
RBAC은 특정 권한을 가진 Role (역할)을 만들어 주체에 부여하는 방식의 인증 인가 방식으로, 쿠버네티스의 인가 방식 중 가장 많이 사용하는 방식이다.
쿠버네티스의 자원은 다음과 같이 나뉜다.
- 클러스터 단위 관리 자원 (node, pv, namespace ...)
- 네임스페이스 단위로 관리되는 자원 (pod, svc ...)
네임스페이스를 생성하면 자동으로 SA (service account)가 생성되고 추가로도 생성할 수 있다. 이 SA에 RoleBinding (역할을 묶어주는, 연결해주는) 할 수 있다. 클러스터 단위에서도 ClusterRole, ClusterRoleBinding을 통해 연결 할 수 있다. 역할을 범위로 정리하면 다음과 같다.
- Role(네임스페이스내 자원의 권한)
- ClusterRole(클러스터 수준의 자원의 권한)
2. EKS 인증/인가
RBAC 관련 krew 플러그인 설치
동작 확인을 위해 RBAC 관련 플러그인 access-matrix, rbac-tool, rolesum, rbac-view 4가지를 설치한다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
# 설치
kubectl krew install access-matrix rbac-tool rbac-view rolesum
# Show an RBAC access matrix for server resources
kubectl access-matrix # Review access to cluster-scoped resources
kubectl access-matrix --namespace default # Review access to namespaced resources in 'default'
# RBAC Lookup by subject (user/group/serviceaccount) name
kubectl rbac-tool lookup
kubectl rbac-tool lookup system:masters
SUBJECT | SUBJECT TYPE | SCOPE | NAMESPACE | ROLE
+----------------+--------------+-------------+-----------+---------------+
system:masters | Group | ClusterRole | | cluster-admin
kubectl rbac-tool lookup system:nodes # eks:node-bootstrapper
kubectl rbac-tool lookup system:bootstrappers # eks:node-bootstrapper
kubectl describe ClusterRole eks:node-bootstrapper
# RBAC List Policy Rules For subject (user/group/serviceaccount) name
kubectl rbac-tool policy-rules
kubectl rbac-tool policy-rules -e '^system:.*'
# Generate ClusterRole with all available permissions from the target cluster
kubectl rbac-tool show
# Shows the subject for the current context with which one authenticates with the cluster
kubectl rbac-tool whoami
{Username: "kubernetes-admin",
UID: "aws-iam-authenticator:911283.....:AIDA5ILF2FJ......",
Groups: ["system:masters",
"system:authenticated"],
Extra: {accessKeyId: ["AKIA5ILF2FJ....."],
arn: ["arn:aws:iam::911283....:user/admin"],
canonicalArn: ["arn:aws:iam::911283....:user/admin"],
principalId: ["AIDA5ILF2FJ....."],
sessionName: [""]}}
# Summarize RBAC roles for subjects : ServiceAccount(default), User, Group
kubectl rolesum -h
kubectl rolesum aws-node -n kube-system
kubectl rolesum -k User system:kube-proxy
kubectl rolesum -k Group system:masters
# [터미널1] A tool to visualize your RBAC permissions
kubectl rbac-view
INFO[0000] Getting K8s client
INFO[0000] serving RBAC View and http://localhost:8800
## 이후 해당 작업용PC 공인 IP:8800 웹 접속
echo -e "RBAC View Web http://$(curl -s ipinfo.io/ip):8800"
|
cs |
Amazon EKS 인증/인가 흐름
Amazon EKS의 인증 인가 흐름은 다음과 같다.
1. AWS 토큰 받기 → 2. Authentication (인증) → 3. Authorization (인가)
1. AWS 토큰 받기
kubectl 명령을 따라가 보면 사용자 PC에서 쿠버네티스 명령을 내리면, 사용자 PC의 kubeconfig 설정 정보에서 get-token 명령으로 EKS 서비스 엔드포인트로 요청이 간다. 응답값으로 base64로 인코딩된 토큰이 전달되고, 내용은 Pre-signed url이다. 해당 토큰은 아래 실습에서 살펴본다.
2. Authentication (인증)
2-1. kubectl → API Server
이 Bearer Token을 k8s 액션과 함께 api 서버로 요청한다. 웹훅에서 이 토큰을 확인 하고 인증을 진행한다.
이 인증 인가는 api에서 하는 게 아니라 AWS IAM 쪽에서 인증을 대신 확인 해준다.
2-2. API Server → Webhook
이를 위해 Webhook에서 aws IAM 처리 할 수 있도록 요청을 주고, UserId, Role arn을 반환 한다. 인증은 완료되었고, 쿠버네티스 인가를 하기 위해 매핑하는 AWS-Auth를 사용한다.
2-3. Webhook → AWS-Auth
AWS-Auth는 AWS IAM과 쿠버네티스의 User, Group으로 매핑하는 config map이다.
3. Authorization (인가)
API 서버에서 인증된 사용자와 User, 그룹을 받아서 RBAC으로 인가한다.
실습 1 - 인증/인가 분석
AWS API를 사용하는 User의 ARN을 찍어볼 수 있다. config이서 확인 해보면 User exec 부분에 보면, 인증 처리를 하는 부분이 보인다. 이 부분을 수동으로 진행해본다. 예전에는 툴을 설치하여 진행했지만, aws cli 1.16 버전 이후에 내장되어 있다.
1. kubectl 명령 → aws eks get-token → EKS Service endpoint(STS)에 토큰 요청
⇒ 응답값 디코드(Pre-Signed URL 이며 GetCallerIdentity..)
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
# sts caller id의 ARN 확인
aws sts get-caller-identity --query Arn
"arn:aws:iam::<자신의 Account ID>:user/admin"
# kubeconfig 정보 확인
cat ~/.kube/config | yh
...
- name: admin@myeks.ap-northeast-2.eksctl.io
user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
args:
- eks
- get-token
- --output
- json
- --cluster-name
- myeks
- --region
- ap-northeast-2
command: aws
env:
- name: AWS_STS_REGIONAL_ENDPOINTS
value: regional
interactiveMode: IfAvailable
provideClusterInfo: false
# Get a token for authentication with an Amazon EKS cluster.
# This can be used as an alternative to the aws-iam-authenticator.
aws eks get-token help
# 임시 보안 자격 증명(토큰)을 요청 : expirationTimestamp 시간경과 시 토큰 재발급됨
aws eks get-token --cluster-name $CLUSTER_NAME | jq
aws eks get-token --cluster-name $CLUSTER_NAME | jq -r '.status.token'
|
cs |
2. Pre-Signed URL을 Bearer Token으로 EKS API Cluster Endpoint로 요청을 보냄
이 내용을 EKS 쿠버네티스 API에 bearer 에 담아서 요청 하게 된다. 이 구조를 보면 일반적으로 AWS 구문과 비슷하다.
- 디코드 과정: 토큰을 jwt 사이트에 복붙으로 디코드 정보 확인(HS384 → HS256) PAYLOAD 정보 확인 : (일반적인 AWS API 호출과 유사)
- PAYLOAD의 값을 URL Decode Online 에서 DECODE로 확인
디코드 완료된 구문
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
https://sts.ap-northeast-2.amazonaws.com/?
Action=GetCallerIdentity&
Version=2011-06-15&
X-Amz-Algorithm=AWS4-HMAC-SHA256&
X-Amz-Credential=AKIA5ILF.../20230525/ap-northeast-2/sts/aws4_request&
X-Amz-Date=20230525T120720Z&
X-Amz-Expires=60&
X-Amz-SignedHeaders=host;x-k8s-aws-id&
X-Amz-Signature=6e09b846da702767f38c78831986cb558.....
|
cs |
3. EKS API는 Token Review 를 Webhook token authenticator에 요청
⇒ (STS GetCallerIdentity 호출) AWS IAM 해당 호출 인증 완료 후 User/Role에 대한 ARN 반환
- 참고로 Webhook token authenticator 는 aws-iam-authenticator 를 사용한다.
|
1
2
3
4
5
6
7
8
9
10
11
|
# tokenreviews api 리소스 확인
kubectl api-resources | grep authentication
tokenreviews authentication.k8s.io/v1 false TokenReview
# List the fields for supported resources.
kubectl explain tokenreviews
...
DESCRIPTION:
TokenReview attempts to authenticate a token to a known user. Note:
TokenReview requests may be cached by the webhook token authenticator
plugin in the kube-apiserver.
|
cs |
4. 쿠버네티스 RBAC 인가를 처리
EKS에서 인가처리를 진행한다. AWS에 인가 서비스가 있으면 좋겠지만 플랫폼 업데이트 등의 따라 업데이트 되기 힘드므로 인가 부분을 컨피그 맵을 사용하게 된다.
- 해당 IAM User/Role 확인이 되면 k8s aws-auth configmap에서 mapping 정보를 확인
- aws-auth 컨피그맵에 'IAM 사용자, 역할 arm, K8S 오브젝트' 로 권한 확인 후 k8s 인가 허가가 되면 최종적으로 동작 실행을 합니다.
- EKS를 생성한 IAM principal은 aws-auth 와 상관없이 kubernetes-admin Username으로 system:masters 그룹에 권한을 가짐
kubectl rbac-tool whoami 명령어로 등록 되어 있는 그룹 system:masters , system:authenticated이 확인 된다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
|
# Webhook api 리소스 확인
kubectl api-resources | grep Webhook
mutatingwebhookconfigurations admissionregistration.k8s.io/v1 false MutatingWebhookConfiguration
validatingwebhookconfigurations admissionregistration.k8s.io/v1 false ValidatingWebhookConfiguration
# validatingwebhookconfigurations 리소스 확인
kubectl get validatingwebhookconfigurations
NAME WEBHOOKS AGE
eks-aws-auth-configmap-validation-webhook 1 50m
vpc-resource-validating-webhook 2 50m
aws-load-balancer-webhook 3 8m27s
kubectl get validatingwebhookconfigurations eks-aws-auth-configmap-validation-webhook -o yaml | kubectl neat | yh
# aws-auth 컨피그맵 확인
kubectl get cm -n kube-system aws-auth -o yaml | kubectl neat | yh
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::91128.....:role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-1OS1WSTV0YB9X
username: system:node:{{EC2PrivateDNSName}}
#---<아래 생략(추정), ARN은 EKS를 설치한 IAM User , 여기 있었을경우 만약 실수로 삭제 시 복구가 가능했을까?---
mapUsers: |
- groups:
- system:masters
userarn: arn:aws:iam::111122223333:user/admin
username: kubernetes-admin
# EKS 설치한 IAM User 정보
kubectl rbac-tool whoami
{Username: "kubernetes-admin",
UID: "aws-iam-authenticator:9112834...:AIDA5ILF2FJIR2.....",
Groups: ["system:masters",
"system:authenticated"],
...
# system:masters , system:authenticated 그룹의 정보 확인
kubectl rbac-tool lookup system:masters
kubectl rbac-tool lookup system:authenticated
kubectl rolesum -k Group system:masters
kubectl rolesum -k Group system:authenticated
# system:masters 그룹이 사용 가능한 클러스터 롤 확인 : cluster-admin
kubectl describe clusterrolebindings.rbac.authorization.k8s.io cluster-admin
Name: cluster-admin
Labels: kubernetes.io/bootstrapping=rbac-defaults
Annotations: rbac.authorization.kubernetes.io/autoupdate: true
Role:
Kind: ClusterRole
Name: cluster-admin
Subjects:
Kind Name Namespace
---- ---- ---------
Group system:masters
# cluster-admin 의 PolicyRule 확인 : 모든 리소스 사용 가능!
kubectl describe clusterrole cluster-admin
Name: cluster-admin
Labels: kubernetes.io/bootstrapping=rbac-defaults
Annotations: rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
*.* [] [] [*]
[*] [] [*]
# system:authenticated 그룹이 사용 가능한 클러스터 롤 확인
kubectl describe ClusterRole system:discovery
kubectl describe ClusterRole system:public-info-viewer
kubectl describe ClusterRole system:basic-user
kubectl describe ClusterRole eks:podsecuritypolicy:privileged
|
cs |
실습 2 - 데브옵스 신입 사원을 위한 myeks-bastion-2에 설정 해보기
1. [myeks-bastion] testuser 사용자 생성
데브옵스 신입 사원을 위한 myeks-bastion-2에 설정해본다. 우선 IAM 유저 생성하고 AWS 권한을 부여해본다. 엑세스 권한과 정책 (AdministratorAccess)을 설정하고 확인 해본다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
# testuser 사용자 생성
aws iam create-user --user-name testuser
# 사용자에게 프로그래밍 방식 액세스 권한 부여
aws iam create-access-key --user-name testuser
{
"AccessKey": {
"UserName": "testuser",
"AccessKeyId": "AKIA5ILF2##",
"Status": "Active",
"SecretAccessKey": "TxhhwsU8##",
"CreateDate": "2023-05-23T07:40:09+00:00"
}
}
# testuser 사용자에 정책을 추가
aws iam attach-user-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --user-name testuser
# get-caller-identity 확인
aws sts get-caller-identity --query Arn
"arn:aws:iam::911283464785:user/admin"
# EC2 IP 확인 : myeks-bastion-EC2-2 PublicIPAdd 확인
aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output table
|
cs |
2. [myeks-bastion-2] testuser 자격증명 설정 및 확인
두번째 배스천 서버에 들어가서 자격증명을 해준다. 유저 arn 확인하면 등록 된 걸 확인 할 수 있다. 인증정보가 ~/.kube의 config 파일에 없기 때문에 kubectl은 동작 할 수 없다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
ssh ec2-user@3.35.141.234 -i ~/.ssh/ygpark.pem
# get-caller-identity 확인 >> 왜 안될까요?
aws sts get-caller-identity --query Arn
# testuser 자격증명 설정
aws configure
AWS Access Key ID [None]: AKIA5ILF2F...
AWS Secret Access Key [None]: ePpXdhA3cP....
Default region name [None]: ap-northeast-2
# get-caller-identity 확인
aws sts get-caller-identity --query Arn
"arn:aws:iam::991354587926:user/testuser"
# kubectl 시도 >> testuser도 AdministratorAccess 권한을 가지고 있는데, 실패 이유는?
kubectl get node -v6
ls ~/.kube
|
cs |
3. [myeks-bastion] testuser에 system:masters 그룹 부여로 EKS 관리자 수준 권한 설정
첫번째 베스천에서 mapping을 설정해준다. config map을 확인 해보면 해당 mapping을 사용할 수 있다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
# 방안1 : eksctl 사용 >> iamidentitymapping 실행 시 aws-auth 컨피그맵 작성해줌
# Creates a mapping from IAM role or user to Kubernetes user and groups
eksctl create iamidentitymapping --cluster $CLUSTER_NAME --username testuser --group system:masters --arn arn:aws:iam::$ACCOUNT_ID:user/testuser
# 확인
kubectl get cm -n kube-system aws-auth -o yaml | kubectl neat | yh
...
# 방안2 : 아래 edit로 mapUsers 내용 직접 추가!
kubectl edit cm -n kube-system aws-auth
---
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::911283464785:role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-LHQ7DWHQQRZJ
username: system:node:{{EC2PrivateDNSName}}
mapUsers: |
- groups:
- system:masters
userarn: arn:aws:iam::911283464785:user/testuser
username: testuser
...
# 확인 : 기존에 있는 role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-YYYYY 는 어떤 역할/동작을 하는 걸까요?
eksctl get iamidentitymapping --cluster $CLUSTER_NAME
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::911283464785:role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-LHQ7DWHQQRZJ system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws:iam::911283464785:user/testuser testuser system:masters
|
cs |
4. [myeks-bastion-2] testuser kubeconfig 생성 및 kubectl 사용 확인
eks에 kubeconfig update하면 쿠버네티스에 config 정보가 추가된다. kubectl을 적용해보면 작동이 되는 걸 확인 할 수 있다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
# testuser kubeconfig 생성 >> aws eks update-kubeconfig 실행이 가능한 이유는?, 3번 설정 후 약간의 적용 시간 필요
aws eks update-kubeconfig --name $CLUSTER_NAME --user-alias testuser
# 첫번째 bastic ec2의 config와 비교해보자
cat ~/.kube/config | yh
# kubectl 사용 확인
kubectl ns default
kubectl get node -v6
# rbac-tool 후 확인 >> 기존 계정과 비교해보자
kubectl krew install rbac-tool && kubectl rbac-tool whoami
{Username: "testuser",
UID: "aws-iam-authenticator:911283464785:AIDA5ILF2FJIV65KG6RBM",
Groups: ["system:masters",
"system:authenticated"],
Extra: {accessKeyId: ["AKIA5ILF2FJIZJUZSG4D"],
arn: ["arn:aws:iam::911283464785:user/testuser"],
canonicalArn: ["arn:aws:iam::911283464785:user/testuser"],
...
|
cs |
5. [myeks-bastion] testuser 의 Group 변경(system:masters → system:authenticated)으로 RBAC 동작 확인
auth configmap을 수동으로 변경할 수 도 있다. master → authenticated 변경하고 사용해보면 작동을 안하는 걸 확인 할 수 있다.
|
1
2
3
4
5
6
|
# 방안2 : 아래 edit로 mapUsers 내용 직접 수정 system:authenticated
kubectl edit cm -n kube-system aws-auth
...
# 확인
eksctl get iamidentitymapping --cluster $CLUSTER_NAME
|
cs |
6. [myeks-bastion-2] testuser kubectl 사용 확인
인가 절차에서 RBAC에서 권한이 없기 때문에 동작 차단이 됐다.
|
1
2
3
4
|
# 시도
kubectl get node -v6
kubectl api-resources -v5
|
cs |
7. [myeks-bastion]에서 testuser IAM 맵핑 삭제
해당 매핑을 aws-auth config map에서 삭제하면 IAM user가 남아 있어도 kubectl이 작동되지 않는다.
|
1
2
3
4
5
6
|
# testuser IAM 맵핑 삭제
eksctl delete iamidentitymapping --cluster $CLUSTER_NAME --arn arn:aws:iam::$ACCOUNT_ID:user/testuser
# Get IAM identity mapping(s)
eksctl get iamidentitymapping --cluster $CLUSTER_NAME
kubectl get cm -n kube-system aws-auth -o yaml | yh
|
cs |
8. [myeks-bastion-2] testuser kubectl 사용 확인
|
1
2
3
4
|
# 시도
kubectl get node -v6
kubectl api-resources -v5
|
cs |
실습3 - EC2 Instance Profile(IAM Role)에 맵핑된 k8s rbac 확인 해보기
노드에 해당되는 IAM ARN은 쿠버네티스 내부에 system:node, system:bootstrappers 두 그룹에 매핑되어 있는 상태이다. 이 ARN 관리 워커노드가 프로비전될 때 매핑된 롤이 필요해서 설정이 이미 되어 있다.
1. 노드 mapRoles 확인 - 링크
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
# 노드에 호스트이름 확인
for node in $N1 $N2 $N3; do ssh ec2-user@$node hostname; done
# 노드에 STS ARN 정보 확인 : Role 뒤에 인스턴스 ID!
for node in $N1 $N2 $N3; do ssh ec2-user@$node aws sts get-caller-identity --query Arn; done
"arn:aws:sts::911283464785:assumed-role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-LHQ7DWHQQRZJ/i-07c9162ed08d23e6f"
"arn:aws:sts::911283464785:assumed-role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-LHQ7DWHQQRZJ/i-00d9d24c0af0d6815"
"arn:aws:sts::911283464785:assumed-role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-LHQ7DWHQQRZJ/i-031e672f89572abe8"
# aws-auth 컨피그맵 확인 >> system:nodes 와 system:bootstrappers 의 권한은 어떤게 있는지 찾아보세요!
# username 확인! 인스턴스 ID? EC2PrivateDNSName?
kubectl describe configmap -n kube-system aws-auth
...
mapRoles:
----
- groups:
- system:nodes
- system:bootstrappers
rolearn: arn:aws:iam::911283464785:role/eksctl-myeks-nodegroup-ng-f6c38e4-NodeInstanceRole-1OU85W3LXHPB2
username: system:node:{{EC2PrivateDNSName}}
...
# Get IAM identity mapping(s)
eksctl get iamidentitymapping --cluster $CLUSTER_NAME
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::911283464785:role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-1OS1WSTV0YB9X system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
...
|
cs |
2. awscli 파드를 추가하고, 해당 노드(EC2)의 IMDS 정보 확인 : AWS CLI v2 파드 생성
AWS CLI를 통해 파드를 추가 한다. 그리고 ARN을 확인 해보면 노드 ARN을 가지고 있다. 파드 내부에서 Token 탈취가 가능하고 이후 IAM 권한 내에서 모든 행동이 가능하다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
|
# awscli 파드 생성
cat <<EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
name: awscli-pod
spec:
replicas: 2
selector:
matchLabels:
app: awscli-pod
template:
metadata:
labels:
app: awscli-pod
spec:
containers:
- name: awscli-pod
image: amazon/aws-cli
command: ["tail"]
args: ["-f", "/dev/null"]
terminationGracePeriodSeconds: 0
EOF
# 파드 생성 확인
kubectl get pod -owide
# 파드 이름 변수 지정
APODNAME1=$(kubectl get pod -l app=awscli-pod -o jsonpath={.items[0].metadata.name})
APODNAME2=$(kubectl get pod -l app=awscli-pod -o jsonpath={.items[1].metadata.name})
echo $APODNAME1, $APODNAME2
# awscli 파드에서 EC2 InstanceProfile(IAM Role)의 ARN 정보 확인
kubectl exec -it $APODNAME1 -- aws sts get-caller-identity --query Arn
kubectl exec -it $APODNAME2 -- aws sts get-caller-identity --query Arn
# awscli 파드에서 EC2 InstanceProfile(IAM Role)을 사용하여 AWS 서비스 정보 확인 >> 별도 IAM 자격 증명이 없는데 어떻게 가능한 것일까요?
# > 최소권한부여 필요!!! >>> 보안이 허술한 아무 컨테이너나 탈취 시, IMDS로 해당 노드의 IAM Role 사용 가능!
kubectl exec -it $APODNAME1 -- aws ec2 describe-instances --region ap-northeast-2 --output table --no-cli-pager
kubectl exec -it $APODNAME2 -- aws ec2 describe-vpcs --region ap-northeast-2 --output table --no-cli-pager
# EC2 메타데이터 확인 : IDMSv1은 Disable, IDMSv2 활성화 상태, IAM Role - 링크
kubectl exec -it $APODNAME1 -- bash
-----------------------------------
아래부터는 파드에 bash shell 에서 실행
curl -s http://169.254.169.254/ -v
...
# Token 요청
curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" ; echo
curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" ; echo
# Token을 이용한 IMDSv2 사용
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
echo $TOKEN
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/ ; echo
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/ ; echo
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/meta-data/iam/security-credentials/ ; echo
# 위에서 출력된 IAM Role을 아래 입력 후 확인
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/meta-data/iam/security-credentials/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-1DC6Y2GRDAJHK
{
"Code" : "Success",
"LastUpdated" : "2023-05-27T05:08:07Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIxxxx",
"SecretAccessKey" : "rkexxxxxxx",
"Token" : "IQoJxxxxxx",
"Expiration" : "2023-05-27T11:09:07Z"
}
## 출력된 정보는 AWS API를 사용할 수 있는 어느곳에서든지 Expiration 되기전까지 사용 가능
# 파드에서 나오기
exit
---
|
cs |
IAM 사용자가 아닌 IAM Role로 등록되어 사용도 가능하다. 노드 탈취시에 EKS의 노드 권한들을 모두 사용 가능하다.
3. awscli 파드에 kubeconfig (mapRoles) 정보 생성 및 확인
IAM 사용자가 아닌 IAM Role로 등록되어 사용도 가능하다. 노드 탈취시에 EKS의 노드 권한들을 모두 사용 가능하다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
# node 의 IAM Role ARN을 변수로 지정
eksctl get iamidentitymapping --cluster $CLUSTER_NAME
NODE_ROLE=<각자 자신의 노드 Role 이름>
NODE_ROLE=eksctl-myeks-nodegroup-ng1-NodeInstanceRole-1DC6Y2GRDAJHK
# awscli 파드에서 kubeconfig 정보 생성 및 확인 >> kubeconfig 에 정보가 기존 iam user와 차이점은?
kubectl exec -it $APODNAME1 -- aws eks update-kubeconfig --name $CLUSTER_NAME --role-arn $NODE_ROLE
kubectl exec -it $APODNAME1 -- cat /root/.kube/config | yh
...
- --role
- eksctl-myeks-nodegroup-ng1-NodeInstanceRole-3GQR27I04PAJ
kubectl exec -it $APODNAME2 -- aws eks update-kubeconfig --name $CLUSTER_NAME --role-arn $NODE_ROLE
kubectl exec -it $APODNAME2 -- cat /root/.kube/config | yh
|
cs |
'스터디 > Kubernetes' 카테고리의 다른 글
| [AWES] EKS Automation - flux (1) | 2023.06.10 |
|---|---|
| [AWES] EKS Security - IRSA (0) | 2023.05.31 |
| [AWES] EKS - Karpenter (0) | 2023.05.28 |
| [AWES] EKS - Autoscaling (0) | 2023.05.27 |
| [AWES] EKS Observability (0) | 2023.05.21 |
