[GCP]GKE 차근 차근 알아보기 6탄 — Cloud IAM 과 Kubernetes RBAC
안녕하세요 이정운 입니다.
지난번에 조금은 길었지만 GKE 환경에서 Cloud Build 를 활용하여 CI/CD 적용 설정 및 테스트까지 해보는 시간을 가졌었습니다. 해당 이야기를 진행하는 중간쯤에 Cloud Build 가 GKE cluster 환경을 제어하기 위하여 하단과 같이 Cloud IAM 을 통해서 특정 service account 에 conatiner.developer 권한을 매핑하는 작업을 진행했었습니다.
gcloud projects add-iam-policy-binding ${PROJECT} \
--member=serviceAccount:${@cloudbuild.gserviceaccount.com">PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
--role=roles/container.developer지난 이야기에서는 그부분이 메인이 아니어서 설명없이 간단히 넘어갔지만 이번 이야기에서 설명을 드려보면 언급된 Cloud IAM 은 Cloud Identity and Access Management 를 의미하여 Google cloud 에서 권한을 관리하고 접근을 제어할 수 있는 기능을 제공하는 기본 솔루션 입니다. 당연히 GKE 에 대한 접근 제한도 Cloud IAM 을 통해서 제어 가능합니다.
Cloud IAM 을 통해서 권한 관리를 할 수 있지만 GKE 는 Managed Kubernetes 이기 때문에 Kubernetes 자체에서 제공하는 RBAC 도 기본 지원 가능하므로 이를 통한 역할별 접근 제어 기능을 제공할 수도 있습니다
말이 나온 김에 이번 이야기에서는 짧게 GKE 관점에서 Cloud IAM 을 살펴보고 GKE 환경의 Kubernetes 관점의 RBAC 도 조금 살펴보는 시간을 가져 보도록 하겠습니다.
본 이야기는 하단과 같이 좋은 이야기를 기반으로 참고해서 작성되었습니다.
액세스 제어 개요
https://cloud.google.com/kubernetes-engine/docs/concepts/access-control?hl=ko
Using RBAC Authorization
https://kubernetes.io/docs/reference/access-authn-authz/rbac/
Making Sense of Kubernetes RBAC and IAM Roles on GKE
https://medium.com/uptime-99/making-sense-of-kubernetes-rbac-and-iam-roles-on-gke-914131b01922
Simplifying Granular Access Control on Kubernetes(GKE) Using IAM and RBAC
https://medium.com/google-cloud/simplifying-granular-access-control-on-kubernetes-gke-using-iam-and-rbac-19a627e3aa18
권한을 찾아서: GitHub Team을 이용하여 Kubernetes 계정 인증하기 (3)
https://medium.com/rainist-engineering/k8s-auth-with-github-team-part3-7e976adcf4c6
Demystifying RBAC in Kubernetes
https://www.cncf.io/blog/2018/08/01/demystifying-rbac-in-kubernetes/
Google cloud IAM 계정, 권한 및 조직 관리
https://www.slideshare.net/mobile/JerryJeong2/google-cloud-iam
#1) Cloud IAM
Cloud IAM 은 기 언급했지만 GCP 내에서 프로젝트와 리소스에 대한 접근을 관리하는 역할을 제공합니다. 프로젝트에 사용자를 추가한 후 프로젝트와 클러스터 내에서 작업을 수행할 수 있는 권한을 부여하는 역할을 사용자에게 할당 할 수 있으며 이를 통해서 해당 사용자에 대한 권한 제어가 가능합니다. 좀 더 쉽게 설명하면 ‘누가’ ‘어떤 자원에 대해서’ ‘무엇을 할수 있는지’ 에 대한 설정 및 제어 기능을 제공 할 수 있습니다.
여기에 덧붙여, GCP 의 특성 중에 하나인데 사람이 아니라 Service account 를 만들고 해당 Service account 에 권한을 부여할 수 있습니다. Service account 란 사용자를 대신하여 작업을 수행하는, 프로젝트에 연결된 Google 계정이며 이러한 Service account 에는 사용자와 동일한 방식으로 역할과 권한을 할당 할 수 있습니다. 다시 말해, Service account 는 반드시 사람이 아니라 머신이나 VM 에 부여할 수 있으며 이렇게 부여된 Service account 는 사용자와 동일한 방식으로 역할과 권한을 할당 할 수 있습니다.(예를 들어, 특정 사용자가 아니라 VM 자체에 특정 API 를 호출할 수 있는 권한을 부여 가능)
gcloud projects add-iam-policy-binding ${PROJECT} \
--member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
--role=roles/container.developer이전 이야기에서 사용된 상단과 같은 Cloud IAM 명령을 한번 살펴보면 roles/container.developer 라는 이름의 역할을 부여하고 있습니다. 이 역할을 실제 살펴보면 Kubernetes Engine Developer 라는 이름을 가지고 하단과 같이 267 개의 권한을 가진 미리 정의된 역할입니다.
역할을 확인해 보시면 아시겠지만 GKE 환경에 대한 접근을 가능하게 허용된 개발자 권한입니다. 이를 다시 해석해 보면 GKE 환경에서 구동중인 kubernetes 리소스에 접근 가능한 개발자 권한을 Service account 인 ${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com 로 부여한다는 의미 입니다. (참고로 ${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com 는 Cloud Build 가 기본으로 사용하는 Service account 입니다.) Service account 입장에서는 이제 GKE 환경에 대한 개발자 권한을 받았으며 그에 맞는 작업을 언제든 할 수 있다는 의미이기도 합니다.
해당 명령 수행 후에 관리콘솔에서 IAM&Admin > IAM 메뉴를 클릭하면 하단과 같이 ${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com 이 기본 가지고 있는 Cloud Build Service account 에 더해서 Kubernetes Engine Developer 권한이 추가된 것을 확인할 수 있습니다.
좀 더 들어가보면 roles/container.developer 는 개발자에게 필요한 각각의 권한을 사전 정의해 둔 역할을 의미하며 Cloud IAM 에는 다음과 같이 GKE 를 위한 사전 정의된 역할을 더 가지고 있습니다. 다시 말하면 필요시 Cloud IAM 의 사전 정의해 둔 역할의 할당을 통해서 GKE 에 대한 권한 배분이나 관리가 가능하다는 의미 입니다.
https://cloud.google.com/kubernetes-engine/docs/how-to/iam
#2) Kubernetes RBAC
Kubernetes 에서 제공하는 RBAC 은 Role Based Access Control 을 의미하며 역할 기반 접근 제어를 의미합니다. Kubernetes 기본 액세스 제어 API를 사용하여 클러스터 또는 네임스페이스 수준에서 Kubernetes 리소스와 작업을 위한 세분화된 권한이 있는 역할(Role)을 만들 수 있는 기능을 제공할 수 있으며 역할을 만든 후 역할을 사용자와 Kubernetes 서비스 계정에 할당하는 역할결합(RoleBinding) 을 만들어서 연결 가능합니다. 특히나, Kubernetes RBAC 은 Kubernetes 내부의 액세스 제어에 이미 익숙하고 클라우드와 상관없는 방식의 액세스 관리를 선호하는 경우에 유용합니다.
역할 기반 액세스 제어
https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control
상단의 링크에 자세한 설명이 있지만 Cloud IAM은 프로젝트별 기준으로 작동하게 되며 사용자가 특정 GCP 프로젝트에 있는 클러스터에 액세스하기 위해서는 프로젝트 수준의 권한이 필요합니다. 그에 비해서 Kubernetes RBAC 권한은 각 클러스터 내의 리소스 액세스에 대해 세부적인 제어 기능을 제공하기 때문에 프로젝트 수준의 권한 없이도 클러스터에 있는 리소스 사용을 제어 가능합니다. 그렇기 때문에 Cloud IAM 과 Kubernetes RBAC 은 함께 조합해서 사용할 수도 있으며 필요시 더 세밀한 제어를 가능하게 만들수 있습니다.
https://medium.com/uptime-99/making-sense-of-kubernetes-rbac-and-iam-roles-on-gke-914131b01922
Kubernetes RBAC 을 사용하려면 Role 이나 ClusterRole 이라는 객체를 생성한 후 RoleBinding 이나 ClusterRoleBinding 을 사용해서 연관된 역할과 사용자를 연결해주면 됩니다. 여기서 Role 과 ClusterRole 은 이름을 보면 알겠지만 동일하게 역할을 지정하는 기능을 수행하지만 ClusterRole 은 이름 그대로 범위가 더 넓은 클러스터 레벨이나 리소스 단위가 아닌 엔드포인트(예: /healthz) 등에 적용할 수 있는 객체입니다.
실제 하단과 같이 GKE 환경에서 기본 생성되어 있는 Role 을 확인 가능합니다.
kubectl get role — all-namespaces또한, 하단의 kubectl 명령을 통해서 Role 의 상세 내용도 확인 가능합니다.
kubectl get role gce:cloud-provider -n kube-system -o=yaml당연한 이야기 이겠지만 ClusterRole 도 하단과 같이 확인 가능합니다. 보시면 아시겠지만 더 넓은 클러스터 단위의 역할을 의미하기 때문에 namespace 와 연동되지 않은 admin, edit 등의 역할도 확인할 수 있다는 것을 보실 수 있습니다.
kubectl get clusterroles예를 들어 현재의 account 를 확인한 후 kubectl 명령을 통해서 해당 사용자에게 cluster-admin 권한을 하단과 같은 방식으로 clusterrolebinding 을 만들어서 제공 가능합니다.
gcloud info | grep Accountkubectl create clusterrolebinding myname-cluster-admin-binding — clusterrole=cluster-admin — user=jwlee98@gmail.comkubectl get clusterrolebindingkubectl get clusterrolebinding myname-cluster-admin-binding -o=yaml#3) Cloud IAM & RBAC
Kubernetes 에서 제공하는 RBAC 을 위해서 User 를 생성하려면 하단의 링크에서 확인되는 것과 같이 credential 을 만들기 위해서 key 생성과 같은 번거로운 작업을 거쳐야 합니다.
Configure RBAC In Your Kubernetes Cluster
https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/
어떻게 보면 간단할 수도 있겠지만 credential 을 만들고 관리하기 위해서는 key 생성과 같은 많은 부수적인 작업들이 추가되어야 합니다. 이를 GCP 에서 제공되는 Cloud IAM 을 활용하게되면 좀 더 편리하게 조합해서 활용할 수 있습니다. 예를 들어 새로운 개발자가 들어와서 해당 개발자에게 권한을 제공해야 한다고 가정하면 관리콘솔의 Cloud IAM 을 통해서 하단과 같이 프로젝트의 viewer 권한을 제공할 수 있습니다.
이제 해당 개발자는 GCP 프로젝트에 Viewer 권한을 얻었으므로 해당 개발자로 새로 GCP 관리콘솔에 로그인 하게 되면 프로젝트의 GKE cluster 에 접근 가능합니다. 그러나 Cloud IAM 상의 viewer 권한만 있기 때문에 보는 것은 가능하나 하단과 같이 GKE 의 상태를 변경하는 작업을 수행하게 되면 권한이 없다는 오류를 받게 됩니다.
gcloud info | grep Account
kubectl scale deployment gceme-frontend-production -n production — replicas=3여기서 개발자에게 GKE cluster 를 변경하는 것도 허용하고자 한다면 다시 임시 개발자 계정이 아니라 원래 계정으로 돌아와서 해당 개발자에게 하단과 같이 RoleBinding 을 만들어서 ‘edit’ 라는 미리 정의된 ClusterRole 을 부여해 주면 됩니다. (당연히 Cloud IAM 을 통하여 추가 권한을 줘도 가능합니다.)
-----rolebinding-edit.yaml-----
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: edit-role
namespace: production
subjects:
- kind: User
name: jungwoon@freejava.co.kr
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: edit
apiGroup: rbac.authorization.k8s.io
-----rolebinding-edit.yaml-----kubectl create -f rolebinding-edit.yaml
RoleBinding 을 통해서 Cloud IAM 으로 추가한 개발자 계정에 ‘edit’ 권한 부여가 완료되었다면 다시 개발자 계정으로 들어가서 권한 문제가 있었던 kubectl scale 명령을 수행하여 pod 의 replica 를 증가시켜 봅니다.
kubectl scale deployment gceme-frontend-production -n production — replicas=3보시면 아시겠지만 Cloud IAM 으로 생성된 개발자 계정에 Kubernetes RBAC 을 이용하여 ‘edit’ 권한이 부여되어서 문제없이 kubectl scale 명령을 수행할 수 있는 것을 확인 가능합니다.
여기까지 잘 따라오셨다면 간단하게 GCP 내에서 프로젝트와 리소스에 대한 액세스를 관리하는 역할을 제공하는 Cloud IAM 과 Kubernetes RBAC 을 간단하게 잘 살펴본 것입니다. 간략하게 소개드렸긴 하지만 실제적으로 프로젝트를 수행하거나 직접 권한 관리를 수행하게 되면 많이 어려워지는 부분이오니 한번씩 더 챙겨서 연습해 보시기 바라겠습니다.
그럼 이번 이야기는 여기서 줄이도록 하겠으며 다음에 다시 돌아오도록 하겠습니다. 휘리릭~~~~
* Disclaimer: 본 글의 작성자는 Google 직원이지만 Google cloud 를 공부하는 한 개인으로서 작성된 글입니다. 본 글의 내용, 입장은 Google 을 대변하지 않으며 Google 이 해당 콘텐츠를 보장하지 않습니다.
