Roles

Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise.

Module

Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise.

Overview

At the end of this module, you will :

  • Learn to restrict access of resources

  • Learn to manage roles

  • Learn to secure the cluster access

Prerequisites

Create the directory data/roles in your home folder to manage the YAML file needed in this module.

mkdir ~/data/roles

Create

Kubernetes role-based access control (RBAC) system lets exercise fine-grained control over how users access the API resources running on a cluster. RBAC can be use to dynamically configure permissions for the cluster's users and define the kinds of resources with which users can interact.

RBAC allow to create permissions that apply to an entire cluster, or to specific namespaces within a cluster. Cluster-wide permissions are useful for limiting certain users' access to specific API resources (such as security policies or Secrets). Namespace-specific __permissions are useful when multiple groups of users operating within their own respective namespaces. RBAC can help to ensure that users only have access to cluster resources within their own namespace.

RBAC uses the rbac.authorization.k8s.io API group to drive authorization decisions, allowing admins to dynamically configure policies through the Kubernetes API.

To be able to work with RBAC on a Kubernetes cluster, the apiserver has to be started with --authorization-mode=RBAC

The create command can directly ask the API resource to create a Roles / Rolebinding in command line or create a Roles / Rolebindng object based on a yaml file definition.

Exercise n°1

Create a Role in the default namespace to grant read access to pods.

kubectl create role pods-reader --verb=get,list,watch --resource=pods

Exercise n°2

Create a ClusterRole to grant read access to secrets in any particular namespace.

kubectl create clusterrole secrets-reader --verb=get,list,watch --resource=secrets

Exercise n°3

Create a RoleBinding to grant the "pod-reader" role to a user "jane" within the default namespace.

kubectl create rolebinding read-pods --user=jane --role=pods-reader

Exercise n°4

Create a RoleBinding to allow any user in the group "manager" to read secrets in any namespace.

kubectl create clusterrolebinding read-secrets --group=manager --clusterrole=secrets-reader

Get

The get command list the object asked. It could be a single object or a list of multiple objects comma separated. This command is useful to get the status of each object. The output can be formatted to only display some information based on some json search or external tools like tr, sort, uniq.

Roles

The default output display some useful information about each services :

  • Name : the name of the newly created resource

  • Age : the age since his creation

Exercise n°1

List the existing Roles and Rolebinding in the default namespace.

# List the roles
kubectl get roles

# List the rolebinding
kubectl get rolebinding

Exercise n°2

List the existing ClusterRoles and ClusterRolebinding.

# List the cluster roles
kubectl get clusterroles

# List the cluster roles binding
kubectl get clusterrolebinding

Describe

Once an object is running, it is inevitably a need to debug problems or check the configuration deployed.

The describe command display a lot of configuration information about the Roles (labels, annotations, etc.) and the binding policy (resources associated, resources name, verbs ...)

This command is really useful to introspect and debug an object deployed in a cluster.

Exercise n°1

Describe the roles pod-reader previously created and his binding read-pods.

# Describe a role
kubectl describe role

# Describe the rolebinding associated
kubectl describe rolebinding

Exercise n°2

Describe the roles secrets-reader previously created and his binding read-secrets.

# Describe a clusterrole
kubectl describe clusterrole secrets-reader

# Describe the clusterrolebinding associated
kubectl describe clusterrolebinding reader-secrets

Explain

Kubernetes come with a lot of documentation about his objects and the available options in each one. Those information can be fin easily in command line or in the official Kubernetes documentation.

The explain command allows to directly ask the API resource via the command line tools to display information about each Kubernetes objects and their architecture.

Exercise n°1

Get the documentation of a specific field of a role resource.

kubectl explain roles

Add the --recursive flag to display all of the fields at once without descriptions.

Exercise n°2

Get the documentation of a specific field of a rolebinding resource.

kubectl explain rolebinding

Delete

The delete command delete resources by filenames, stdin, resources and names, or by resources and label selector.

A role can be deleted only if it is not used by a running Kubernetes resource.

Note that the delete command does NOT do resource version checks, so if someone submits an update to a resource right when you submit a delete, their update will be lost along with the rest of the resource.

Exercise n°1

Delete the previous role in command line.

# Delete a rolebinding
kubectl delete rolebinding read-pods
kubectl delete clusterrolebinding read-secrets

# Delete a role
kubectl delete roles pod-reader
kubectl delete clusterroles secret-reader

Module exercise

The purpose of this section is to manage each steps of the lifecycle of an application to better understand each concepts of the Kubernetes course.

The main objective in this module is to understand how to secure the internal access to respect the least privileges principles.

For more information about the application used all along the course, please refer to the Exercise App > Voting App link in the left panel.

Based on the principles explain in this module, try by your own to handle this steps. The development of a yaml file is recommended.

The file developed has to be stored in this directory : ~/data/votingapp/15_roles

  1. Create a votingapp called vote in the namespace voting-app to limit his access to :

    1. Get, list, watch Secrets

    2. Get, list, watch ConfigMaps

    3. Get, list, watch PersistentVolumes and PersistentVolumeClaims

  2. Bind the role votingapp to the service account vote and result

External documentation

Those documentations can help you to go further in this topic :

PreviousService AccountsNextMinikube

Last updated