Trace Kubernetes control-plane access

System and boundaries

The Kubernetes API server is the control-plane entry point for desired cluster state. Clients include people, controllers, kubelets, Pods, automation, and external systems. Each request crosses transport authentication, request authentication, authorization, and admission before a write reaches storage.

Authentication maps presented credentials to a user name, groups, and extra attributes. Kubernetes does not manage normal human user objects. ServiceAccounts are Kubernetes-managed workload identities. Impersonation can replace request identity only when the original caller has explicit impersonation permission.

Authorization decides whether the authenticated request attributes can perform an API verb on a resource or non-resource URL. Admission runs after authorization for applicable create, update, delete, or connect operations and can validate or mutate object content.

Request and decision flow

1. The client connects to an authenticated API-server endpoint.
2. An enabled authenticator validates the credential. Failed authenticators can leave a request anonymous when anonymous access is enabled.
3. The API server forms the request identity and attributes: user, groups, extra values, verb, API group, resource, subresource, namespace, name, or non-resource path.
4. Configured authorizers evaluate those attributes. RBAC, Node, and webhook authorizers can participate. A request with no allow result is denied.
5. For an applicable operation, mutating admission runs, the object schema is validated, and validating admission runs. Admission can inspect fields that normal authorization does not use.
6. The API server applies the operation to storage or handles the subresource.
7. Audit policy records selected stages and request context. Controllers can cause later actions under their own identities.

An authorization allow for create pods does not mean every Pod specification is safe. Admission can restrict privilege, host access, images, identities, and other object fields. Admission does not replace the need to restrict who can create the object.

Failure domains

• The API endpoint is public or directly reachable around the approved access gateway.
• Anonymous authentication exposes an unintended non-resource or discovery path.
• A static, copied, or long-lived credential remains usable after the owner changes.
• Group mapping grants a broad binding to the wrong external identity.
• A caller can impersonate, bind, or escalate into greater authority.
• Pod creation or workload update becomes indirect node, Secret, or ServiceAccount access.
• An admission webhook fails open, has an excessive timeout, or is bypassed for an uncovered resource.
• A webhook authorizer or admission service receives sensitive data without a protected channel.
• Audit policy omits request stages or records credentials and Secret data.

Test the effective API server, not only manifests. Include aggregated APIs, subresources such as exec and portforward, controller-created objects, and emergency credentials.

Design tradeoffs and residual risk

An identity-aware access gateway can centralize human authentication and hide the public API endpoint. Kubernetes still authorizes API actions. Short-lived credentials reduce stale access and increase dependency on issuers. Admission adds object-aware controls and can block cluster operations when its dependencies fail.

Cluster-admin access simplifies recovery and creates a total control-plane compromise path. Break-glass credentials need offline custody, narrow use, strong evidence, and tested revocation. API audit supports reconstruction but cannot prove node-level actions outside observed APIs.

Residual risk includes compromised controllers, node credentials, etcd access, admission gaps, external identity drift, and direct control-plane paths.

Pomerium boundary

Pomerium can protect Kubernetes API access and integrate authenticated users with the documented cluster access flow. Kubernetes owns API authentication interpretation, authorization, admission, persistence, and audit. Operators must restrict direct API reachability and ensure user mapping, impersonation, RBAC, and admission match the intended model.

Exercise

Trace one kubectl apply request and one Pod exec request. Record the transport endpoint, original identity, any impersonated identity, groups, API attributes, authorizer result, admission checks, stored change or connection, audit stages, and controller follow-on actions.

Run negative tests for anonymous access, wrong group, expired credential, cross-namespace action, secret read, Pod exec, role bind, role escalate, privileged Pod, admission outage, and direct API endpoint. Each denial must have an identifiable owner and evidence source.

Evaluation checklist

• Can the team trace transport, authentication, authorization, admission, storage, and audit in order?
• Are original and impersonated identities both visible and authorized?
• Do RBAC and admission each enforce the decisions only they can see?
• Are API endpoints, subresources, aggregated APIs, and controller actions in scope?
• Can direct, anonymous, stale, escalation, and admission-failure paths fail safely?