Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Background

  • Establish a system of users with different roles to access a set of Kubernetes resources.
  • Control processes running in a Pod and operations they can perform via the Kubernetes API.
  • Limit the visibility of certain resources per namespaces.

Overview

RBAC has three main building blocks.

SubjectThe user or process that wants to access a resource.
ResourceThe Kubernetes API resource type.
VerbThe operation that can be executed on the resource.


PlantUML Macro
@startuml

rectangle subject as "Subjects" {
    rectangle subjects [
        Users
        Groups
        ServiceAccount
    ]
}

rectangle resource as "API Resources" {
    rectangle resources [
        Pods
        ConfigMaps
        Deployments
        Services
        Ingresses
        ...
    ]
}
rectangle verb as "Operations (verbs)" {
    rectangle verbs [ 
        Create
        List
        Watch
        Delete
        ...
    ]
}

@enduml


Calls to the API server needs to be authenticated and Kubernetes offers a variety of authentication methods for those API requests.

Authentication StrategyDescription
X.509 client certificateUse an OpenSSL client certificate to authenticate.
Basic authenticationUsername and password.
Bearer tokensUse an OpenID or web-hooks as ways to authenticate.

ServiceAccount

  • Kubernetes does not store or represent users or groups with an API resources, it does not exist in its etcd database, however ServiceAccounts exists as objects in Kubernetes and are used by processes running inside the cluster.
  • Kubernetes clusters come with a ServiceAccount called default that lives in the default namespace.  Any pod that doesn't explicitly assign a ServiceAccount uses the default ServiceAccount.

Creating a ServiceAccount

MethodExample
kubectl CLI


Code Block
kubectl create serviceaccount test-bot


YAML manifest


Code Block
apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-bot


RBAC API Primitives

Kubernetes has two API resource primitives used to implement the RBAC functionality.

ResourceDescription
RoleThe Role API primitive declares the API resources and the set of allowed operations on those resources.
RoleBindingThe RoleBinding API primitive binds the Role object to the subject(s).


PlantUML Macro
@startuml

rectangle role as "Role" {
    card resource as "API Resource(s)"
    usecase verb as "Operation(s)"

    verb --> resource : get,list,watch,...
}
rectangle role_binding as "RoleBinding"


rectangle subjects [
    Users
    Groups
    ServiceAccounts
]

role_binding --> subjects : many
role_binding --> role : one

@enduml

Default Roles in Kubernetes

Default ClusterRoleDescription
cluster-adminAllows read/write access to any resources across all namespaces.
adminAllows read/write to any resources in a namespace.
editAllows read/write access to resources in a namespace except Roles and RoleBindings.  Does provide access to Secrets.
viewAllows read-only access to resource in a namespace except Roles, RoleBindings, and Secrets.

Creating Roles

MethodExample
kubectl CLI


Code Block
kubectl create role my-ro --verb=get,list,watch --resource=pods,deployments,services


YAML manifest


Code Block
apiVersion: rbac.authroization.k8s.io/v1
kind: Role
metadata:
  name: my-ro
rules:
  - apiGroups:
    - ""
    resources:
    - pods
    - services
    verbs:
    - list
    - get
    - watch
  - apiGroups:
    - apps
    resources:
    - deployments
    verbs:
    - list
    - get
    - watch

The API group name for a resource can be identified by performing kubectl explain <resource>