In Kubernetes, there are several ways to manage and organize users within a cluster. Here are the main approaches:
Role-Based Access Control (RBAC)
Create users with certificates:
# Generate private key
openssl genrsa -out user.key 2048
# Create certificate signing request
openssl req -new -key user.key -out user.csr -subj "/CN=username/O=group"
# Sign the certificate (using cluster CA)
openssl x509 -req -in user.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out user.crt -days 365Create kubeconfig for user:
kubectl config set-credentials username --client-certificate=user.crt --client-key=user.key
kubectl config set-context username-context --cluster=cluster-name --user=usernameService Accounts (for applications)
# Create service account
kubectl create serviceaccount my-service-account
# Create role
kubectl create role pod-reader --verb=get,list,watch --resource=pods
# Bind role to service account
kubectl create rolebinding read-pods --role=pod-reader --serviceaccount=default:my-service-accountClusterRoles and ClusterRoleBindings
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-admin-custom
rules:
- apiGroups: [""]
resources: ["*"]
verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin-binding
subjects:
- kind: User
name: admin-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin-custom
apiGroup: rbac.authorization.k8s.ioNamespace-based isolation
# Create namespace for team
kubectl create namespace team-dev
# Create role within namespace
kubectl create role dev-access --verb=get,list,create,delete --resource=pods,services -n team-dev
# Bind user to namespace role
kubectl create rolebinding dev-binding --role=dev-access --user=dev-user -n team-devExternal authentication integration
OIDC (OpenID Connect):
# In kube-apiserver configuration
--oidc-issuer-url=https://your-oidc-provider.com
--oidc-client-id=kubernetes
--oidc-username-claim=email
--oidc-groups-claim=groupsLDAP integration (often through external tools like Dex or Keycloak)
Common user management patterns
Development teams:
- Create namespaces per team/project
- Use RoleBindings within namespaces
- Limit resource quotas per namespace
Multi-tenancy:
- Network policies for isolation
- Resource quotas and limits
- Separate service accounts per tenant
Checking current permissions:
# Check what current user can do
kubectl auth can-i --list
# Check specific user permissions
kubectl auth can-i get pods --as=system:serviceaccount:default:my-saThe key is combining RBAC with namespaces and potentially external authentication systems to create a secure, organized user management structure that fits your organization’s needs.
Theory
So how do we create a role?
Role Creation
We do that by creating a role object.
So, we create a role definition file
with the API version set to our back.authorization.K.IU/V1 and kind said to role, we name the role developer as we are creating this role for developers,
and then we specify rules. Each rule has three sections: API groups, resources, and works.
The same things that we talked about in one of the previous lectures.
For Core group you can leave the API group section as blank.
For any other group, you specify the group name.
The resources that we want to give developers access to are pods.
The actions that they can take are list, get, create, and delete.
Similarly, to allow the developers to create conflict maps,
we add another rule to create config map.
You can add multiple rules for a single role like this.
Create the role using the cube control create roll command.
Role Binding
The next step is to link the user to that role.
For this, we create another object called roll binding.
The roll binding object links a user object to a role.
We will name it dev user to Developer Binding.
The kind is role binding.
It has two sections.
The subjects is where we specify the user details.
The roll ref section is where we provide the details
of the roll we created.
Create the role binding using the
cube control create command.
Transclude of RBAC---Practice-Test#^f7d277
Namespace relation to role bindings
Also note that the roles and role bindings fall under the scope of name spaces.
So here the dev user gets access to pot and convict maps within the default name space.
If you want to limit the dev user’s access within a different name space then specify the name space within the metadata of the definition file while creating them.
View Roles and Role Bindings
To view the created roles,
update a deployment, watch a deployment, et cetera.
Link to originalThese are known as verbs.
run the cube control get rolls command.
To list role bindings, run the cube control,
get roll bindings command.
To view more details about the role, run the cube control
describe role developer command.
Here you see the details about the resources and permissions
for each resource.
Similarly, to view details about rule bindings
run the cube control, describe rolled bindings command.
Here you can see details about an existing role binding.
Check Users’ access in the cluster
What if you being a user would like to see if you have access to a particular resource in the cluster?
You can use the Q control oath can I command,
and check if you can say, create deployments,
or say delete notes.
Check access of the users as an Admin
If you’re an administrator, then you can even
impersonate another user to check their permission.
For instance, say you were tasked to create necessary set
of permissions for a user to perform
a set of operations, and you did that,
but you would like to test if what you did is working.
You don’t have to authenticate as the user to test it.
Instead, you can use the same command
with the AS user option like this.
Since we did not grant the developer permissions
to create deployments, it returns no.
The dev user has access to creating pods though.
You can also specify the name space in the command
like this, the dev user does not have permission to
create a pod in the test name space.
Well, a quick note on resource names.
We just saw how you can provide access
to users for resources like pods within the name space.
You can go one level down
and allow access to specific resources alone.
For example, say you have five parts in namespace
you wanna give access to a user to pods, but not all pods.
You can restrict access to the blue and orange pod alone
by adding a resource names field to the rule.