Skip to content

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
  1. The client’s request is authenticated
  2. If the authentication was successful, the credentials are taken as one input of the authorization module
  3. The second input is a vector containing the request path, resource, verb, and namespace
  4. 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:
  • 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
    
Back to top