Skip to main content

Manage Kubernetes users and roles

Reviewed on · View on GitHub

The managed Kubernetes service uses RBAC (Role-Based Access Control) to manage the permissions of a cluster Kubernetes. This page explains how to create and manage users, roles and permissions.

note

The Numspot API provides a kubeconfig with administrator rights. Fine-grained permission management is performed through Kubernetes manifests.

Connect to the Kubernetes cluster​

Before creating users or roles, connect to your cluster:

export KUBECONFIG=~/chemin/vers/kubeconfig
kubectl get nodes

To download the kubeconfig, see Download the kubeconfig.

RBAC concepts​

RBAC components​

ComponentScopeDescription
RoleNamespacePermissions within a namespace
ClusterRoleClusterPermissions across the whole cluster
RoleBindingNamespaceBinds a Role to a user/group
ClusterRoleBindingClusterBinds a ClusterRole to a user/group

Users and groups​

Kubernetes distinguishes:

  • Users: human accounts (external management);
  • ServiceAccounts: accounts for applications;
  • Groups: collections of users.

Create a Role​

A Role defines permissions within a namespace.

Basic syntax​

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: <role_name>
namespace: <namespace>
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]

Role examples​

Read-only Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: readonly
namespace: production
rules:
- apiGroups: [""]
resources: ["pods", "services", "configmaps", "secrets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["deployments", "replicasets", "statefulsets"]
verbs: ["get", "list", "watch"]

Developer Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: developer
namespace: production
rules:
- apiGroups: [""]
resources: ["pods", "services", "configmaps", "secrets"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["apps"]
resources: ["deployments", "replicasets"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
resources: ["pods/log", "pods/exec"]
verbs: ["get"]

Namespace administrator Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: namespace-admin
namespace: production
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]

Create a ClusterRole​

A ClusterRole defines permissions at cluster scope.

ClusterRole examples​

Cluster read-only ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-readonly
rules:
- apiGroups: [""]
resources: ["nodes", "namespaces", "persistentvolumes"]
verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]

Viewer ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: view
rules:
- apiGroups: [""]
resources: ["*"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["*"]
verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
resources: ["*"]
verbs: ["get", "list", "watch"]

Create a ServiceAccount​

ServiceAccounts are used by applications to authenticate.

Create a ServiceAccount​

apiVersion: v1
kind: ServiceAccount
metadata:
name: app-sa
namespace: production
kubectl apply -f serviceaccount.yaml

Create a ServiceAccount via the CLI​

kubectl create serviceaccount <name> -n <namespace>

Assign a role​

RoleBinding (namespace)​

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: readonly-binding
namespace: production
subjects:
- kind: User
name: <user>
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: readonly
apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding (cluster)​

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-view-binding
subjects:
- kind: User
name: <user>
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: view
apiGroup: rbac.authorization.k8s.io

Assign to a ServiceAccount​

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-sa-binding
namespace: production
subjects:
- kind: ServiceAccount
name: app-sa
namespace: production
roleRef:
kind: Role
name: developer
apiGroup: rbac.authorization.k8s.io

Modify a user or a role​

Modify a Role​

kubectl edit role <role_name> -n <namespace>

Modify a ClusterRole​

kubectl edit clusterrole <clusterrole_name>

Modify a RoleBinding​

kubectl edit rolebinding <rolebinding_name> -n <namespace>

Manage permissions​

Check permissions​

#Check if a user can perform an action
kubectl auth can-i <verb> <resource> --as=<user> -n <namespace>

#Exemples
kubectl auth can-i create pods --as=dev-user -n production
kubectl auth can-i delete secrets --as=dev-user -n production
kubectl auth can-i list nodes --as=dev-user

List a user's permissions​

kubectl auth can-i --list --as=<user> -n <namespace>

Revoke permissions​

Delete the RoleBinding to revoke the permissions:

kubectl delete rolebinding <rolebinding_name> -n <namespace>

Delete a user or a role​

Delete a ServiceAccount​

kubectl delete serviceaccount <name> -n <namespace>

Delete a Role​

kubectl delete role <role_name> -n <namespace>

Delete a ClusterRole​

kubectl delete clusterrole <clusterrole_name>

Delete a RoleBinding​

kubectl delete rolebinding <rolebinding_name> -n <namespace>
warning

Deleting a Role or ClusterRole is irreversible. Check that no RoleBinding depends on the role before deletion.

Best practices​

Principle of least privilege​

Grant only the permissions that are required:

  • use namespace Roles rather than ClusterRoles;
  • limit the verbs (get, list rather than *);
  • avoid * permissions on all resources.

Role organization​

User typeRecommended Role
DeveloperRole within a namespace with pods/deployments
OpsClusterRole with read access to nodes/pvs
Namespace adminRole with extended permissions

Credential rotation​

For ServiceAccounts:

#Delete and recreate the token
kubectl delete secret <secret_name> -n <namespace>
kubectl get serviceaccount <sa_name> -n <namespace> -o jsonpath='{.secrets[0].name}'

Access audit​

#List the roles
kubectl get roles --all-namespaces

#List the clusterroles
kubectl get clusterroles

#List the rolebindings
kubectl get rolebindings --all-namespaces

#List the clusterrolebindings
kubectl get clusterrolebindings

Audit and extraction of rights​

Export all RBAC rules​

kubectl get roles,rolebindings,clusterroles,clusterrolebindings --all-namespaces -o yaml > rbac-backup.yaml

List access by user​

kubectl get rolebindings,clusterrolebindings --all-namespaces -o json | jq '.items[] | select(.subjects[]?.name != null) | {name: .metadata.name, namespace: .metadata.namespace, subjects: .subjects, roleRef: .roleRef}'

Check sensitive access​

#Who can create pods
kubectl auth can-i create pods --all-namespaces

#Who can read secrets
kubectl auth can-i get secrets --all-namespaces

#Who can access the nodes
kubectl auth can-i list nodes

Use with external systems​

OIDC integration​

For critical deployments, configure an external OIDC (OpenID Connect) identity provider to authenticate users.

Bastion and proxy​

For sensitive architectures, use an SSH bastion or an access proxy:

  • centralize the connections;
  • enforce audit logs;
  • implement MFA authentication.

Limitations​

ActionSupport
Download the kubeconfigThrough the API or the console
Create RolesThrough kubectl only
Create ServiceAccountsThrough kubectl only
Manage ClusterRolesThrough kubectl only
Configure permissionsThrough YAML manifests
tip

Automate RBAC management with manifests versioned in your source control system. Use tools such as kustomize or helm to manage the RBAC configurations per environment.