# Written by hand. See README.md beside this file for what a reading is and # how it is checked. Run `npm run config-model:verify` after any change. apiVersion: "evidence.confighub.com/v1alpha1" kind: "PlanStepReadings" metadata: name: "plan-step-readings" readAt: "2026-10-11" note: >- Each reading says what one base needs for one step that its flattening verdict file names, and who does it. The verdict's line comes from a sweep of the whole chart. The reading comes from the base's own retained objects and from one live run on a throwaway local cluster. spec: readings: - record: "cloudnative-pg-cloudnative-pg-0-28-2-default" step: "webhook-certificate" reading: "workload-supplies" suppliedBy: "the CloudNativePG operator" instruction: "The CloudNativePG operator makes its own certificate after it starts and fills the caBundle of both webhook configurations, so you do nothing for this step." evidence: - path: "recipes/cloudnative-pg/cloudnative-pg/0.28.2/revisions/default/r001/rendered/release-objects.yaml" object: "Deployment default/cloudnative-pg" shows: "The volume 'webhook-certificates' mounts the Secret 'cnpg-webhook-cert' with 'optional: true'. The file holds no Secret of that name, so the operator starts without it." - path: "recipes/cloudnative-pg/cloudnative-pg/0.28.2/revisions/default/r001/rendered/release-objects.yaml" object: "ClusterRole cloudnative-pg" shows: "One rule grants 'get' and 'patch' on 'mutatingwebhookconfigurations' and 'validatingwebhookconfigurations'. Another grants 'create' on 'secrets'. The operator may make the Secret and write the caBundle." - path: "recipes/cloudnative-pg/cloudnative-pg/0.28.2/revisions/default/r001/rendered/release-objects.yaml" object: "MutatingWebhookConfiguration cnpg-mutating-webhook-configuration" shows: "None of its 4 webhooks has a 'caBundle', and the object has no 'cert-manager.io' annotation." - path: "recipes/cloudnative-pg/cloudnative-pg/0.28.2/revisions/default/r001/rendered/release-objects.yaml" object: "ValidatingWebhookConfiguration cnpg-validating-webhook-configuration" shows: "None of its 5 webhooks has a 'caBundle', and the object has no 'cert-manager.io' annotation." observed: log: "docs/user/live-walk-plan-step-readings-2026-10-11.md" result: "Run 1. Straight after the apply all 9 webhooks had an empty caBundle. 13 seconds after the apply the operator had created the Secrets cnpg-ca-secret and cnpg-webhook-cert and had written a caBundle into all 9. The Deployment rolled out with 1 Pod, and a server dry-run of a Cluster passed both webhooks." - record: "elastic-eck-operator-3-4-0-default" step: "webhook-certificate" reading: "workload-supplies" suppliedBy: "the ECK operator" instruction: "The ECK operator fills the empty Secret elastic-operator-webhook-cert after it starts and writes the caBundle into the webhook configuration, so you do nothing for this step." evidence: - path: "recipes/elastic/eck-operator/3.4.0/revisions/default/r001/rendered/release-objects.yaml" object: "Secret default/elastic-operator-webhook-cert" shows: "The Secret has no data. It is a place for the operator to write its certificate." - path: "recipes/elastic/eck-operator/3.4.0/revisions/default/r001/rendered/release-objects.yaml" object: "StatefulSet default/elastic-operator" shows: "The environment variable 'WEBHOOK_SECRET' is 'elastic-operator-webhook-cert', and the volume 'cert' mounts that Secret at '/tmp/k8s-webhook-server/serving-certs'." - path: "recipes/elastic/eck-operator/3.4.0/revisions/default/r001/rendered/release-objects.yaml" object: "ConfigMap default/elastic-operator" shows: "The key 'eck.yaml' sets 'enable-webhook: true' and 'webhook-name: elastic-operator.default.k8s.elastic.co'. It does not turn off the operator's own management of the webhook certificate." - path: "recipes/elastic/eck-operator/3.4.0/revisions/default/r001/rendered/release-objects.yaml" object: "ClusterRole elastic-operator" shows: "Its rules grant 'update' and 'patch' on 'secrets' and on 'validatingwebhookconfigurations'." - path: "recipes/elastic/eck-operator/3.4.0/revisions/default/r001/rendered/release-objects.yaml" object: "ValidatingWebhookConfiguration elastic-operator.default.k8s.elastic.co" shows: "None of its 16 webhooks has a 'caBundle', and the object has no 'cert-manager.io' annotation." observed: log: "docs/user/live-walk-plan-step-readings-2026-10-11.md" result: "Run 2. Straight after the apply the Secret had no key and all 16 webhooks had an empty caBundle. 13 seconds after the apply the operator had written tls.crt and tls.key into the Secret and a caBundle into all 16. The StatefulSet rolled out with 1 Pod. An Elasticsearch with a bad version was refused with the operator's own message." - record: "elastic-eck-operator-3-4-0-ha" step: "webhook-certificate" reading: "workload-supplies" suppliedBy: "the ECK operator" instruction: "The ECK operator fills the empty Secret elastic-operator-webhook-cert after it starts and writes the caBundle into the webhook configuration, so you do nothing for this step." evidence: - path: "recipes/elastic/eck-operator/3.4.0/revisions/ha/r001/rendered/release-objects.yaml" object: "Secret default/elastic-operator-webhook-cert" shows: "The Secret has no data. It is a place for the operator to write its certificate." - path: "recipes/elastic/eck-operator/3.4.0/revisions/ha/r001/rendered/release-objects.yaml" object: "StatefulSet default/elastic-operator" shows: "The environment variable 'WEBHOOK_SECRET' is 'elastic-operator-webhook-cert', and the volume 'cert' mounts that Secret. This base asks for 2 replicas." - path: "recipes/elastic/eck-operator/3.4.0/revisions/ha/r001/rendered/release-objects.yaml" object: "ConfigMap default/elastic-operator" shows: "The key 'eck.yaml' sets 'enable-webhook: true' and 'webhook-name: elastic-operator.default.k8s.elastic.co'. It does not turn off the operator's own management of the webhook certificate." - path: "recipes/elastic/eck-operator/3.4.0/revisions/ha/r001/rendered/release-objects.yaml" object: "ClusterRole elastic-operator" shows: "Its rules grant 'update' and 'patch' on 'secrets' and on 'validatingwebhookconfigurations'." - path: "recipes/elastic/eck-operator/3.4.0/revisions/ha/r001/rendered/release-objects.yaml" object: "ValidatingWebhookConfiguration elastic-operator.default.k8s.elastic.co" shows: "None of its 16 webhooks has a 'caBundle', and the object has no 'cert-manager.io' annotation." observed: log: "docs/user/live-walk-plan-step-readings-2026-10-11.md" result: "Run 3, on the cluster of run 2 after that base's other objects were deleted and its CRDs were left. All 16 webhooks had an empty caBundle after the apply and a caBundle 2 seconds later. The image was already on the node. Both Pods became ready and one held the leader lease." - record: "elastic-eck-operator-3-4-0-no-crds" step: "webhook-certificate" reading: "workload-supplies" suppliedBy: "the ECK operator" instruction: "The ECK operator fills the empty Secret elastic-operator-webhook-cert after it starts and writes the caBundle into the webhook configuration, so you do nothing for this step." evidence: - path: "recipes/elastic/eck-operator/3.4.0/revisions/no-crds/r001/rendered/release-objects.yaml" object: "Secret default/elastic-operator-webhook-cert" shows: "The Secret has no data. It is a place for the operator to write its certificate." - path: "recipes/elastic/eck-operator/3.4.0/revisions/no-crds/r001/rendered/release-objects.yaml" object: "StatefulSet default/elastic-operator" shows: "The environment variable 'WEBHOOK_SECRET' is 'elastic-operator-webhook-cert', and the volume 'cert' mounts that Secret at '/tmp/k8s-webhook-server/serving-certs'." - path: "recipes/elastic/eck-operator/3.4.0/revisions/no-crds/r001/rendered/release-objects.yaml" object: "ConfigMap default/elastic-operator" shows: "The key 'eck.yaml' sets 'enable-webhook: true' and 'webhook-name: elastic-operator.default.k8s.elastic.co'. It does not turn off the operator's own management of the webhook certificate." - path: "recipes/elastic/eck-operator/3.4.0/revisions/no-crds/r001/rendered/release-objects.yaml" object: "ClusterRole elastic-operator" shows: "Its rules grant 'update' and 'patch' on 'secrets' and on 'validatingwebhookconfigurations'." - path: "recipes/elastic/eck-operator/3.4.0/revisions/no-crds/r001/rendered/release-objects.yaml" object: "ValidatingWebhookConfiguration elastic-operator.default.k8s.elastic.co" shows: "None of its 16 webhooks has a 'caBundle', and the object has no 'cert-manager.io' annotation." observed: log: "docs/user/live-walk-plan-step-readings-2026-10-11.md" result: "Run 4, on the cluster of runs 2 and 3, which still held the 12 CRDs this base leaves out. The Secret had no key after the apply. 2 seconds later it held tls.crt and tls.key and all 16 webhooks had a caBundle. The Pod became ready." - record: "grafana-rollout-operator-0-49-0-default" step: "webhook-certificate" reading: "workload-supplies" suppliedBy: "the rollout-operator" instruction: "The rollout-operator makes a self-signed certificate after it starts and fills the caBundle of all four webhook configurations, so you do nothing for this step." evidence: - path: "recipes/grafana/rollout-operator/0.49.0/revisions/default/r001/rendered/release-objects.yaml" object: "Deployment default/rollout-operator" shows: "The container arguments hold '-server-tls.enabled=true' and '-server-tls.self-signed-cert.secret-name=certificate'. The operator signs its own certificate and keeps it in a Secret named 'certificate'." - path: "recipes/grafana/rollout-operator/0.49.0/revisions/default/r001/rendered/release-objects.yaml" object: "Role default/rollout-operator-webhook-role" shows: "It grants 'create' on 'secrets', and 'get' and 'update' on the Secret named 'certificate'." - path: "recipes/grafana/rollout-operator/0.49.0/revisions/default/r001/rendered/release-objects.yaml" object: "ClusterRole rollout-operator-webhook-clusterrole" shows: "It grants 'list', 'patch' and 'watch' on 'validatingwebhookconfigurations' and 'mutatingwebhookconfigurations'." - path: "recipes/grafana/rollout-operator/0.49.0/revisions/default/r001/rendered/release-objects.yaml" object: "MutatingWebhookConfiguration prepare-downscale-default" shows: "It carries the label 'grafana.com/inject-rollout-operator-ca: \"true\"' and its webhook has no 'caBundle'." - path: "recipes/grafana/rollout-operator/0.49.0/revisions/default/r001/rendered/release-objects.yaml" object: "ValidatingWebhookConfiguration no-downscale-default" shows: "It carries the label 'grafana.com/inject-rollout-operator-ca: \"true\"' and its webhook has no 'caBundle'." - path: "recipes/grafana/rollout-operator/0.49.0/revisions/default/r001/rendered/release-objects.yaml" object: "ValidatingWebhookConfiguration pod-eviction-default" shows: "It carries the label 'grafana.com/inject-rollout-operator-ca: \"true\"' and its webhook has no 'caBundle'." - path: "recipes/grafana/rollout-operator/0.49.0/revisions/default/r001/rendered/release-objects.yaml" object: "ValidatingWebhookConfiguration zpdb-validation-default" shows: "It carries the label 'grafana.com/inject-rollout-operator-ca: \"true\"' and its webhook has no 'caBundle'." observed: log: "docs/user/live-walk-plan-step-readings-2026-10-11.md" result: "Run 5. Straight after the apply there was no Secret named certificate and all 4 webhooks had an empty caBundle. 21 seconds after the apply the operator had created the Secret and written a caBundle into all 4. The Deployment rolled out with 1 Pod. The walk sent no request through these webhooks." - record: "hashicorp-vault-0-32-0-dev-mode" step: "webhook-certificate" reading: "workload-supplies" suppliedBy: "the Vault agent injector" instruction: "The Vault agent injector makes its own certificate after it starts and fills the caBundle of the webhook configuration vault-agent-injector-cfg, so you do nothing for this step." evidence: - path: "recipes/hashicorp/vault/0.32.0/revisions/dev-mode/r001/rendered/release-objects.yaml" object: "Deployment vault/vault-agent-injector" shows: "The environment variable 'AGENT_INJECT_TLS_AUTO' is 'vault-agent-injector-cfg', the name of the webhook configuration. 'AGENT_INJECT_TLS_AUTO_HOSTS' lists the Service names the certificate is for." - path: "recipes/hashicorp/vault/0.32.0/revisions/dev-mode/r001/rendered/release-objects.yaml" object: "ClusterRole vault-agent-injector-clusterrole" shows: "It grants 'get', 'list', 'watch' and 'patch' on 'mutatingwebhookconfigurations'." - path: "recipes/hashicorp/vault/0.32.0/revisions/dev-mode/r001/rendered/release-objects.yaml" object: "MutatingWebhookConfiguration vault-agent-injector-cfg" shows: "Its one webhook has 'caBundle: \"\"', and the object has no 'cert-manager.io' annotation." observed: log: "docs/user/live-walk-plan-step-readings-2026-10-11.md" result: "Run 6. Straight after the apply the webhook had an empty caBundle. 8 seconds after the apply the injector had written one. It made no Secret. The injector and the Vault server Pod became ready, and a server dry-run of an annotated Pod came back with the vault-agent-init and vault-agent containers added." - record: "jetstack-cert-manager-v1-20-2-crds-enabled" step: "webhook-certificate" reading: "workload-supplies" suppliedBy: "the cert-manager webhook and cainjector" instruction: "The cert-manager webhook makes its own CA Secret after it starts and the cainjector copies it into both webhook configurations, so you do nothing for this step." evidence: - path: "recipes/jetstack/cert-manager/v1.20.2/revisions/crds-enabled/r001/rendered/release-objects.yaml" object: "Deployment cert-manager/cert-manager-webhook" shows: "The container arguments hold '--dynamic-serving-ca-secret-name=cert-manager-webhook-ca'. The webhook makes and serves its own certificate." - path: "recipes/jetstack/cert-manager/v1.20.2/revisions/crds-enabled/r001/rendered/release-objects.yaml" object: "Role cert-manager/cert-manager-webhook:dynamic-serving" shows: "It grants 'create' on 'secrets', and 'get', 'list', 'watch' and 'update' on the Secret named 'cert-manager-webhook-ca'." - path: "recipes/jetstack/cert-manager/v1.20.2/revisions/crds-enabled/r001/rendered/release-objects.yaml" object: "ValidatingWebhookConfiguration cert-manager-webhook" shows: "The annotation 'cert-manager.io/inject-ca-from-secret' is 'cert-manager/cert-manager-webhook-ca'. The cainjector reads it. The webhook has no 'caBundle'." - path: "recipes/jetstack/cert-manager/v1.20.2/revisions/crds-enabled/r001/rendered/release-objects.yaml" object: "MutatingWebhookConfiguration cert-manager-webhook" shows: "The annotation 'cert-manager.io/inject-ca-from-secret' is 'cert-manager/cert-manager-webhook-ca'. The webhook has no 'caBundle'." - path: "recipes/jetstack/cert-manager/v1.20.2/revisions/crds-enabled/r001/rendered/release-objects.yaml" object: "Deployment cert-manager/cert-manager-cainjector" shows: "The cainjector is one of this file's own workloads, so nothing outside the file is needed." - path: "recipes/jetstack/cert-manager/v1.20.2/revisions/crds-enabled/r001/rendered/release-objects.yaml" object: "ClusterRole cert-manager-cainjector" shows: "It grants 'update' and 'patch' on 'validatingwebhookconfigurations' and 'mutatingwebhookconfigurations'." - path: "runs/lifecycle-observations/cert-manager-eso/jetstack-cert-manager-crds-enabled/receipt.yaml" shows: "An earlier run of this base, on 2026-06-06, records the check 'webhook-ca-bundle:cert-manager-webhook' as a pass with every caBundle filled." observed: log: "docs/user/live-walk-plan-step-readings-2026-10-11.md" result: "Run 7. Straight after the apply there was no Secret cert-manager-webhook-ca and both webhooks had an empty caBundle. 29 seconds after the apply the Secret existed and the cainjector had written a caBundle into both. All three Deployments rolled out." # This reading has no observed block on purpose. The walk did not run the # hook Job. It did the Job's check by hand, so the step stays recorded as # not run and the log is cited as evidence instead. - record: "jetstack-cert-manager-v1-20-2-crds-enabled" step: "hooks" reading: "check-after-install" instruction: "The chart's hooks all belong to one Job that only checks the cert-manager API after an install, and the retained file leaves it out, so check the API yourself afterwards." evidence: - path: "recipes/jetstack/cert-manager/v1.20.2/revisions/crds-enabled/r001/receipts/scan-receipt.yaml" shows: "The finding 'helm-hook|Job|cert-manager|cert-manager-startupapicheck' says the startup API check is a Helm post-install hook that '--no-hooks' left out of the render." - path: "recipes/jetstack/cert-manager/v1.20.2/chart-dossier.yaml" shows: "The maintained note says 'startup API check is a Helm post-install hook and is excluded from the rendered revision by --no-hooks'." - path: "recipes/jetstack/cert-manager/v1.20.2/revisions/crds-enabled/r001/rendered/release-objects.yaml" absentKinds: - "Job" shows: "The retained file holds no Job, so the check does not travel with the objects. The installer package under packages/jetstack/cert-manager/v1.20.2 ships no hook file either." - path: "recipes/jetstack/cert-manager/v1.20.2/source-lock.yaml" shows: "The chart package with the 'packageSHA256' recorded here holds 'templates/startupapicheck-job.yaml'. Its one container runs with the arguments 'check', 'api' and '--wait'. The three hook lines the sweep counted in 'values.yaml' are the default annotations of that Job, its RBAC and its ServiceAccount." - path: "runs/lifecycle-observations/cert-manager-eso/jetstack-cert-manager-crds-enabled/receipt.yaml" shows: "An earlier run of this base records the hook policy 'startupapicheck-becomes-post-apply-api-dry-run' and a passing server dry-run of an Issuer." - path: "docs/user/live-walk-plan-step-readings-2026-10-11.md" shows: "Run 7. No Job ran and none existed on the cluster. All three Deployments rolled out without the hook. The walk then did the hook's check by hand. It applied a self-signed Issuer and a Certificate 45 seconds after the apply, and the Certificate was ready at once." - record: "kedacore-keda-2-19-0-default" step: "webhook-certificate" reading: "workload-supplies" suppliedBy: "the KEDA operator" instruction: "The KEDA operator makes the Secret kedaorg-certs after it starts and fills the caBundle of the webhook configuration and of the APIService, so you do nothing for this step." evidence: - path: "recipes/kedacore/keda/2.19.0/revisions/default/r001/rendered/release-objects.yaml" object: "Deployment default/keda-operator" shows: "The container arguments hold '--enable-webhook-patching=true', '--enable-cert-rotation=true' and '--cert-secret-name=kedaorg-certs'. Its volume mounts that Secret with 'optional: true'." - path: "recipes/kedacore/keda/2.19.0/revisions/default/r001/rendered/release-objects.yaml" object: "Role default/keda-operator-certs" shows: "It grants 'create' and 'update' on 'secrets', and 'get' on the Secret named 'kedaorg-certs'." - path: "recipes/kedacore/keda/2.19.0/revisions/default/r001/rendered/release-objects.yaml" object: "ClusterRole keda-operator-minimal-cluster-role" shows: "It grants 'patch' and 'update' on 'validatingwebhookconfigurations' and on 'apiservices'." - path: "recipes/kedacore/keda/2.19.0/revisions/default/r001/rendered/release-objects.yaml" object: "ValidatingWebhookConfiguration keda-admission" shows: "None of its 6 webhooks has a 'caBundle', and the object has no 'cert-manager.io' annotation." - path: "recipes/kedacore/keda/2.19.0/revisions/default/r001/rendered/release-objects.yaml" object: "APIService v1beta1.external.metrics.k8s.io" shows: "It has no 'caBundle' and no 'cert-manager.io' annotation." observed: log: "docs/user/live-walk-plan-step-readings-2026-10-11.md" result: "Run 8. Straight after the apply there was no Secret kedaorg-certs and all 6 webhooks had an empty caBundle. The operator created the Secret 15 seconds after the apply and then exited once on purpose so that it restarted with the new certificate. 47 seconds after the apply all 6 webhooks and the APIService had a caBundle. All three Deployments rolled out and the APIService was available." - record: "metallb-metallb-0-16-1-default" step: "webhook-certificate" reading: "workload-supplies" suppliedBy: "the MetalLB controller and frr-k8s" instruction: "The MetalLB controller and frr-k8s fill their two empty certificate Secrets after they start and write the caBundle into both webhook configurations, so you do nothing for this step." evidence: - path: "recipes/metallb/metallb/0.16.1/revisions/default/r001/rendered/release-objects.yaml" object: "Secret metallb-system/metallb-webhook-cert" shows: "The Secret has no data. It is a place for the controller to write its certificate." - path: "recipes/metallb/metallb/0.16.1/revisions/default/r001/rendered/release-objects.yaml" object: "Deployment metallb-system/metallb-controller" shows: "The container arguments hold '--webhook-mode=enabled', and the volume 'cert' mounts the Secret 'metallb-webhook-cert'." - path: "recipes/metallb/metallb/0.16.1/revisions/default/r001/rendered/release-objects.yaml" object: "ClusterRole metallb:controller" shows: "One rule grants 'patch' and 'update' on the ValidatingWebhookConfiguration named 'metallb-webhook-configuration'." - path: "recipes/metallb/metallb/0.16.1/revisions/default/r001/rendered/release-objects.yaml" object: "Role metallb-system/metallb-controller" shows: "One rule grants 'create', 'patch' and 'update' on 'secrets'." - path: "recipes/metallb/metallb/0.16.1/revisions/default/r001/rendered/release-objects.yaml" object: "ValidatingWebhookConfiguration metallb-webhook-configuration" shows: "None of its 6 webhooks has a 'caBundle', and the object has no 'cert-manager.io' annotation." - path: "recipes/metallb/metallb/0.16.1/revisions/default/r001/rendered/release-objects.yaml" object: "Secret metallb-system/frr-k8s-webhook-server-cert" shows: "The Secret has no data. It is a place for frr-k8s to write its certificate." - path: "recipes/metallb/metallb/0.16.1/revisions/default/r001/rendered/release-objects.yaml" object: "Deployment metallb-system/metallb-frr-k8s-statuscleaner" shows: "The container arguments hold '--webhook-port=19443', and the volume 'cert' mounts the Secret 'frr-k8s-webhook-server-cert'." - path: "recipes/metallb/metallb/0.16.1/revisions/default/r001/rendered/release-objects.yaml" object: "ClusterRole metallb-frr-k8s-controller" shows: "One rule grants 'update' on the ValidatingWebhookConfiguration named 'frr-k8s-validating-webhook-configuration'." - path: "recipes/metallb/metallb/0.16.1/revisions/default/r001/rendered/release-objects.yaml" object: "Role metallb-system/metallb-frr-k8s-controller" shows: "It grants 'update' on 'secrets'." - path: "recipes/metallb/metallb/0.16.1/revisions/default/r001/rendered/release-objects.yaml" object: "ValidatingWebhookConfiguration frr-k8s-validating-webhook-configuration" shows: "Its one webhook has no 'caBundle', and the object has no 'cert-manager.io' annotation." observed: log: "docs/user/live-walk-plan-step-readings-2026-10-11.md" result: "Run 9. Straight after the apply both Secrets had no key and all 7 webhooks had an empty caBundle. frr-k8s wrote its caBundle 20 seconds after the apply and the MetalLB controller wrote its 6 after 40 seconds. Both Secrets then held a certificate. All four workloads were ready 89 seconds after the apply, and the webhook refused a bad IPAddressPool by name." - record: "ingress-nginx-ingress-nginx-4-15-1-admission-disabled" step: "hooks" reading: "not-needed-in-this-base" instruction: "All eight hooks belong to the admission webhook's certificate Jobs, and this base turns the admission webhook off, so no hook applies and you do nothing for this step." evidence: - path: "data/flattening-safety/witnesses/ingress-nginx-ingress-nginx-4.15.1.yaml" shows: "The 8 'helm-hooks' findings are all files under 'templates/admission-webhooks/job-patch/'. Two of them are 'job-createSecret.yaml' and 'job-patchWebhook.yaml'." - path: "recipes/ingress-nginx/ingress-nginx/4.15.1/effective-values-admission-disabled.yaml" shows: "The values of this base set 'controller.admissionWebhooks.enabled: false'." - path: "recipes/ingress-nginx/ingress-nginx/4.15.1/revisions/admission-disabled/r001/rendered/release-objects.yaml" object: "Deployment ingress-nginx/ingress-nginx-controller" absentKinds: - "ValidatingWebhookConfiguration" - "Job" shows: "The container arguments hold no '--validating-webhook' flag and the Pod mounts no certificate Secret. The file holds no webhook configuration for a hook Job to patch." - path: "recipes/ingress-nginx/ingress-nginx/4.15.1/source-lock.yaml" shows: "In the chart package with the 'packageSHA256' recorded here, each of the 8 hook files opens with a condition on '.Values.controller.admissionWebhooks.enabled'." observed: log: "docs/user/live-walk-plan-step-readings-2026-10-11.md" result: "Run 10. The controller Pod was ready 47 seconds after the apply. The cluster held no webhook configuration, no Job and no Secret in the ingress-nginx namespace. The API server accepted an Ingress of class nginx and the controller picked it up. The Service is of type LoadBalancer, and its external address stayed pending on a local cluster." - record: "ingress-nginx-ingress-nginx-4-15-1-internal-clusterip" step: "hooks" reading: "not-needed-in-this-base" instruction: "All eight hooks belong to the admission webhook's certificate Jobs, and this base turns the admission webhook off, so no hook applies and you do nothing for this step." evidence: - path: "data/flattening-safety/witnesses/ingress-nginx-ingress-nginx-4.15.1.yaml" shows: "The 8 'helm-hooks' findings are all files under 'templates/admission-webhooks/job-patch/'. Two of them are 'job-createSecret.yaml' and 'job-patchWebhook.yaml'." - path: "recipes/ingress-nginx/ingress-nginx/4.15.1/effective-values-internal-clusterip.yaml" shows: "The values of this base set 'controller.admissionWebhooks.enabled: false'." - path: "recipes/ingress-nginx/ingress-nginx/4.15.1/revisions/internal-clusterip/r001/rendered/release-objects.yaml" object: "Deployment ingress-nginx/ingress-nginx-controller" absentKinds: - "ValidatingWebhookConfiguration" - "Job" shows: "The container arguments hold no '--validating-webhook' flag and the Pod mounts no certificate Secret. The file holds no webhook configuration for a hook Job to patch." - path: "recipes/ingress-nginx/ingress-nginx/4.15.1/source-lock.yaml" shows: "In the chart package with the 'packageSHA256' recorded here, each of the 8 hook files opens with a condition on '.Values.controller.admissionWebhooks.enabled'." observed: log: "docs/user/live-walk-plan-step-readings-2026-10-11.md" result: "Run 11, on the cluster of run 10 after that base's objects and namespace were deleted. The controller Pod was ready 15 seconds after the apply. The cluster held no webhook configuration, no Job and no Secret in the ingress-nginx namespace. The API server accepted an Ingress of class nginx and the controller picked it up." # This reading has no observed block on purpose. The walk ran this base # without the hooks, and it cannot say what the hooks do, so the step # stays recorded as not run. The log is cited as evidence instead. - record: "secrets-store-csi-driver-secrets-store-csi-driver-1-6-0-sync-secret-rotation" step: "hooks" reading: "unknown" instruction: "The chart's hooks sit in two files named for CRD upgrades, and this repository does not hold what they run, so this step stays yours to settle. The retained file holds both CRDs, and the driver started without the hooks on a new cluster." evidence: - path: "data/flattening-safety/witnesses/secrets-store-csi-driver-secrets-store-csi-driver-1.6.0.yaml" shows: "The 10 'helm-hooks' findings are 5 lines in 'templates/crds-upgrade-hook.yaml' and 5 in 'templates/keep-crds-upgrade-hook.yaml'. The hook values are 'pre-install,pre-upgrade' and 'pre-upgrade'. The witness records where the hooks are and not what they run." - path: "recipes/secrets-store-csi-driver/secrets-store-csi-driver/1.6.0/revisions/sync-secret-rotation/r001/rendered/release-objects.yaml" object: "CustomResourceDefinition secretproviderclasses.secrets-store.csi.x-k8s.io" absentKinds: - "Job" shows: "The retained file holds this CRD itself and holds no Job." - path: "recipes/secrets-store-csi-driver/secrets-store-csi-driver/1.6.0/revisions/sync-secret-rotation/r001/rendered/release-objects.yaml" object: "CustomResourceDefinition secretproviderclasspodstatuses.secrets-store.csi.x-k8s.io" shows: "The retained file holds this CRD itself." - path: "docs/user/live-walk-plan-step-readings-2026-10-11.md" shows: "Run 12. The test script applied the 2 CRDs first and both were established. The DaemonSet was ready with 3 of 3 containers 18 seconds after the apply. No Job existed, and the API server accepted a SecretProviderClass."