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.
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
List of roles created in command line.
NAME AGE
pods-reader 8m
List of roles binding created in command line.
NAME AGE
read-pods 10m
Exercise n°2
List the existing ClusterRoles and ClusterRolebinding.
# List the cluster roles
kubectl get clusterroles
# List the cluster roles binding
kubectl get clusterrolebinding
List all the cluster roles created by default and in command line.
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
Describe the roles previously created in command line.
Describe the cluster roles binding previously created in command line.
Name: read-secrets
Labels: <none>
Annotations: <none>
Role:
Kind: ClusterRole
Name: secret-reader
Subjects:
Kind Name Namespace
---- ---- ---------
Group manager
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
KIND: Role
VERSION: rbac.authorization.k8s.io/v1
DESCRIPTION:
Role is a namespaced, logical grouping of PolicyRules that can be
referenced as a unit by a RoleBinding.
FIELDS:
apiVersion <string>
APIVersion defines the versioned schema of this representation of an
object. Servers should convert recognized schemas to the latest internal
value, and may reject unrecognized values. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#resources
kind <string>
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds
metadata <Object>
Standard object's metadata.
rules <[]Object> -required-
Rules holds all the PolicyRules for this Role
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
KIND: RoleBinding
VERSION: rbac.authorization.k8s.io/v1
DESCRIPTION:
RoleBinding references a role, but does not contain it. It can reference a
Role in the same namespace or a ClusterRole in the global namespace. It
adds who information via Subjects and namespace information by which
namespace it exists in. RoleBindings in a given namespace only have effect
in that namespace.
FIELDS:
apiVersion <string>
APIVersion defines the versioned schema of this representation of an
object. Servers should convert recognized schemas to the latest internal
value, and may reject unrecognized values. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#resources
kind <string>
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds
metadata <Object>
Standard object's metadata.
roleRef <Object> -required-
RoleRef can reference a Role in the current namespace or a ClusterRole in
the global namespace. If the RoleRef cannot be resolved, the Authorizer
must return an error.
subjects <[]Object>
Subjects holds references to the objects the role applies to.
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
Create a votingapp called vote in the namespace voting-app to limit his access to :
Get, list, watch Secrets
Get, list, watch ConfigMaps
Get, list, watch PersistentVolumes and PersistentVolumeClaims
Bind the role votingapp to the service account vote and result
Create the votingapp role based on the prerequisites.
kubectl create role votingapp --verb=get,list,watch --resource=secrets,configmaps,persistentvolume,persistentvolumeclaim -n voting-app
Bind the votingapp role to the vote and result service accounts.
