liveBook · Manning

Admission controller

As explained in Google Anthos in Action

An admission controller is a Kubernetes component that intercepts API requests after authentication and authorization and can validate or mutate them before persistence.

An admission controller checks a Kubernetes API request before the requested object is created or updated. It can validate or mutate the request, then allow or deny it. This makes admission control useful for rules that permissions alone cannot express, such as requiring a label on every namespace or restricting how Pods are configured. section 13.4.1 section 11.2.3

ACM Policy Controller uses Gatekeeper for this role. Enabling it creates a ValidatingWebhook configuration that registers the policy engine with the API server. For a Pod creation request, the API server calls the Gatekeeper service; a Gatekeeper Pod evaluates the configured policies and returns its decision. A denial prevents creation and supplies an error to the API server. section 13.4.1

Gatekeeper policies pair a constraint template, which defines a test in Rego, with a constraint that supplies its arguments and selects where it applies. For example, a constraint can require a billing label on namespaces or deny privileged containers in Pods. ACM can also use ClusterSelectors to apply different constraints to different clusters. section 11.2.3 section 13.4.1

Test a Pod restriction before enforcing it

A K8sPSPPrivilegedContainer constraint can match Pods with `enforcementAction: dryrun`. Reported violations identify affected Pods, including system workloads, before the restriction is enforced. Review those results and plan exemptions rather than assuming every existing Pod satisfies a new policy. section 13.4.1

Table 13.2 Namespace exemption options (view table figure)

Process option

Results of exemption

Audit

Namespace(s) will not report audit results but will still be part of the webhook and sync processes.

Webhook

Namespace(s) will be exempt from the admission controller but will still be part of the audit and sync processes.

Sync

Namespace(s) resources will not be reported into Gatekeeper but will still be part of the audit and webhook processes.

*

Exempts the namespace(s) from all Gatekeeper processes.

Namespace exemptions have different scopes: a webhook exemption bypasses admission checks but retains audit and sync; `*` exempts the namespace from all Gatekeeper processes. section 13.4.1

Treat the controller as part of the deployment path. A malfunction can obstruct deployment requests across a cluster, while an expensive custom policy can add latency. Gatekeeper is available as an open source deployment, but operating and supporting it remains the organization's responsibility; ACM provides a supported deployment option. section 13.3 section 13.4.1

How Google Anthos in Action covers it

How deep it goes
Explains webhook registration and the request-decision flow, then shows policy configuration and exemptions; defers detailed policy creation.
Examples
Uses Pod creation, privileged-container checks, required namespace billing labels, dry-run violations, and namespace exemptions.
What you can do after
Operate/configure it through ACM Policy Controller constraints, dry-run checks, and scoped Gatekeeper exemptions.
How it connects
Connects admission control to the Kubernetes API server, validating webhooks, Gatekeeper, constraint templates, constraints, and role-based access control.

Also explained in

Compare how 3 books explain admission controller →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Google Anthos in Action. The section links point to the parts of the book it draws on.