Installation Manual - 94 Gatekeeper preflight and dry-run design

Validate the Gatekeeper Operator package and dry-run the operator-only install shape before any admission-impacting Gatekeeper rollout.

This chapter records the OP-GF-OPERATORS-03 Gatekeeper preflight for the greenfield v7 clusters.

The gate was dry-run only. It did not install Gatekeeper and did not change live cluster or GitOps desired state.

Governance

Intent

After catalog hygiene, Gatekeeper became the first candidate for the next platform operator. Because Gatekeeper can affect admission, the first step was to validate the package, namespace model, install mode, source pinning, and dry-run behavior before any live install.

Access Path

Live checks used:

local workspace -> dl385-2 -> gf-ocp-bootstrap-01 -> v7 kubeconfigs

Kubeconfigs on gf-ocp-bootstrap-01:

/home/ze/ocp-greenfield-deployment/artifacts/openshift/hub-dc-v7/auth/kubeconfig
/home/ze/ocp-greenfield-deployment/artifacts/openshift/spoke-dc-v7/auth/kubeconfig

Baseline

Both clusters were healthy during preflight:

Argo applications were Synced/Healthy at:

11e76f466ddcccee78e6ea59f06c55ad775b3c25

Both clusters had default operator sources disabled:

OperatorHub/cluster.spec.disableAllDefaultSources=true

Package Findings

Gatekeeper resolved through the mirrored Red Hat catalog on both clusters:

There was no suggested namespace annotation in the package metadata.

No existing Gatekeeper namespace, Subscription, CSV, webhook, or Gatekeeper CRD was found. A broad constraints CRD search only matched the built-in OpenShift SCC CRD.

Dry-run Validation

The first full intended server-side dry-run validated the target Namespace, then failed the namespaced OLM objects because the namespace did not exist:

namespaces "openshift-gatekeeper-system" not found

That is expected behavior. A server-side dry-run Namespace is not persisted for later objects in the same manifest.

The no-change validation was split into three checks:

After dry-run validation, the target Gatekeeper objects were still absent.

Operator-only Install Shape

Use this as the first Gatekeeper GitOps install shape:

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-gatekeeper-system
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: gatekeeper-system
  namespace: openshift-gatekeeper-system
spec: {}
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: gatekeeper-operator-product
  namespace: openshift-gatekeeper-system
  annotations:
    argocd.argoproj.io/sync-wave: "10"
    operatorframework.io/bundle-unpack-timeout: 30m
spec:
  channel: stable
  installPlanApproval: Automatic
  name: gatekeeper-operator-product
  source: cs-redhat-operator-index-v4-20
  sourceNamespace: openshift-marketplace
  startingCSV: gatekeeper-operator-product.v3.21.0

The empty OperatorGroup spec: {} is intentional because the CSV supports only the AllNamespaces install mode.

Boundary

Do not include these in the first Gatekeeper install gate:

• Gatekeeper custom resource;
• validating or mutating webhook rollout;
• constraint templates;
• constraints.

Those are admission-impacting and need later rollback-tested gates after the operator CSV is healthy.

Result

Gatekeeper is suitable for the next operator gate only as an operator-only hub install first.

The next gate is:

OP-GF-OPERATORS-04: hub Gatekeeper operator-only GitOps install

That gate should install only the Namespace, OperatorGroup, and Subscription on hub-dc-v7, validate CSV success and cluster health, then stop before the Gatekeeper operand is created.