[번역] A closer look at vSphere with Kubernetes Permissions

출처 : https://cormachogan.com/2020/07/10/a-closer-look-at-vsphere-with-kubernetes-permissions/

Cloud-Native-Apps-Icon-2020.png

최근 vSphere with Kubernetes에 대한 많은 게시물에서 단일 사용자(administrator@vsphere.local)를 사용하여 모든 작업을 수행한다. 이를 통해 허가 걱정 없이 다양한 활동을 할 수 있다. 이 vSphere SSO(Single Sign-On) 관리자는 모든 vK8s 네임스페이스에 대해 "edit" 권한을 가지고 있다. 이 게시물에서는 서로 다른 일부 vSphere SSO 사용자와 사용 권한을 서로 다른 네임스페이스에 할당하는 방법과 이러한 사용 권한이 (Kubernetes ClusterRole 및 RoleBinding 구성을 통해) vK8s 플랫폼에서 구현되는 방법에 대해 살펴보고자 한다.

먼저 vK8s에서 네임스페이스가 어떻게 표시되는지 살펴봅시다. 기본적으로 네임스페이스에 할당된 사용 권한은 없다.

0-vK8s-Permissions.png

이제 네임스페이스 권한에 사용할 수 있도록 새 vSphere SSO 사용자를 생성해 부자. 새 사용자를 추가하는 절차는 Administration > Single Sign On > Users and Groups 아래의 vSphere Client에서 찾을 수 있다.

1-Add-vSphere-SSO-User.png

사용자가 생성되면 이제 네임스페이스 권한에 역할과 함께 추가할 수 있다. 사용자에게 할당할 수 있는 두 가지 간단한 역할이 있는데, view 또는 edit다..

2-View-or-Edit-Permissions.png

이 테스트를 위해 사용자 cormac에게 네임스페이스 darren-ns에서는 볼 수 있지만 네임스페이스 cormac-ns에서는 편집할 수 있는 역할을 부여했다.

3-darren-ns.png

4-cormac-ns.png

이제 사용자 cormac으로 vK8s에 로그인하여 서로 다른 네임스페이스에서 수행할 수 있는 작업과 수행할 수 없는 작업에 대해 알아보자.

$ kubectl-vsphere login  --server=https://20.0.0.1 --insecure-skip-tls-verify --vsphere-username \
cormac@vsphere.local

Password:********
Logged in successfully.

You have access to the following contexts:
   20.0.0.1
   cormac-ns
   darren-ns

If the context you wish to use is not in this list, you may need to try
logging in again later, or contact your cluster administrator.

To change context, use `kubectl config use-context <workload name>`

이제 사용자 cormac은 네임스페이스 darren-ns에서만 볼 수 있다는 것을 기억하자. 네임스페이스 컨텍스트로 전환하여 해당 네임스페이스에서 사용자 cormac으로 영구 볼륨 클레임을 생성하려고 하면 어떻게 되는지 확인하자.

$ kubectl config get-contexts
CURRENT   NAME               CLUSTER         AUTHINFO                                NAMESPACE
*         20.0.0.1           20.0.0.1        wcp:20.0.0.1:cormac@vsphere.local
          cormac-ns          20.0.0.1        wcp:20.0.0.1:cormac@vsphere.local       cormac-ns
          darren-ns          20.0.0.1        wcp:20.0.0.1:cormac@vsphere.local       darren-ns


$ kubectl config use-context darren-ns
Switched to context "darren-ns".


$ kubectl apply -f block-pvc.yaml
Error from server (Forbidden): error when creating "block-pvc.yaml": persistentvolumeclaims is forbidden: \
User "sso:cormac@vsphere.local" cannot create resource "persistentvolumeclaims" in API group "" in the \
namespace "darren-ns"

우리가 알 수 있듯이, 사용자 cormac은 이 사용자가 해당 네임스페이스에 보기 역할만 가지고 있기 때문에 해당 네임스페이스에 새 개체를 만들 수 없다. 사용자 cormac이 편집 권한을 가진 네임스페이스 cormac-ns에서 유사한 작업을 시도해보자.

$ kubectl config use-context cormac-ns
Switched to context "cormac-ns".

$ kubectl apply -f ./Pacific/BT-DEMO/pacific-vsan-block-rwo/block-pvc.yaml
persistentvolumeclaim/block-pvc created
$

