RBAC 관련 krew install을 해보겠습니다.
kubectl krew install access-matrix rbac-tool rbac-view rolesum whoami
rbac-tool
rbac-tool은 rbac에 대한 정보를 조회할 수 있도록 해줍니다.
kubectl rbac-tool lookup
조회하면 대략 위와 같은 모습인데요. 기본적으로 subject에 대한 role과 binding 정보를 보여주고 있습니다.
SUBJECT : 주체를 나타냅니다.
SUBJECT TYPE : ServiceAccount (애플리케이션 단), User(사용자), Group(그룹) 으로 분류됩니다.
SCOPE : clusterRole인지 그냥 Role인지 구분되며, Role이면 옆에 Namespace로 구분됩니다.
ROLE : 연결된 역할
BINDING : 연결된 바인딩
또한 다음과 같이 policy-rules에 대해서도 조회가 가능합니다. 여기서는 api에 대한 verb 정보 등을 확인할 수 있습니다.
kubectl rbac-tool policy-rules -e '^system:.*'
rolesum
rolesum은 깔끔하게 Resource에 대해 verbs를 확인할 수 있는 정보들이 있습니다.
rbac-view
rbac-view라고 입력만 하면 바로 웹서버가 켜지면서 정보를 수집합니다.
kubectl rbac-view
8800포트를 열어주고 들어가면 아래 웹 뷰가 나오는데요.. 와 정말 대박이네요 이런것도 되고.
해당 subject에 대해서 어떤 role이 어떤 verbs를 할 수 있는지에 대해서 잘 표시가 되어있습니다.
가시적으로 보거나 빠르게 찾아야할 때 정말 도움이 될 것 같습니다.
whoami
whoami 명령어는 현재 api를 요청하는 자격증명 주체의 정보를 보여줍니다.
kubectl whoami
이런 도구들을 보면 정말 좋은 툴이 많아졌다는걸 느낍니다. 옛날에 각 환경별로 verbs가 달라야하는 일이 있었는데, 이걸 위해서 제가 모든 클러스터에 한땀한땀 api를 따야했는데, 이런 기능들을 활용하면 그냥 중앙에서 손쉽게 관리하고 조회도 매우 빠르고 간편해졌다는것을 느낍니다.
EKS의 인증/인가
기본적으로 EKS의 인증인가 시스템의 핵심은 인증은 IAM에서 진행하고, 인가는 RBAC에서 처리한다고 볼 수 있습니다.
콘솔상 EKS > 액세스 탭에 들어가보면 클러스터 액세스 방식을 선택할 수 있습니다. 기본적으로 인증시스템은 원래 aws-auth라는 configMap을 통해서 허용했으나 점점 aws-auth는 deprecate 시키고, EKS API를 통한 방식으로 이동하는 추세입니다.
1. AWS STS , get-token으로 토큰정보 발행
STS(Security Token Service)로 AWS 리소스에 대한 액세스를 제어할 수 있는 임시 보안 자격 증명 서비스에 토큰정보를 요청하여 신뢰할 수 있는 사용자임을 확인합니다.
특히 이 때 aws eks get-token을 사용하는데 이는 kube-config정보에서 확인이 가능합니다.
cat ~/.kube/config
정확히 이부분 aws eks get-token --cluster-name myeks --region ap-northeast-2 --output json 이라고 되어있죠?
aws eks get-token을 확인해보면 다음과 같이 설명하고 있습니다.
Get a token for authentication with an Amazon EKS cluster. This can be used as an alternative to the aws-iam-authenticator.
즉 EKS cluster에서 authentication을 위해 토큰을 발행하는 로직입니다. 이는 aws-iam-authenticator를 대체한다고 설명하고 있습니다. 따라서 실제로 get-token 명령어를 사용해서 credential(토큰)을 획득할 수 있습니다.
aws eks get-token --cluster-name $CLUSTER_NAME | jq
이렇게 토큰의 만료시점도 작성되어 있습니다. 만료가 되면 토큰이 재발급됩니다.
"expirationTimestamp": "2025-03-15T14:30:26Z",
다음 명령어를 통해서 디버그도 해볼 수 있습니다. 보면 sts 쪽으로 요청을 진행하는 것을 확인할 수 있습니다.
aws eks get-token --cluster-name $CLUSTER_NAME --debug | jq
2. EKS API Cluster Endpoint로 요청
kubectl의 client-go 라이브러리가 pre-signed URL을 bearer token으로 EKS API Cluster Endpoint로 요청하게 됩니다.
3. EKS API가 Token Review를 Webhook token authenticator에 요청
즉 EKS에서는 AWS IAM에 토큰 리뷰를 요청한다. 기본적으로 AWS의 사용자가 맞는지 부터 확인을 받고나서 EKS 서비스를 이용해야하기 때문이다. 따라서 IAM 사용자가 맞다고 인정되면 Role/User의 ARN을 반환하게 된다.
api-resources를 확인해보면 authentication이 있는것을 확인할 수 있습니다.
kubectl api-resources | grep authentication
tokenreviews 정보를 확인해보면 토큰을 통해서 사용자를 인지한다고 합니다.
(james@myeks:N/A) [root@operator-host ~]# kubectl explain tokenreviews
GROUP: authentication.k8s.io
KIND: TokenReview
VERSION: v1
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.
4. ConfigMap 방식의 경우 쿠버네티스 RBAC 인가를 처리함
IAM에서 다시 반환하게 되는 IAM User/Role이 확인되면 쿠버네티스 aws-auth configmap에서 mapping 정보를 확인하게 됩니다.
configmap 방식을 활용하는 경우 아래의 aws-auth라는 configmap이 항상 존재해서 조회가 가능합니다.
kubectl get cm -n kube-system aws-auth -o yaml
실제로 신입사원이 와서 EKS에 접근권한을 주려면 어떻게해야할까?
다만 사실 실제로 내가 회사 다녔던 회사도 EKS를 사용했는데 여기서는 configMap을 활용해서 역시 했었습니다.
여기는 다만 group으로 아예 설정을 진행해두었고, 신입사원을 해당 group에만 넣어주면 알아서 통제가 가능했습니다.
1. 신규 유저 생성
먼저 다음과 같이 testuser를 생성하여 administrator 권한을 부여하였습니다.
# testuser 생성
aws iam create-user --user-name testuser
# 액세스키 생성
aws iam create-access-key --user-name testuser
# administrator 정책 부여
aws iam attach-user-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --user-name testuser
# sts 확인
aws sts get-caller-identity --query Arn
# kubectl whoami 확인 = sts와 동일
kubectl whoami
자세한 정보가 모두 비밀정보라서 아주 일부만 캡쳐하였습니다.
2. 이제 생성한 유저에 대한 자격증명을 세팅하고 kubectl을 시도해보자.
당연히 안될것이다. AWS 자체에 admin 권한이어도 kubernetes 상의 RBAC에는 등록된 정보가 전혀 없기 때문입니다.
3. 따라서 configmap에 등록해주자.
직접 등록해도되지만 eksctl을 통해 조금 더 간편하게 등록이 가능합니다. 다음과 같이 iamidentitymapping을 사용하면 aws-auth를 작성해줍니다.
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
4. testuser kubeconfig 생성 및 kubectl 사용
이제 등록을 완료했으니 kubeconfig를 생성하고 kubectl을 사용해보자. 잘 조회되는 것을 확인할 수 있습니다.
aws eks update-kubeconfig --name $CLUSTER_NAME --user-alias testuser
rbac-tool에서도 바로 system:masters로 변경된 것을 확인할 수 있습니다.
kubectl rbac-tool whoami
ConfigMap의 취약점
configMap은 이것만 수정하면 권한 자체가 너무 쉽게 바뀌고, 이걸 삭제해버리면 클러스터의 접근자체가 안된다는 맹점이 있습니다.
그냥 바로 edit 해보겠습니다.
kubectl edit cm -n kube-system aws-auth
mapUsers에서 testuser의 그룹을 system:authenticated로 변경해보겠습니다.
변경하는 즉시 node조회도 불가능한 것을 확인할 수 있습니다.
iamidentitymapping을 없애버리면 알아서 바로 configmap에서도 빠지게되고 바로 접근도 불가능하게 됩니다.
Instance Profile에 대해서
사실 각 worker node 역시 EKS의 리소스를 사용하기 때문에 해당 Role자체가 존재하고 있습니다.
각각의 워커노드에 role을 검색해보면 다음과 같이 mapping된 것을 확인할 수 있습니다.
실제로 콘솔에서 봐도 EKS 관련 권한 정책이 많이 설정되어 있는 것을 확인할 수 있습니다.
