This change replaces the usage of Service Tokens by OIDC tokens in the instructions of Kubernetes cluster local and remote access. Some other changes were made, like the deletion of redundant pages. Story: 2010738 Task: 49561 Change-Id: Ie8206ecd316efd356a5889899a68f9a9ddbcdfa6 Signed-off-by: Joao Victor Portal <Joao.VictorPortal@windriver.com>
4.2 KiB
Configure Users, Groups, and Authorization
In the examples provided below, Kubernetes permissions will be given to testuser user. Two different ways to do this are presented: in the first option, testuser user is directly bound to a role; in the second option, testuser is indirectly associated to a Kubernetes group that has permissions.
Note
For bigger environments, like a with many subclouds, or to minimize Kubernetes custom cluster configurations, use the second option, where permissions are granted through Kubernetes groups.
Grant Kubernetes permissions through direct role binding
Create the following deployment file and deploy the file with
kubectl apply -f
<filename>.kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: testuser-rolebinding roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: testuser
Grant Kubernetes permissions through groups
Create the following deployment file and deploy the file with
kubectl apply -f
<filename>.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cluster-reader-role rules: - apiGroups: ["*"] resources: ["*"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: cluster-reader-rolebinding subjects: - kind: Group name: k8s-reader apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: cluster-reader-role apiGroup: rbac.authorization.k8s.io --- # Note: the ClusterRole "cluster-admin" already exists in the system. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: cluster-admin-rolebinding subjects: - kind: Group name: k8s-admin apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: cluster-admin apiGroup: rbac.authorization.k8s.io
Create the groups k8s-reader and k8s-admin in your Windows Active Directory or server. See Microsoft documentation on Windows Active Directory <https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/ virtual-dc/active-directory-domain-services-overview>__ for additional information on adding users and groups to Windows Active Directory.
To give Kubernetes permissions to testuser, add this user in either the k8s-reader or k8s-admin groups in your Windows Active Directory or server, depending on the permissions you want to grant. The permissions are given because there is a mapping between a Windows Active Directory or group and a Kubernetes group with same name. To remove Kubernetes permissions from testuser user, remove this user from k8s-reader and k8s-admin groups in your Windows Active Directory or server.
Note
The group names k8s-reader and k8s-admin are arbitrary. As long as the Windows Active Directory or LDAP group have the same name as the Kubernetes group, the mapping will happen. For example, if a more company-specific approach is preferred, the groups k8s-reader and k8s-admin groups could be named after departments, like billingDeptGroup and managerGroup.