EKS Starter - 4. 사용자 관리 및 RBAC

https://www.udemy.com/course/amazon-eks-starter-kubernetes-on-aws/ 참고

먼저 EKS를 제어할 수 있는 또 다른 Admin 사용자를 추가해보자.
IAM에 아무런 권한이 없는 프로그래밍 전용 계정을 생성해준다.

다음으로 Configmap을 설정한다. Configmap은 컨테이너에서 필요한 환경설정 내용을 컨테이너와 분리해서 제공해주기 위한 기능이다. 환경설정에는 디버그 로그 레벨, 연결할 DB, 접근해야 할 사용자 등등 다양한 조건들이 들어갈 수 있다. 만약 환경설정 파일을 컨테이너와 분리하지 않는다면 완벽하게 동일하게 서비스를 하는 컨테이너라도 DEV냐 PRD냐에 따라 환경은 달라질 수 있기 때문에 DEV용 컨테이너, PRD용 컨테이너로 각각 컨테이너를 만들어줘야 하는 불편함이 있다. 하지만, Configmap을 컨테이너와 분리한다면 컨테이너는 1개만 두고 DEV용 환결설정 파일 PRD용 환경설정 파일만 만들어주면 되므로 좀 더 가볍게 구성할 수 있다.

먼저 현재 설정되어 있는 configmap 정보를 불러와보자.
kubectl -n kube-system get cm

aws-auth 에 관련 된 configmap도 존재하는 것을 볼 수 있다.
어떤 내용이 적혀 있는지 확인하고 수정하기 위해 아래와 같이 yaml 파일로 현재 aws-auth 내용을 내보내기 한다.
kubectl -n kube-system get configmap aws-auth -o yaml > aws-auth-configmap.yaml

그리고 yaml 파일을 열어보자.

위 캡쳐를 보면 기본적으로 mapRoles에 node들에 대한 Role이 정의되어 있다. 만약 사용자를 추가하려면 mapUsers:에 해당 사용자 계정과 롤을 넣으면 된다. (참고로 AWS EKS는 클러스터를 생성한 IAM user에게 system:mastes 권한을 부여한다.) admin 권한을 주는 예제이다. 만약, 다른 권한들을 알고 싶다면 kubernetes.io/docs/reference/access-authn-authz/rbac/ 를 참고하면 된다.

그리고 적용해주자.
kubectl apply -f aws-auth-configmap.yaml -n kube-system

kubectl -n kube-system describe cm aws-auth

kubectl에 사용자 계정을 admin으로 추가해줬으니, 이제 kubectl이 설치된 시스템의 AWS credentials에 해당 사용자 계정의 액세스키와 시크릿키를 넣어주자.

현재 AWS CLI의 사용자를 확인해보자.
aws sts get-caller-identity

이제 아까 생성한 k8s-cluster-admin으로 AWS CLI 사용자를 변경해보자.
export AWS_PROFILE="clusteradmin"

이후 kubectl get nodes 등등 클러스터를 관리하기 위한 명령이 모두 성공하는 것을 볼 수 있다.

kubectl -n kube-system get po

마지막으로 클러스터에서 이미지를 실행할 수 있는지도 테스트해보자.
kubectl run nginx --image=nginx --restart=Never

그리고 삭제하자.
kubectl delete pods nginx

이제 admin 권한이 아닌 read-only 권한을 주자.
그 전에 먼저 네임스페이스에 대한 내용을 알아보자. 네임스페이스란 오브젝트를 논리적으로 분리할 수 있는 논리적인 파티션이라고 할 수 있다.
kubectl get ns 명령으로 한번 네임스페이스를 확인해보자.

default(기본 네임스페이스), kube-node-lease(노드의 가용성 체크를 위한 네임스페이스이며, 하트비트 lease 오브젝트 존재), kube-public(모든 사용자가 read 권한으로 접근이 가능한 네임스페이스), kube-system(클러스터 핵심 리소스 배치 네임스페이스)

production 환경의 네임스페이스를 읽을 수 있는 IAM User를 생성한다고 가정하고 네임스페이스부터 생성하자.

kubectl create namespace production

kubectl get ns

이후 IAM 콘솔에서 아무런 권한이 없는 사용자를 생성하자.

그리고 role을 추가하기 위한 role.yaml 파일을 하나 생성하자.

Kind에 Role가 있으니 Role에 대한 것이며 metadata의 namespace를 production으로 지정하면서 특정 네임스페이스에 대한 제한을 뒀다. 이외에도 resoures나 verbs 등에 제한을 둘 수 있는 것을 볼 수 있다.

그리고 해당 role을 바인딩할 rolebinding.yaml을 생성하자.

그리고 적용하자
kubectl apply -f role.yaml

앞의 2개의 yaml 파일의 appapi 버전에 문제가 있는 것 같다. 경고 메시지의 권고와 같이 수정 후 다시 적용해보자.
별다른 에러없이 잘 적용된다.

바인딩 파일도 적용하자.
kubectl apply -f rolebinding.yaml

이제 생성한 prod-viewer 사용자를 쿠버네티스 aws-auth 네임스페이스에 추가하자.
kubectl -n kube-system get configmap aws-auth -o yaml > aws-auth-configmap.yaml
vi aws-auth-configmap.yaml

kubectl apply -f aws-auth-configmap.yaml

이제 prod-viewer를 aws cli credentials에 추가하자.

저장한 계정 정보를 환경 변수에 넣고 잘 적용되었는지 확인해보자.
export AWS_PROFILE="productionviewer"

이제 설정한 role 대로 잘 동작하는지 확인해보자.

kubectl get nodes -> default 네임스페이스에서 get 실패

kubectl -n kube-system get po -> kube-system 네임스페이스에서 get 실패

kubectl -n production get po -> production 네임스페이스에서 get 성공

kubectl run nginx --image=nginx --restart=Never -n production -> production 네임스페이스 이지만 read 권한이 아닌 run 이므로 실패