Kubernetes - User Management / RBAC

Introduction

This time, when I was checking the operation of RBAC, it became a story of user management.

User authentication settings

Kubernetes provides some authentication modules as standard, but this case I will use X509 Client Certs.

Creating a private key

Create the private key testuser.key and the signature request file testuser.csr.

$ openssl genrsa -out testuser.key 2048
Generating RSA private key, 2048 bit long modulus
.....................................+++
.......................................................................+++
e is 65537 (0x10001)
$ openssl req -new -key testuser.key -out testuser.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [Default Company Ltd]:testuser
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:testuser
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Creating a signature file

Create a signature file testuser.crt.

$ sudo openssl x509 -req -in testuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out testuser.crt -days 10000
Signature ok
subject=/C=XX/L=Default City/O=testuser/CN=testuser
Getting CA Private Key
$ ls
testuser.crt  testuser.csr  testuser.key

Adding the certificate to the API server

Add the created certificate to the API server.

$ kubectl config set-credentials testuser --client-certificate=testuser.crt --client-key=testuser.key --embed-certs=true
User "testuser" set.

Context settings

Check cluster name and existing Context

$ kubectl config get-clusters
NAME
kubernetes
$ kubectl config get-contexts
CURRENT   NAME                          CLUSTER      AUTHINFO           NAMESPACE
*         kubernetes-admin@kubernetes   kubernetes   kubernetes-admin

Creating Context

Create a Context for testuser.

$ kubectl config set-context testuser-context --user=testuser --cluster=kubernetes
Context "testuser-context" created.
$ kubectl config get-contexts
CURRENT   NAME                          CLUSTER      AUTHINFO           NAMESPACE
*         kubernetes-admin@kubernetes   kubernetes   kubernetes-admin
          testuser-context                kubernetes   testuser

Context switching

$ kubectl config use-context testuser-context
Switched to context "testuser-context".
$ kubectl config get-contexts
CURRENT   NAME                          CLUSTER      AUTHINFO           NAMESPACE
          kubernetes-admin@kubernetes   kubernetes   kubernetes-admin
*         testuser-context                kubernetes   testuser

Confirmation

At the moment, the authority is not set for testuser, so check that the kubectl command causes an error.

$ kubectl get pod
Error from server (Forbidden): pods is forbidden: User "testuser" cannot list resource "pods" in API group "" in the namespace "default"

Once confirmed, revert to the original Context.

$ kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".

RBAC settings

Use RBAC to set permissions for the testuser created so far. There are two types of RBAC,

• Role/Role Binding and
• Cluster Role/Cluster Role Binding.

Role/RoleBinding has a different setting range from Namespace level, and ClusterRole/ClusterRoleBinding has a different setting range from Cluster level.

Using RBAC Authorization

Settings of ClusterRole/ClusterRoleBinding

$ kubectl apply -f RoleCluster.yaml
clusterrole.rbac.authorization.k8s.io/readonly-for-all created
clusterrolebinding.rbac.authorization.k8s.io/readonly-for-test created

Check applied settings:

$ kubectl describe clusterrole readonly-for-all
Name:         readonly-for-all
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRole","metadata":{"annotations":{},"name":"readonly-for-all"},"rules":[{"apiGr...
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  *.*        []                 []              [get list watch]
             [*]                []              [get]
             [*]                []              [list]
             [*]                []              [watch]
$ kubectl describe clusterrolebinding readonly-for-test
Name:         readonly-for-test
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"readonly-for-test"},"roleRef...
Role:
  Kind:  ClusterRole
  Name:  readonly-for-all
Subjects:
  Kind  Name    Namespace
  ----  ----    ---------
  User  testuser

Operation check

Switch the Context and check the operation of RBAC.

$ kubectl config get-contexts
CURRENT   NAME                          CLUSTER      AUTHINFO           NAMESPACE
*         kubernetes-admin@kubernetes   kubernetes   kubernetes-admin
          testuser-context                kubernetes   testuser
$ kubectl config use-context testuser-context
Switched to context "testuser-context".
$ kubectl config current-context
testuser-context

I don’t have a pod, but the kubectl get pod command, which was in error before configuring RBAC, is returning successfully.Also, creating a pod has failed because you don’t have permission.

$ kubectl get pod
No resources found in default namespace.
$ kubectl apply -f nginx.yaml
Error from server (Forbidden): error when creating "nginx.yaml": pods is forbidden: User "testuser" cannot create resource "pods" in API group "" in the namespace "example"

Conclusion

The flow of user authentication is as follows. Since the verification environment this time is an on-premise environment, the API server and client will be on the same node. So, the only user switching is Context switching, and the OS user has not changed. Perhaps this setting will be useful when accessing a cluster on the cloud from outside the cluster.

RBAC itself should be linked with resources, and Role and Cluster Role are also prepared by default, so I think it is easy to understand.