Cluster가 생성되면 Cluster를 생성한 IAM 사용자 또는 역할의 ARN만 aws-auth ConfigMap에 추가된다. 또한 이 ARN에만 system:masters
권한이 포함된다. 즉, Cluster 생성자
만 다른 사용자 및 역할을 aws-auth ConfigMap에 추가
할 수 있다.(참고)
이번 글에서는 IAM 역할
을 생성해서 Bastion 서버(EC2)에 붙여준 후, IAM 역할
에 쿠버네티스 RBAC
를 사용하여 Pod
에 대한 읽기 권한을 부여해본다.
조직 내 개별 사용자의 역할을 기반으로 컴퓨터 또는 네트워크 리소스에 대한 액세스를 규제하는 방법
쿠버네티스 문서 - https://kubernetes.io/docs/reference/access-authn-authz/rbac/
Bastion에 대한 EKS IAM 역할을 생성하고 Role
및 RoleBinding
을 통해 해당 역할에 Pod
에 대해 get
, watch
, list
할 수 있는 권한을 부여해 보겠다.
IAM 콘솔에서 Bastion EC2에 연결할 역할을 만들어 준다.
AWS 서비스
→ EC2
를 선택해주고 검토
단계까지 다음을 누르고 이름을 정해준 후 역할을 생성한다.
EC2 콘솔로 이동하여 만든 IAM 역할
을 Bastion 서버(EC2)에 연결해준다.
kubectl edit -n kube-system configmap/aws-auth
명령어를 실행시켜 Configmap을 수정해준다.
처음 kubectl edit -n kube-system configmap/aws-auth
명령어를 실행시키면 다음과 같이 작성 되어져 있을 것이다.
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::90018*******:role/L23724-eks-node-role-tokyo
username: system:node:{{EC2PrivateDNSName}}
kind: ConfigMap
metadata:
creationTimestamp: "2021-04-22T03:43:04Z"
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:data:
.: {}
f:mapRoles: {}
manager: vpcLambda
operation: Update
time: "2021-04-22T04:35:30Z"
name: aws-auth
namespace: kube-system
resourceVersion: "182506"
selfLink: /api/v1/namespaces/kube-system/configmaps/aws-auth
uid: 38358930-4ed3-48e1-b9da-bf5344f5bbba
mapRoles
부분에 Bastion에 붙여준 IAM 역할을 다음과 같이 추가하고 저장해준다.
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws:iam::90018*******:role/L23724-bastion-eks-role
username: L23724-bastion-eks-role
저장하고 나오면 configmap/aws-auth edited
이라는 메시지가 출력된다.
Role
은 권한을 나타내는 규칙이 포함된다.
다음은 default
네임스페이스의 Pod
에 대한 읽기 액세스 권한을 부여할 수 있는 템플릿이다.
pod-read-role.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
아래 kubectl apply
명령어를 통해 pod-reader
라는 Role
을 생성한다.
[aylee@ip-24-0-0-228 ~]$ kubectl apply -f pod-read-role.yml
role.rbac.authorization.k8s.io/pod-reader created
RoleBinding
은 Role
에 정의 된 권한을 사용자 또는 사용자 집합에 부여한다.
다음은 방금 만든 IAM 역할(L23724-bastion-eks-role)에 Role(권한)을 부여할 수 있는 템플릿이다.
role-binding.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
name: L23724-bastion-eks-role
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io
아래 명령어를 통해 적용시켜준다.
[aylee@ip-24-0-0-228 ~]$ kubectl apply -f role-binding.yml
rolebinding.rbac.authorization.k8s.io/read-pods created
RoleBinding
이 완료되었다. 이제 Bastion 서버(EC2)에 연결되어있는 IAM 역할
에 권한(pod-reader 역할)
이 부여되었다.
RBAC
에 대한 자세한 내용은 아래 쿠버네티스 문서를 통해 확인
https://kubernetes.io/docs/reference/access-authn-authz/rbac/
aws sts get-caller-identity
명령어를 사용하면 designated_user에 대한 IAM 사용자 세부 정보가 표시 된다.
현재는 Bastion 서버 내에 aws configure
로 세팅한 사용자(Cluster 생성자)가 나온다.
[aylee@ip-24-0-0-228 ~]$ aws sts get-caller-identity
{
"Account": "90018*******",
"UserId": "AIDA5DFZMAR**********",
"Arn": "arn:aws:iam::90018*******:user/L23724"
}
다음 명령을 통해 aws configure
에 대한 설정을 모두 삭제해 준다.
rm -rf ~/.aws
다시 aws sts-get-caller-identity
명령어를 실행해주면 UserID
와 ARN
이 EC2에 붙어있는 IAM 역할
로 바껴있는 것을 볼 수 있다.
[aylee@ip-24-0-0-228 ~]$ aws sts get-caller-identity
{
"Account": "90018*******",
"UserId": "AROA5DFZMAR**********:i-0ef01f0daec2132a5",
"Arn": "arn:aws:sts::90018*******:assumed-role/L23724-bastion-eks-role/i-0ef01f0daec2132a5"
}
권한 부여가 잘 되었는지 보기 위해 kubectl
명령어를 실행해보면
[aylee@ip-24-0-0-228 ~]$ kubectl get svc
Error from server (Forbidden): services is forbidden: User "L23724-bastion-eks-role" cannot list resource "services" in API group "" in the namespace "default"
[aylee@ip-24-0-0-228 ~]$ kubectl get po
No resources found in default namespace.
권한을 주지 않은 Service
에 대한 리스트는 볼 수 없고 Pod
에 대한 리스트는 볼 수 있다.
(현재는 따로 Pod를 띄워 놓지 않았기 때문에 리소스가 없다고 나옴)
configmap 에 롤 추가 하고 role과 rolebinding 만 했다고 해서 aws sts-get-caller-identity 하면 designated_user 세부정보가 바뀌는게 이해가 안되네요...앞서 설정은 설정이지만 그게 designated_user의 aws sts까지 바꾼다는게..........그러면 configmap에 여러 롤을 추가하면 그리고 여러 role과 rolebinding을 추가하면 어떤 user의 aws sts와 연동이 되는지 좀 헷갈리네요
즉 cm이 여러그룹을 설정햇다면 .aws/ config 삭제후 aws sts get-caller-identity 하면 그중에 뭘로 셋팅되는지 어떤기준으로되나요?