이 작전은 성공적이다. 그래서 어떻게 시행되는가? 사용자가 제공된 CLI 명령 kubectl-vsphere 로그인을 사용하여 vK8s에 로그인할 때 쿠베르네츠 환경에서는 쿠베르네츠 구성(일반적으로 .kube/config)이 클러스터, 컨텍스트 및 사용자 세부 정보로 업데이트된다는 점을 가장 먼저 알아야 한다. vK8s가 사용되도록 설정되면 토큰 Exchange 서비스가 vCenter 서버에서 실행됨 이렇게 하면 vSphere SSO 자격 증명이 필요하며 쿠베르네테스 RBAC와 함께 사용할 수 있도록 JSON 웹 토큰(JWT)으로 변환된다. 이를 통해 vSphere 사용자는 vK8s 클러스터에 로그인할 수 있다. 다음과 유사한 항목이 쿠베르네츠 구성 파일에 추가된다. 우리는 감독관 클러스터와 두 개의 네임스페이스 컨텍스트를 가지고 있지만, 모두 동일한 사용자를 가지고 있다. 구성 파일의 사용자 섹션에서 토큰을 볼 수 있다.

contexts:
- context:
    cluster: 20.0.0.1
    user: wcp:20.0.0.1:cormac@vsphere.local
  name: 20.0.0.1

- context:
    cluster: 20.0.0.1
    namespace: cormac-ns
    user: wcp:20.0.0.1:cormac@vsphere.local
  name: cormac-ns

- context:
    cluster: 20.0.0.1
    namespace: darren-ns
    user: wcp:20.0.0.1:cormac@vsphere.local
  name: darren-ns


- name: wcp:20.0.0.1:cormac@vsphere.local
  user:
    token: eyJraWQiOiI4QTVCNUMxREExNDUwMTg3QzMyQjI1NDBDMDBCQ0YzMUYzMkU2NEE3IiwiYWxnIjoiUlMyNTYifQ....

토큰은 로그인 시 할당되며 10시간 동안 지속된다. 일단 만료되면 사용자는 한 번 더 인증을 받아야 한다. 로그아웃 시 클러스터, 컨텍스트 및 사용자 토큰이 구성 파일에서 제거된다.

그러나 지금 발생하는 문제는 앞에서 본 사용 권한이 vSphere SSO에서 Kubernetes RBAC로 어떻게 전파되는가 하는 것이다. 이 사용자가 일부 네임스페이스에 대한 편집 권한을 가지고 있지만 다른 네임스페이스에 대한 사용 권한을 보는 방법 이를 이해하려면 ClusterRole 및 RoleBinding과 같은 Kubernetes 구성 요소를 살펴봐야 한다(참고: 이러한 구성 요소는 vK8s 네임스페이스가 아닌 Supervisor Control VM에서만 검사할 수 있음). 먼저 ClusterRoles 목록을 표시해 봅자. 여기서 다른 모든 역할 중에서 edit와 view라는 두 가지 역할이 있음을 알 수 있다. 이전에 네임스페이스 권한에서 보았던 역할 편집 및 보기에 매핑된 기능이다.

root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]# kubectl get ClusterRole
NAME                                                                   AGE
admin                                                                  2d1h
aggregate-workload-cluster-admin                                       2d1h
cluster-admin                                                          2d1h
edit                                                                   2d1h
ncp-cluster-role                                                       2d1h
ncp-patch-role                                                         2d1h
nsx-node-agent-cluster-role                                            2d1h
system:aggregate-to-admin                                              2d1h
system:aggregate-to-edit                                               2d1h
system:aggregate-to-view                                               2d1h
system:auth-delegator                                                  2d1h
system:basic-user                                                      2d1h
system:certificates.k8s.io:certificatesigningrequests:nodeclient       2d1h
system:certificates.k8s.io:certificatesigningrequests:selfnodeclient   2d1h
system:controller:attachdetach-controller                              2d1h
.
.
.
system:persistent-volume-provisioner                                   2d1h
system:public-info-viewer                                              2d1h
system:volume-scheduler                                                2d1h
view                                                                   2d1h
vmware-image-agent-clusterrole                                         2d1h
vmware-image-controller-clusterrole                                    2d1h
vmware-registry-manager-clusterrole                                    2d1h
.
.
.
wcp:guest-clusters-view                                                2d1h
wcp:guest-clusters-view-cluster-scope-vmresources                      2d1h
wcp:schedext-role-annotations                                          2d1h
wcp:schedext-role-namespaces                                           2d1h
root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]#

