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