[번역] A closer look at vSphere with Kubernetes Permissions
출처 : https://cormachogan.com/2020/07/10/a-closer-look-at-vsphere-with-kubernetes-permissions/
최근 vSphere with Kubernetes에 대한 많은 게시물에서 단일 사용자(administrator@vsphere.local)를 사용하여 모든 작업을 수행한다. 이를 통해 허가 걱정 없이 다양한 활동을 할 수 있다. 이 vSphere SSO(Single Sign-On) 관리자는 모든 vK8s 네임스페이스에 대해 "edit" 권한을 가지고 있다. 이 게시물에서는 서로 다른 일부 vSphere SSO 사용자와 사용 권한을 서로 다른 네임스페이스에 할당하는 방법과 이러한 사용 권한이 (Kubernetes ClusterRole 및 RoleBinding 구성을 통해) vK8s 플랫폼에서 구현되는 방법에 대해 살펴보고자 한다.
먼저 vK8s에서 네임스페이스가 어떻게 표시되는지 살펴봅시다. 기본적으로 네임스페이스에 할당된 사용 권한은 없다.
이제 네임스페이스 권한에 사용할 수 있도록 새 vSphere SSO 사용자를 생성해 부자. 새 사용자를 추가하는 절차는 Administration > Single Sign On > Users and Groups 아래의 vSphere Client에서 찾을 수 있다.
사용자가 생성되면 이제 네임스페이스 권한에 역할과 함께 추가할 수 있다. 사용자에게 할당할 수 있는 두 가지 간단한 역할이 있는데, view 또는 edit다..
이 테스트를 위해 사용자 cormac에게 네임스페이스 darren-ns에서는 볼 수 있지만 네임스페이스 cormac-ns에서는 편집할 수 있는 역할을 부여했다.
이제 사용자 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에서 구현되는 방법에 대한 좋은 통찰력을 얻으셨기를 바란다.
No Comments