Authorisation

Process¶

Concept Description

Requests

Kubernetes authorizes API requests by using the API server
- evaluating the request attributes against the policies
- and subsequently allowing or denying the request
By default, permissions are denied, unless explicitly allowed by a policy

Process

The client’s request is authenticated
If the authentication was successful, the credentials are taken as one input of the authorization module
The second input is a vector containing the request path, resource, verb, and namespace
If the user/application is permitted to execute a certain action on a certain resource, the request is passed on to the admission controller. If not, the authorization module returns an HTTP 403 Forbidden client error

Modes¶

Concept	Description
Node Authorization	A special-purpose authorizer that grants permissions to kube‐ lets based on the pods they are scheduled to run
ABAC	Attribute-based access control (ABAC) An authorizer through which access rights are granted to users through policies combining attributes (user attributes, resource attributes, objects, etc.)
Webhook	HTTP callback: an HTTP POST that occurs when something happens This mode allows for integration with Kubernetes-external authorizers
RBAC	Role-based access control (RBAC)

RBAC¶

Concept	Description
Components	Subjects: Set of users and processes that want to access the Kubernetes API Resources: The set of Kubernetes API Objects available in the cluster Verbs: The set of operations that can be executed to the resources (CRUD) Role: Connects API `Resources` and `Verbs` RoleBinding: Given a `Role`, which already binds API Objects and verbs, it establishes which `Subjects` can use it
Structure	Role\ClusterRole: The actual permission It contains rules that represent a set of permissions Each rule contains resources and verbs The verb is the action that will apply on the resource Subject (User, Group or ServiceAccount): The object that will receive the permissions RoleBinding\ClusterRoleBinding: The connection between Role\ClusterRole and the subject
Actions (Verbs)	Actions on a resource that a role uses in its rules: read-only: `get, list` read-write: `create, update, patch, delete, deletecollection`
Roles	Types: Cluster-wide: Cluster roles and their respective cluster role bindings Namespace-wide: Roles and role bindings Default Roles: User-facing roles: `cluster-admin, admin` (for namespaces), `edit, view` Core components: `system:kube-controller-manager, system:node` The Kubernetes control-plane components as well as nodes have predefined roles, defining exactly the permissions the respective component needs in order to work properly Other components: Kubernetes defines roles for noncore components that are almost always used alongside the core bits For example, there's a role called `system:persistent-volume-provisioner` for enabling dynamic volume provisioning

Role¶

Description:

A role contains rules that represent a set of permissions
Permissions are purely additive (there are no "deny" rules)
Roles can be defined within a namespace with a Role, or cluster-wide with a ClusterRole
Example Role in the "default" namespace that can be used to grant read access to pods:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
    namespace: default
    name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Example:

Create a namespace coolapp

$ kubectl create namespace coolapp
    namespace "coolapp" created

Create a service account myappid in this namespace

$ kubectl --namespace=coolapp create serviceaccount myappid
    serviceaccount "myappid" created

Now that we have established an identity for our application, we can define a role podview that allows only viewing and listing pods in its namespace

$ kubectl --namespace=coolapp create role podview \
          --verb=get --verb=list                 \
          --resource=pods

$ kubectl --namespace=coolapp describe role/podview
    Name:         podview
    Labels:       <none>
    Annotations:  <none>
    PolicyRule:
      Resources  Non-Resource URLs  Resource Names  Verbs
      ---------  -----------------  --------------  -----
      pods       []                 []              [get list]

Attach the role podview to our application, represented by the service account myappid. Do this by creating a role binding (which binds a role to a human or machine user) called mypodviewer

$ kubectl --namespace=coolapp create rolebinding mypodviewer \
          --role=podreader                                   \
          --serviceaccount=coolapp:myappid
    rolebinding.rbac.authorization.k8s.io "mypodviewer" created

$ kubectl --namespace=coolapp describe rolebinding/mypodviewer
    Name:         mypodviewer
    Labels:       <none>
    Annotations:  <none>
    Role:
      Kind:  Role
      Name:  podreader
    Subjects:
      Kind            Name     Namespace
      ----            ----     ---------
      ServiceAccount  myappid  coolapp

ClusterRole¶

Description:

A ClusterRole can be used to grant the same permissions as a Role, but because they are cluster-scoped, they can also be used to grant access to:
- cluster-scoped resources (like nodes)
- non-resource endpoints (like "/healthz")
- namespaced resources (like pods) across all namespaces

Example:

Grant read access to secrets in any particular namespace, or across all namespaces:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

RoleBinding¶

Description:

A RoleBinding grants the permissions defined in a Role to a user or set of users
It holds a list of Subjects (users, groups, or service accounts), and a reference to the Role being granted
Permissions can be granted within a namespace with a RoleBinding, or cluster-wide with a ClusterRoleBinding
A RoleBinding may reference a Role in the same namespace

Example:

Grants the pod-reader role to the user jane within the default namespace
This allows jane to read pods in the default namespace
roleRef is how you will actually create the binding
- the kind will be either Role or ClusterRole
- the name will reference the name of the specific Role or ClusterRole you want

# This role binding allows "jane" to read pods in the "default" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding¶

Description:

May be used to grant permission at the cluster level and in all namespaces

Example:

Allow any user in the group "manager" to read secrets in any namespace

# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io