Memory hook: Authenticate who, authorize what, protect the secret, record the request.
Must remember
Authentication identifies the caller. Kubernetes can use supported client certificates, bearer tokens and integrations such as an OIDC identity provider. Normal human users are typically managed outside the Kubernetes API; ServiceAccounts are Kubernetes objects providing workload identities. A token is a credential, not a grant of unlimited permissions.
Prefer short-lived, audience-bound projected service-account tokens over manually issued long-lived token Secrets. Disable automatic token mounting where a workload does not need API access. Give each application an appropriate identity instead of sharing a privileged ServiceAccount. Cloud workload identity integrations can exchange trusted workload identity for scoped cloud access; Kubernetes RBAC and cloud IAM remain separate permission systems.
Authorization decides whether the identity can perform the requested operation. With RBAC, permissions are additive allow rules: verbs such as get/list/watch/create on resources and API groups. A Role defines namespaced permissions; a binding grants them to subjects. A ClusterRole can describe namespaced or cluster-scoped permissions. A RoleBinding can bind a ClusterRole's applicable permissions within one namespace; a ClusterRoleBinding grants its permissions across the cluster. There is no RBAC deny rule that overrides an existing allow grant.
Avoid wildcard resources/verbs and routine cluster-admin access. Permission to create Pods may indirectly expose Secrets or powerful ServiceAccounts available to those Pods. Permission to bind roles, escalate privileges or impersonate identities also deserves special review. kubectl auth can-i get secrets -n team-a checks a particular permission for the selected identity; it does not prove there is no indirect escalation path.
Secrets separate sensitive values from ordinary configuration, but base64 is encoding, not encryption. Kubernetes does not automatically guarantee encrypted etcd storage; configure and verify encryption at rest. Restrict Secret API access and which containers receive each secret. List/watch can expose Secret contents, not just names. Avoid secrets in images, Git, command history, crash reports and application logs. Rotate a leaked value and update consumers; deleting its Kubernetes object does not revoke credentials issued by another system.
Audit logging records API activity according to a policy. Levels are None, Metadata, Request and RequestResponse. Metadata captures who, action, target and timing without request/response bodies; body logging can expose sensitive content. Audit stages describe request progress, including receipt and completion. Protect log access, forward evidence beyond the workload's control and choose retention appropriate to the investigation requirements. Application logs and API audit logs answer different questions.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Give a support user read access in one namespace | Use a narrowly scoped Role/RoleBinding or a suitable ClusterRole referenced by a RoleBinding. |
| A Pod never calls the API | Avoid mounting an API token and avoid unnecessary RBAC grants. |
| Investigate who changed a RoleBinding | Use protected API audit records; ordinary application stdout is insufficient. |
| A database password leaked in Git | Revoke/rotate it at the database and update consumers; removing the commit or Secret is insufficient. |
Traps
- A valid credential can still lack permission; TLS, authentication and authorization are distinct checks.
- Base64 and encrypted network transport do not establish encryption at rest.
- Preventing direct get Secret access may be insufficient if the same identity can create Pods that mount it.
- Audit RequestResponse is not automatically the safest level because it can retain sensitive bodies.
Active recall
1. Can a RoleBinding reference a ClusterRole without granting cluster-wide access?
Yes. It grants applicable permissions within the binding namespace.
2. Two RBAC bindings grant different permissions. Which wins?
Their allowed permissions are combined. RBAC rules are additive; there is no ordinary explicit deny rule.
3. Does disabling token automount remove every possible credential from a Pod?
No. It prevents that automatic API-token mount, but explicit mounts, environment values or external identity mechanisms may still provide credentials.
4. Which audit level records caller and target while avoiding request/response bodies?
Metadata. The audit policy must still be reviewed for coverage and sensitive metadata.
5. A Secret was deleted after its value leaked. Is the external credential revoked?
Not necessarily. Revoke or rotate the value in the system that validates it and update legitimate consumers.