gatekeeper/gatekeeper

What this page gives you

Every chart page follows the same order. Choose a configuration, inspect its objects and setup work, then read the tests that have run. Open the worked examples.

What To Use

default configuration: 30 rendered objects · 1 image · 0 target prerequisites · 2 hook or setup routes · 7/7 checks passing. These counts come from the linked test records.

The recipe/package proof exists and useful variants exist, but this chart has not been promoted into the public catalog.

Four Separate Questions

Inspecting a source, producing objects, checking a destination, and checking a live result are different jobs. A Catalog match is useful for comparison but is not required. A missing destination or deployment is shown as not run or blocked, not as a failed configuration.

Open the complete assessment, source, lifecycle, and evidence record.

Where This Chart's Settings Come From

Upgrade rule: if a new Helm render and a ConfigHub revision both change the same field, review the overlap before promotion. The values profile shows the Helm side; Unit revision history shows the ConfigHub side.

Read the full values-versus-ConfigHub rule. For the staging commands behind each prerequisite, open the prerequisite action packets.

What This Chart Contains

Shipping a chart as plain rendered YAML is faster and simpler, and it silently drops anything Helm was going to do afterwards. This section reports what a scan of the packaged chart found, across 40 files.

A flattening-safety verdict has decided this version: default:flatten-with-routes; no-crds:unsafe-to-flatten. The verdict records one disposition per construct and names any companion artifact a flattened bundle must ship.

A construct being present does not make a chart unflattenable. Most are switched on or off by values, and a verdict records which ones the base you choose actually reaches. Read the catalog-wide evidence for how common each one is.

What The Starting Configuration Records

A base variant is a starting configuration we have already rendered and checked. Pick the one whose trade-off you want; the table below shows what each one changes. How the values for each are chosen.

The default base-variant record connects those Helm inputs to the Kubernetes objects, remaining requirements, hooks, CRDs, checks, and OCI status. Open it when you need the complete starting record rather than only the rendered YAML.

Open the full rendered YAML to read the actual manifest output. The render record and setup section explain the inputs, tests, CRDs, hooks, and other work around it.

If new Helm values create a useful starting configuration, record another base variant with its own inputs and checks. If one environment changes a field after rendering, record that change in a ConfigHub variant.

How render intents work · All generated render intents · All base variant records

Try This Chart

Review default before use. If a card says review or preparation is needed, treat that as a real limit rather than a ready install.

cub installer inspect oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/gatekeeper-gatekeeper:3.22.2@sha256:ce4877c260225419e22d820f9d15652ad48ed5f205117099e88abb3f590241a5 --json

cub installer pull 'oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/gatekeeper-gatekeeper:3.22.2@sha256:ce4877c260225419e22d820f9d15652ad48ed5f205117099e88abb3f590241a5' --work-dir ./package-review
less ./package-review/package/records/README.md

cosign verify --certificate-identity helm-expt-package-signer@nth-fort-499605-q5.iam.gserviceaccount.com --certificate-oidc-issuer https://accounts.google.com --annotations confighub.com/package-path=packages/gatekeeper/gatekeeper/3.22.2 --annotations confighub.com/package-sha256=a3e59845419c6c3e2fcb857c1370df675ad88c10cdf5b03b1839c435e3026756 europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/gatekeeper-gatekeeper:3.22.2@sha256:ce4877c260225419e22d820f9d15652ad48ed5f205117099e88abb3f590241a5

cub installer setup ...
rendered manifests written under <work-dir>
use the chart option cards below to check pass, watch, blocked, and prerequisites

After You Render It

The first command writes files and does not apply them. Read the objects and setup requirements, then choose the next job.

Available Configurations

Each card is one available way to use this chart in the catalog. Some cards are runnable base variants. Others are candidate paths, derived variants, or review notes that explain what still has to be prepared.

Checks: Each card names what was checked and says whether it passed, needs review, was blocked, was not run, or was not needed.

3 matrix rows for gatekeeper/gatekeeper@3.22.2 · open the full matrix

Local Configuration Checks

We ran cub check v0.7.3 against the exact rendered objects for every configuration below. The result is advisory: read each finding and decide whether it matters for your target.

What this does not check: hook execution, CRD readiness, target Secrets and cloud services, admission behavior, workload health, or rollback. The linked Catalog review covers chart-specific source and operating questions. ConfigHub validation and approval are separate managed controls.

Read all shared check results and the mapping to Catalog rules.

Images This Chart Pulls

Every reference below comes from the reviewed rendered output. What you see is what the cluster pulls. These references are data: you can change a registry or pin a digest with a recorded edit, and prove the change landed in every environment.

First-Run Caveats

Some chart paths need a small preparation step before the cub path feels as smooth as Helm. We show those steps here so the first run does not surprise you.

Open the all-chart adoption caveats · Helm to cub migration · cub deployment path

Advice And Current Status

Use this section to see which chart-specific guides apply, what you must provide, and what work remains.

The source data lives in chart skills and chart evidence router.

What Has Been Tested

Choose the question you care about. Not checked means this catalog has no version-specific result; it is not a pass.

How much is proven, and what more testing would add: Fully proven: Render parity, ConfigHub proof, Local live, GitOps/OCI live, Live Helm-vs-ConfigHub, Two-cluster kind.

What You Must Provide

exact rendered objects with render parity and receipts; CRD handling split into explicit bases; hooks classified and routed (not silently executed); optional chart inputs handled by reviewed base configurations

Hooks, CRDs, And Setup Work

Some Helm charts need work before, during, or after apply: CRDs, hooks, setup jobs, webhook certificates, migrations, generated Secrets, or checks. For each chart, the catalog should make the choice clear: include it in the base variant, split it into a separate base variant, run a setup step, use a GitOps action where evidence exists, require an existing target resource, or block it when there is no safe default.

What each base needs before apply

These requirements come from the same base definition as the rendered objects. The render intent keeps the chart inputs, required Secrets or CRDs, lifecycle routes, and evidence together.

If no route is shown, that does not prove the upstream chart has no hooks. It means the public catalog has no chart-specific action to show yet; check the matrix or send a problem chart if hook behavior should be modeled. Direct apply, Argo CD, Flux, and upgrade implementations are tracked separately. One passing implementation does not prove the others.

default

Evidence: data/hook-lifecycle/receipts/gatekeeper-gatekeeper/default/latest.yaml
data/hook-lifecycle/top100-hooks.csv
recipes/gatekeeper/gatekeeper/3.22.2/helm-pain-report.yaml
runs/hook-lifecycle/gatekeeper-gatekeeper/default/latest/receipt.yaml

no-crds: package applies 17 CRDs first

Before Production

A green render or local live result is not a production support claim. Production support is target-scoped and uses the support-decision artifact when present.

Source And Evidence Files