Memory hook: Authentication identifies; RBAC permits; admission validates.
Must remember
Authentication establishes the caller; authorization such as RBAC decides whether it may perform the API operation; admission may mutate or reject an otherwise authorized request. A valid token therefore does not guarantee the Pod will be admitted. Inspect the rejection message, namespace policies and requested fields.
A ServiceAccount is a namespaced workload identity. Use a dedicated account with only necessary grants, and disable automatic token mounting when the workload does not need API access. Modern projected tokens can be short-lived and audience-bound. A Secret containing base64 text is not encrypted merely because of that encoding; access and at-rest protection remain essential.
Check spec.serviceAccountName on the actual Pod before diagnosing its permissions. To test an allowed operation, an authorized administrator can use kubectl auth can-i get configmaps --as=system:serviceaccount:team:app -n team; repeat with a forbidden operation and expect no. RoleBindings grant access in their own namespace, while the ServiceAccount subject also carries its namespace. A grant in the wrong namespace cannot be repaired by changing only the token.
Security contexts control supported user/group IDs, privilege escalation, capabilities, read-only root filesystems and seccomp settings. Running as non-root is useful but not equivalent to isolation from every host risk. Namespace quotas limit aggregate usage; LimitRanges can default/restrict per-object resources. Requests drive scheduling and CPU utilization scaling calculations; limits constrain resource use.
CRDs add API resource types; an operator/controller supplies reconciliation behavior. Creating the CRD alone does not create all promised business behavior. Use kubectl api-resources and kubectl explain to discover supported fields. Deprecated API versions may later be removed; migrate manifests to served versions and check changed schemas/defaults before upgrading.
Drill: distinguish Forbidden from an admission-policy rejection and a Pending scheduling event. They occur at different layers and need different corrections; granting cluster-admin to fix all three is both ineffective and excessive.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Forbidden on an API operation | Inspect the actual identity and RBAC verb/resource/scope. |
| Pod rejected despite RBAC permission | Inspect admission/security policy and quota. |
| Old manifest API no longer served | Migrate to supported version/schema and validate behavior. |
Traps
- ServiceAccount scope and RoleBinding namespace matter.
- An operator needs controller logic, not only a custom resource definition.
Active recall
1. What happens after authorization?
Admission can validate/mutate supported requests before persistence.
2. Why disable unused token mounting?
To reduce credentials exposed inside the container.
3. Does base64 encrypt a Secret?
No.
4. What does kubectl explain help with?
Discovering API fields and schema for supported resources.
5. Why can a permitted Pod still fail?
Admission, quota, scheduling, image, runtime and application layers have separate conditions.