Practical use of RBAC authentication

Practical use of RBAC authentication

Official documentation

Create a ClusterRole named deployment-clusterrole, which has the permission to create Deployment, Statefulset, and Daemonset. Create a name cicd- in the namespace rbac-test token‘s ServiceAccount, binding

ClusterRole to ServiceAccount and namespace qualified to rbac-test .

My k8s cluster information:

root@k8s-master:~# kubectl get node -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
k8s-master Ready control-plane,master 692d v1.22.0 192.168.123.150 <none> Ubuntu 18.04.5 LTS 4.15.0-213-generic docker://20.10.0
k8s-node1 Ready <none> 692d v1.22.0 192.168.123.151 <none> Ubuntu 18.04.5 LTS 4.15.0-213-generic docker://20.10.0
k8s-node2 Ready <none> 692d v1.22.0 192.168.123.152 <none> Ubuntu 18.04.5 LTS 4.15.0-213-generic docker://20.10.0

Create namespace dev

root@k8s-master:~# kubectl get ns rbac-test --show-labels
NAME STATUS AGE LABELS
rbac-test Active 17s kubernetes.io/metadata.name=rbac-test

?Create ClusterRole

?ClusterRole

ClusterRole contains a set of rules that represent related permissions.

ClusterRole is a cluster-scoped resource. The two resources have different names (Role and ClusterRole) because Kubernetes objects are either namespace scoped or cluster scoped, not both.

ClusterRole has several uses. You can use it to:

  1. Defines access rights to domain objects in a namespace and will be granted access rights within individual namespaces;
  2. Set access permissions for namespace-scoped objects and be granted access across all namespaces;
  3. Define access permissions for cluster-scoped resources.

If you want to define a role within a namespace, you should use Role; if you want to define a cluster-wide role, you should use ClusterRole.

clusterrole.yml

apiVersion: rbac.authorization.k8s.io/v1
kind:ClusterRole
metadata:
  # "namespace" is ignored because ClusterRoles are not namespace restricted
  name: deployment-clusterrole
rules:
- apiGroups: [""]
  resources: ["deployments","statefulsets","daemonsets"]
  verbs: ["create"]

View clusterrole information:

root@k8s-master:~# kubectl apply -f clusterrole.yml
clusterrole.rbac.authorization.k8s.io/deployment-clusterrole created
root@k8s-master:~# kubectl describe clusterrole deployment-clusterrole
Name: deployment-clusterrole
Labels: <none>
Annotations: <none>
PolicyRule:
  Resources Non-Resource URLs Resource Names Verbs
  --------- ----------------- -------------- -----
  daemonsets [] [] [create]
  deployments [] [] [create]
  statefulsets [] [] [create]

Create ServiceAccount

Service Account in Kubernetes is a resource used to provide identity and access control for Pods. Service Accounts allow the establishment of trust relationships between workloads (such as Pods) and other resources in a Kubernetes cluster so that these workloads can communicate securely with the API server and access other resources in the cluster.

The following are the key features and functions of Service Accounts:

  1. Identity: Each Pod can be associated with a Service Account. When an application within a Pod needs to interact with the Kubernetes API server or other RBAC-controlled resources, it can use its Service Account to obtain an identity. This helps ensure that workloads running in the cluster have controlled identities.
  2. Access Control: Service Accounts are used with Kubernetes’ RBAC (Role-Based Access Control) to control which operations and resources can be performed by Pods. By associating a Service Account with a specific role (Role) or role binding (RoleBinding), you can define which permissions are assigned to Pods.
  3. Credentials: Each Service Account is associated with a Secret object, which contains a token and other credential information for authentication. Applications in the Pod can use these credentials to communicate with the Kubernetes API server to obtain necessary information or perform actions.
  4. Default Service Account: Each namespace has a default Service Account named “default”. If you do not explicitly specify a Service Account when creating a Pod, the Pod will automatically use this default Service Account. The default Service Account usually has lower permissions and is generally not recommended for use in production environments.

Service Accounts are useful because they allow you to provide identities and permissions to different workloads in a secure and controlled manner, while ensuring that resource access is subject to strict access controls. Service Accounts are a very important tool when you need to implement fine-grained permission control and identity management in a Kubernetes cluster.

root@k8s-master:~# kubectl create serviceaccount cicd-token -n rbac-test
serviceaccount/cicd-token created
root@k8s-master:~# kubectl describe serviceaccount cicd-token -n rbac-test
Name: cicd-token
Namespace: rbac-test
Labels: <none>
Annotations: <none>
Image pull secrets: <none>
Mountable secrets: cicd-token-token-t74pm
Tokens: cicd-token-token-t74pm
Events: <none>

Bind role

Role Binding is to assign the permissions defined in the role to one or a group of users. It contains a list of several Subjects (users, groups, or service accounts) and references to the roles these subjects have acquired. RoleBinding performs authorization within a specified namespace, while ClusterRoleBinding performs authorization cluster-wide.

A RoleBinding can reference any Role in the same namespace. Alternatively, a RoleBinding can reference a ClusterRole and bind the ClusterRole to the same namespace as the RoleBinding. If you want to bind a ClusterRole to all namespaces in the cluster, you use ClusterRoleBinding.

kubectl -n rbac-test create rolebinding cicd-clusterrole --clusterrole=deployment-clusterrole --serviceaccount=rbac-test:cicd-token

root@k8s-master:~# kubectl describe rolebinding -n rbac-test
Name: cicd-clusterrole
Labels: <none>
Annotations: <none>
Role:
  Kind: ClusterRole
  Name: deployment-clusterrole
Subjects:
  Kind Name Namespace
  ---- ---- ---------
  ServiceAccount cicd-token rbac-test