ServiceAccounts, Roles and RoleBindings

Configuration and Security / Guide 29 of 44 / Intermediate

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 16 min

The token in a Pod is a projected, time-bound token - expirationSeconds reads 3607 here, so it is rotated roughly hourly by the kubelet. Kubernetes no longer creates a permanent Secret per ServiceAccount, which is why kubectl get secrets in a namespace with ServiceAccounts is usually empty.

This guide includes

Use this when a Pod needs to talk to the API and should be able to do nothing else. This matters because every Pod already runs as a ServiceAccount whether you chose one or not, and by default it can do almost nothing - which is the right place to start from.

• creating a ServiceAccount and confirming what it cannot do yet
• granting exactly one permission with a Role and a RoleBinding, imperatively
• proving it from inside a Pod using the projected, time-bound token
• turning the token off entirely with automountServiceAccountToken: false

Before you start

• A cluster and kubectl, with permission to create Roles and RoleBindings.
• The session creates namespace ckad-sa, a ServiceAccount reader, a Role limited to reading Pods, a RoleBinding, and two Pods - one using the token and one with it turned off.

1. 1

   A ServiceAccount, and what it cannot do

2. 2

   One Role, one RoleBinding

3. 3

   Proving it from inside a Pod

4. 4

   Turning the token off

Official sources

• Using RBAC Authorization
• Configure Service Accounts for Pods
• Accessing the API from a Pod