상상한 바와 같이, 두 역할의 주요 차이점은 view 역할이 일반적으로 개체를 가져오거나 나열하거나 감시할 수 있지만, edit 역할은 개체 생성, 삭제, 패치 및 업데이트와 같은 작업도 수행할 수 있다는 것이다. 역할에 대한 설명을 실행하면 역할과 관련된 전체 기능 집합을 볼 수 있다.

이제 네임스페이스에 대한 액세스를 제어하는 것으로 생각할 수 있는 RoleBindings에 대해 살펴봅시다. 우리는 사용자 cormac에게 두 개의 네임스페이스인 cormac-ns와 darren-ns를 할당한다. 이 사용자가 각 네임스페이스에 RoleBinding되어 있는 것을 볼 수 있다.

root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]# kubectl get RoleBinding -n cormac-ns
NAME                                               AGE
wcp:cormac-ns:group:vsphere.local:administrators   2d1h
wcp:cormac-ns:user:vsphere.local:administrator     89m
wcp:cormac-ns:user:vsphere.local:cormac            93m

root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]# kubectl get RoleBinding -n darren-ns
NAME                                               AGE
wcp:darren-ns:group:vsphere.local:administrators   25h
wcp:darren-ns:user:vsphere.local:administrator     89m
wcp:darren-ns:user:vsphere.local:cormac            90m

이제 RoleBindings를 자세히 살펴봅시다. 그러면 네임스페이스 cormac-ns의 cormac에 대한 RoleBinding이 ClusterRole을 편집하고, 네임스페이스 darren-ns의 RoleBinding은 ClusterRole만 볼 수 있다고 가정해보자. 정말 그렇다. 먼저 cormac-ns를 보자.

root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]# kubectl describe RoleBinding wcp:cormac-ns:user:vsphere.local:cormac -n cormac-ns

Name:         wcp:cormac-ns:user:vsphere.local:cormac
Labels:       managedBy=vSphere
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  edit
Subjects:
  Kind  Name                      Namespace
  ----  ----                      ---------
  User  sso:cormac@vsphere.local


root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]# kubectl get RoleBinding wcp:cormac-ns:user:vsphere.local:cormac -n cormac-ns -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: "2020-07-08T10:47:53Z"
  labels:
    managedBy: vSphere
  name: wcp:cormac-ns:user:vsphere.local:cormac
  namespace: cormac-ns
  resourceVersion: "1232328"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/cormac-ns/rolebindings/wcp:cormac-ns:user:vsphere.local:cormac
  uid: eec05c61-57a5-40ba-814c-7ade94c34011
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: edit
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: sso:cormac@vsphere.local
root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]#

cormac-ns의 RoleBinding에서 cormac이 사용하기 위한 edit clusterRole을 명확히 볼 수 있다. 다음에 darren-ns를 봅시다.

root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]# kubectl describe rolebinding wcp:darren-ns:user:vsphere.local:cormac -n darren-ns

Name:         wcp:darren-ns:user:vsphere.local:cormac
Labels:       managedBy=vSphere
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  view
Subjects:
  Kind  Name                      Namespace
  ----  ----                      ---------
  User  sso:cormac@vsphere.local


root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]# kubectl get rolebinding wcp:darren-ns:user:vsphere.local:cormac -n darren-ns -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: "2020-07-08T10:50:18Z"
  labels:
    managedBy: vSphere
  name: wcp:darren-ns:user:vsphere.local:cormac
  namespace: darren-ns
  resourceVersion: "1233346"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/darren-ns/rolebindings/wcp:darren-ns:user:vsphere.local:cormac
  uid: ac47c339-2503-40f6-8726-1b00ea243485
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: sso:cormac@vsphere.local

그리고 마지막으로 우리는 darren-ns 네임스페이스에서 cormac 사용자에게 사용되는 ClusterRole이 view다. 이 사용자가 앞서 PVC를 만들 수 없었던 이유다. 이를 통해 vSphere SSO 로그인이 ClusterRole 및 RoleBindings를 사용하여 Kubernetes와 함께 vSphere에서 구현되는 방법에 대한 좋은 통찰력을 얻으셨기를 바란다.


Revision #1
Created Sat, Jul 11, 2020 3:27 AM by ikhwan.koo
Updated Sat, Jul 18, 2020 5:37 AM by ikhwan.koo