Stage 5 · Platform
Kubernetes Architecture Deep Dive
Authentication & Authorization
Users, service accounts, RBAC, ABAC, and admission control.
Authentication Overview
Kubernetes authentication identifies who is making an API request. It does not determine what they can do — that is authorization. Authentication is performed by the API server using plugins: X.509 client certs, bearer tokens, OIDC, webhook, or proxy. Multiple methods can be configured simultaneously.
# See who you are authenticated as
kubectl auth whoami
# Output shows username, groups, and auth method
# Example output:
# deprecation-warning: ...
# username: admin@example.com
# groups: ["system:masters", "system:authenticated"]The whoami command shows your authenticated identity. system:masters is a special group that bypasses all RBAC checks — never grant it to service accounts or non-admin users.
Service Accounts
Service accounts are per-namespace identities for workloads. By default, every pod is assigned the default service account. Production workloads should use dedicated service accounts with minimal permissions. The token is projected into the pod at /var/run/secrets/kubernetes.io/serviceaccount/.
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-reader
namespace: production
automountServiceAccountToken: false # Disable auto-mount if not needed
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: configmap-reader
namespace: production
rules:
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "list"]
resourceNames: ["app-config"] # Restrict to specific resource
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-reader-binding
namespace: production
subjects:
- kind: ServiceAccount
name: app-reader
namespace: production
roleRef:
kind: Role
name: configmap-reader
apiGroup: rbac.authorization.k8s.ioThis SA can only read a single ConfigMap. automountServiceAccountToken=false prevents the token from being mounted if the pod doesn't need Kubernetes API access. Always use resourceNames to restrict to specific objects.
The default service account is auto-mounted with no permissions by default, but if you grant it permissions, every pod in the namespace gets them. Always create dedicated service accounts for workloads that need API access.
RBAC Deep Dive
RBAC (Role-Based Access Control) maps subjects (users, groups, service accounts) to permissions (roles) via bindings. Roles are namespace-scoped; ClusterRoles are cluster-scoped. Aggregated ClusterRoles let you compose roles from multiple sources.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring-endpoints
labels:
rbac.example.com/aggregate-to-monitoring: "true"
rules:
- apiGroups: [""]
resources: ["services", "endpoints", "pods"]
verbs: ["get", "list", "watch"]
---
# Additional rules for a specific CRD
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring-servicemonitors
labels:
rbac.example.com/aggregate-to-monitoring: "true"
rules:
- apiGroups: ["monitoring.coreos.com"]
resources: ["servicemonitors", "podmonitors"]
verbs: ["get", "list", "watch"]The label rbac.example.com/aggregate-to-monitoring: "true" tells Kubernetes to merge this role into any ClusterRole with the same label. This lets you add CRD permissions to monitoring roles without modifying the original role.
ABAC Mode
ABAC (Attribute-Based Access Control) is a legacy authorization mode. It maps user attributes (username, groups, namespace) directly to permissions in a JSON policy file. It is not recommended for new clusters because RBAC provides better maintainability and auditability.
{
"kind": "Policy",
"spec": {
"user": "dev-team",
"namespace": "staging",
"resource": "pods",
"readonly": true
}
}
{
"kind": "Policy",
"spec": {
"group": "system:serviceaccounts",
"namespace": "production",
"resource": "secrets",
"readonly": true
}
}ABAC policies are loaded from a file specified by --authorization-policy-file. Changes require restarting the API server. RBAC allows dynamic changes without restart.
Webhook Authorization
Webhook authorization delegates authorization decisions to an external service. The API server sends a SubjectAccessReview to the webhook, which returns allowed/denied. This is useful for implementing custom authorization logic that RBAC cannot express.
apiVersion: v1
kind: Config
clusters:
- name: authz-webhook
cluster:
certificate-authority: /etc/kubernetes/pki/webhook-ca.crt
server: https://authz-webhook.example.com/authorize
users:
- name: kube-apiserver
user:
client-certificate: /etc/kubernetes/pki/apiserver-webhook-client.crt
client-key: /etc/kubernetes/pki/apiserver-webhook-client.key
current-context: webhook
contexts:
- context:
cluster: authz-webhook
user: kube-apiserver
name: webhookThe webhook receives SubjectAccessReview requests with the user, groups, verb, resource, and namespace. It must respond quickly (< 3 seconds) or the request times out.
Security Best Practices
- Use OIDC for user authentication instead of static tokens or certs
- Never grant system:masters to service accounts or non-admin users
- Use resourceNames in RBAC to restrict to specific objects
- Enable audit logging to track who accessed what and when
- Review RBAC bindings regularly with kubectl auth can-i --list
- Use automountServiceAccountToken: false when pods don't need API access
Run kubectl auth can-i --list --as=system:serviceaccount:namespace:name to see all permissions for a service account. Use this to verify least-privilege before deploying workloads.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.