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 DC 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

1. 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

1. 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
   

2. Create the groups k8s-reader and k8s-admin in your Windows Active Directory or LDAP server. See Microsoft documentation on Windows Active Directory for additional information on adding users and groups to Windows Active Directory.

3. To give Kubernetes permissions to testuser, add this user in either the k8s-reader or k8s-admin groups in your Windows Active Directory or LDAP server, depending on the permissions you want to grant. The permissions are given because there is a mapping between a Windows Active Directory or LDAP 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 LDAP 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.