Authentication and authorization in Canonical Kubernetes¶
Canonical Kubernetes comes with a well-defined set of authentication and authorization mechanisms enabled by default. This guide provides an overview of these built-in security features, helping users understand what to expect out of the box and where to find further information for custom configuration.
Overview¶
Canonical Kubernetes leverages upstream Kubernetes security primitives for both authentication (identity verification) and authorization (determining permissions). By default, Canonical Kubernetes includes:
TLS certificates for secure communication between components
Service accounts and service account tokens for workloads
Optional integration paths for external identity providers
Role-Based Access Control (RBAC)
Admission controllers
Authentication¶
Authentication in Canonical Kubernetes ensures that users and components are who they claim to be. The following methods are included by default:
Client certificates¶
The Kubernetes API server is configured to trust specific client certificates.
Certificates are issued to admin users during cluster creation.
These can be seen by running
k8s config
on a control plane node.
Service accounts¶
Every pod in Kubernetes is automatically assigned a service account, unless specified otherwise.
Service account tokens are mounted into pods, enabling them to authenticate with the API server securely, unless specified otherwise.
A policy engine (if added) may restrict auto-mounting the default service account token into Pods if used.
These are managed in the namespace where the pod is deployed.
The Kubernetes API server can be configured to accept OpenID Connect (OIDC) tokens for authentication from external identity providers.
In Canonical Kubernetes, anonymous API access is disabled by default.
For more details, see Kubernetes Authentication upstream docs.
Authorization¶
After authentication, Kubernetes checks whether the user or service account is authorized to perform a requested action. In Canonical Kubernetes, this is done through Role-Based Access Control.
Role-Based Access Control (RBAC)¶
RBAC Authorization in Canonical Kubernetes is done through the following types of Kubernetes objects:
Roles define a set of allow permissions within a namespace.
ClusterRoles define cluster-wide allow permissions.
RoleBindings and ClusterRoleBindings assign these roles to users or service accounts.
Example use cases:
Granting users or service accounts read-only access to logs in a namespace.
Granting read-only access to nodes, services, and pods to a monitoring operator.
Kubernetes defines a set of ClusterRoles
and ClusterRoleBindings
that apply
to all users and service accounts, including the default
service accounts
mounted in pods:
system:basic-user
: Allows a user read-only access to basic information about themselves.system:discovery
: Allows read-only access to API discovery endpoints needed to discover and negotiate an API level.system:public-info-viewer
: Allows read-only access to non-sensitive information about the cluster.
For more details, see:
Admission controllers¶
After a request has been authenticated and authorized, admission controllers are used to validate and / or mutate requests to the Kubernetes API that create, modify, or delete resources in Kubernetes. Admission controllers cannot block get, list, or watch requests.
Kubernetes has a default list of admission controllers, which can be expanded or contracted. Keep in mind that several important features of Kubernetes require admission controller to be enabled in order to properly support them. As a result, a Kubernetes API server that is not properly configured with the right set of admission controllers is an incomplete server and will not support all the features you expect.
In addition to the default list of admission controllers, Canonical Kubernetes enables
the NodeRestriction
admission controller. This controller limits the Node
and Pod
objects a kubelet can modify, allowing them to modify only their
own Node
object and Pod
objects bound to their node.
For more details, see Kubernetes Admission Control upstream docs.
Extending authentication and authorization¶
For advanced authentication and authorization, users may want to configure:
OpenID Connect (OIDC) for integrating with external identity providers (e.g.: LDAP, Google, Azure AD).
Webhook token authentication for custom authentication.
Custom RBAC roles.
Pod Security Admission Controller, which can enforce the Pod Security Standards.
For further information on how to extend authentication and authorization in your cluster, see: