CONSTELLATION PRODUCT / ADMISSION & SUPPLY CHAIN

Stop risky workloads at the door.

A validating admission webhook checks pods and every controller that creates them before they reach the cluster. Default rules reject the most dangerous settings. Profiles, simulation and scan-backed gates let you tighten it from there.

Alpha · Webhook on by default, fails open · Database-backed policies optional

01 / DEFAULTS

Three rules that block on day one.#

Out of the box the webhook rejects privileged containers, host networking and the host PID namespace. Two more rules, image signature and read-only root filesystem, run in monitor mode: the pod is admitted and kubectl shows a warning.

Checks pods, Deployments, StatefulSets, DaemonSets, ReplicaSets, Jobs, CronJobs, ReplicationControllers and PVCs on create and update
Pod templates inside controllers are checked, so a privileged Deployment is caught before its pods exist
Allow rules carve out exceptions before deny rules run

The webhook’s failure policy is Ignore by default: if it is down, pods are admitted. It skips its own namespace, but not kube-system; set a namespace selector for system namespaces your platform needs.

02 / RULES & PROFILES

Start from a profile. Adjust the rules.#

Each rule is in monitor or enforce mode and can be scoped by namespace, namespace label or Constellation group. Profiles bundle rules for a purpose and can be exported and imported.

CONDITIONS

What rules can check

Host IPC, privilege escalation, running as root, image registry allowlists, latest or untagged images, digests, resource limits, secrets in environment variables, PVC storage classes and service accounts bound to risky roles.

PROFILES

Ten built in

Pod Security Standards baseline and restricted, basic and strict hardening, image provenance, critical and fixable vulnerabilities, secrets and misconfiguration, privileged-workload approval and admission exceptions.

ENGINES

Rego and CEL too

Write rules in OPA Rego or Kubernetes CEL alongside the built-in conditions.

Turn on database-backed policies to use them

Profiles, custom rules, Rego and CEL reach the live webhook only when admission.policies.enabled is set with the cluster’s ID. It is off by default, so a default install runs the built-in rules. The console’s cluster-wide monitor/protect switch does not yet change the live webhook.

03 / SIMULATE

Know the answer before you deploy.#

Paste a manifest, or pick a resource already in the cluster, and see which rules would match and why. Simulation writes no decisions, changes nothing in the cluster and redacts secret values in its response. Dry runs are kept in a history you can review.

Audit the denials

Optionally, the webhook writes every enforce denial and monitor match to the hash-chained audit log with the rule, reason, namespace, pod, operation and user. Off by default (admission.audit.enabled).

Policy as code

Admission rules, response rules, groups and network rules have Kubernetes custom resources. They are reconciled only when the operator is given a database connection, which the chart does not do by default.

04 / SCAN-BACKED GATES

Admit on evidence, not just on spec.#

Evidence gates read the stored scan for an image before admitting it: vulnerability counts and CVEs, whether a fix exists, how old the scan is, the image digest, secrets and file risks found, and trusted signatures and attestations.

Evidence gates need database-backed policies. Some built-in vulnerability profiles still expect scan provenance the current scanner does not record; test any profile with simulation and monitor mode before enforcing it.

values.yaml / admission

admission:
  webhook:
    failurePolicy: Ignore      # default: fail open
    namespaceSelector:
      matchExpressions:
        - key: kubernetes.io/metadata.name
          operator: NotIn
          values: [kube-system]
  policies:
    enabled: true              # off by default
    clusterId: <cluster-uuid>
  audit:
    enabled: true              # off by default

05 / SIGNATURES

Check who built it.#

The scanner verifies image signatures with cosign on every scan, keyless by default or against your public key, with optional transparency-log checks and required attestation types. Private Sigstore roots of trust, including your own Fulcio, Rekor and TUF, are supported for restricted networks.

Trust policies set which signatures and attestations are required and where. Repository and CI attestations on digest-pinned images have their own trust policies.

No image is trusted until you configure identities and issuers. The built-in signature admission rule is monitor-only; enforce signatures through the image-provenance profile with database-backed policies.

Trust policies: Which signatures and attestations are required, where each policy applies and whether pending attestations verify automatically. — Which signatures and attestations are required, where each policy applies and whether pending attestations verify automatically.

FAQ

Admission questions.#

Does the webhook change our manifests?

No. It is a validating webhook only. It admits, warns or rejects; it never mutates. #

Will it block our system components?

It can. Anything privileged, host-networked or host-PID outside Constellation’s own namespace is rejected by default, including in kube-system. Add a namespace selector for the system namespaces you trust before enforcing. Installs from the Astronomer catalog come with one for Astronomer’s supported tools. #

Is this a replacement for Pod Security Admission?

It is not a substitute for the Kubernetes Pod Security Standards. It includes baseline and restricted profiles modeled on them, alongside rules PSA does not cover, such as scan results and signatures. #

NEXT STEP

Simulate your manifests against the defaults.

Bring a few real workloads. AlphaBravo will walk through what the webhook would do with them.

Contact AlphaBravo Early access