Gatekeeper separates policy logic from cluster requirements

Requiring an ownership label on a namespace is a small policy. Implementing a separate admission service every time an organization changes such a requirement is a large maintenance burden. The August 6 introduction to OPA Gatekeeper describes a reusable alternative. A template supplies policy logic and parameter definitions. Individual constraints select the objects to which that logic applies and provide its arguments.

This distinction makes the policy an API that cluster administrators can configure. The logic still needs an author, but each use of that logic need not become another program. Gatekeeper bridges Kubernetes admission requests to Open Policy Agent, which evaluates policies written in Rego. Kubernetes enforces the resulting admission decision before the requested object is persisted.

I value this use of custom resources because it gives requirements an explicit representation in the cluster. The important operational question is what data the policy actually evaluates. Gatekeeper's admission, audit and replication mechanisms answer different parts of that question, and their differences matter to what a policy can promise.

Templates define a configurable policy type

The introduction describes Gatekeeper's third generation as an integration with the OPA Constraint Framework, built using kubebuilder. Earlier versions used ConfigMap-based policies. The new arrangement uses CRDs for policies and stores audit results on constraint resources. Policy reuse therefore becomes part of the Kubernetes object model.

A ConstraintTemplate contains Rego logic and a schema for its parameters. In the article's required-label example, the template defines a K8sRequiredLabels kind. Its logic compares the labels present on the incoming object with a required set supplied through parameters. Missing labels produce a policy violation. The labels themselves are configuration supplied by each constraint using that template.

After that template is installed, this constraint follows the example in the article. It requires an hr label on Namespace objects. The example assumes the matching ConstraintTemplate already exists and has established the constraint type.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-hr
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["hr"]

Another constraint can require a finance label through the same template. Reusing the implementation does not combine these into an optional choice. The introduction says constraints are evaluated together as a logical AND. A request must satisfy all applicable constraints, so adding the finance requirement alongside the hr requirement means both apply.

The parameter schema is part of that reusable interface. It tells an administrator what information a constraint can supply, while the match block determines where it applies. This keeps policy scope separate from the logic that detects a missing label. A template author can improve the common implementation without requiring each administrator to maintain their own copy of the same Rego expression.

Matching determines where a requirement applies

The project README as updated on July 26 describes match semantics in more detail. A constraint can match kinds, namespaces and object labels. It can also use a namespace selector. Multiple top-level matchers must all be satisfied for an object to fall within the constraint's scope.

Within a kinds matcher, matching one of the listed group-and-kind entries is sufficient. That differs from the AND relationship between top-level matchers. Keeping those two rules separate matters when a requirement targets selected kinds in selected namespaces. The list of kinds broadens the eligible resource types, while an additional namespace matcher restricts the scope.

The README also says an empty matcher is inclusive. A missing restriction therefore should not be assumed to exclude resources. These details make policy configuration consequential even when the Rego implementation is correct. A well-written rule applied to an unintended set of objects still produces the wrong cluster requirement.

Namespace selectors introduce a data dependency. The README directs users to synchronize Namespace resources into OPA when that matcher is used. Evaluating a resource against attributes of its namespace needs information beyond the submitted object. This is a small example of the broader replication requirement.

Audit needs an inventory of existing objects

Admission acts on a request. Introducing a new rule does not itself produce a new request for every existing resource. Gatekeeper's audit periodically evaluates replicated resources against constraints and records violations in the corresponding constraint's status. The introduction shows existing namespaces without a required label appearing in that report.

Audit therefore supplies visibility into previously admitted state, but its input is a configured inventory. The article says resources must first be replicated into OPA. A Config object selects the resource group, version and kind to synchronize through syncOnly. Its example selects Namespace and Pod resources. The presence of an admission rule alone does not establish that every existing object is available to the audit query.

Cross-resource policies need the same machinery. The article uses uniqueness of ingress hostnames as an example, because evaluating one ingress cannot establish uniqueness without access to other ingresses. The README exposes replicated objects through data.inventory, with separate layouts for cluster-scoped and namespaced resources. A policy author can query that inventory when the requirement depends on relationships between objects.

I consider this dependency part of the policy definition. A rule that requires other objects must name an inventory that actually contains them. Otherwise its intended scope and its available evidence differ, even though the incoming admission request is valid input to the engine.

The README configures audit frequency through an interval flag, with a default of 60 seconds. Its reported violations are therefore periodic observations, which should be interpreted alongside the audit timestamp.

The current implementation has defined limits

Gatekeeper v3 supplies validating admission and audit in this introduction. Mutating admission is planned work, as are external data and dry-run support. The historical versions described by the article had different combinations of capabilities. It would be incorrect to transfer an earlier version's mutation support to the new CRD-based implementation simply because they share the Gatekeeper name.

The July README also describes template build errors appearing in status. An object being accepted by the API is therefore distinct from its policy type being successfully built. Together with the audit inventory requirement, that gives administrators concrete implementation state to inspect. The installed templates, matching constraints and synchronized resources determine the policy that Gatekeeper can evaluate for the cluster.