Gate Python Releases on Known Dependency CVEs with pip-audit
Run pip-audit against locked pins, grade findings by severity, block the release above your budget, and alert Slack.
Recover a pending Helm upgrade or rollback after a grace window, explicit approval and a cooperative release fence. Verify the restored revision and manifest.
A cancelled runner can leave Helm pending-upgrade. Later upgrades refuse another operation in progress.
Rollback can rerun hooks and change workloads. Confirm data compatibility first.
| Guard | What it stops |
|---|---|
| Stable revision/status/time plus KV grace | A brief pending window becoming a recovery |
| Explicit approval and stopped-runner confirmation | Cancelling an active deployment |
| Conditional ConfigMap fence plus fresh reads | Cooperating writers and stale approval |
| Explicit deployed baseline | Rolling back into a failed previous attempt |
helm.Status reads one release. A cluster-scoped KV key remembers its revision, status and deployment time. Only unchanged pending-upgrade or pending-rollback observations aged at least grace_seconds qualify. Future observations reset; malformed or oversized records fail.
Native Kubernetes Get reads at most history_window exact Helm Secret names. Their labels select the newest deployed baseline, checked again with helm.Status. Dry-run logs the proposal. Write mode pauses for both confirmations, conditionally acquires a dedicated ConfigMap and re-reads the release and baseline under that fence. helm.Rollback runs once. A final Status must be deployed at initial revision + 1 with the approved manifest. Only then is the fence released.
A proposal, native outputs and a failed execution when recovery is refused or incomplete. No write retries.
Platform teams with a shared release mutex and a data-compatible previous chart.
KV carries the observation across runs. Pause records the recovery decision. Native tasks keep the selected revision, conditional fence changes and verification in one execution. Flow concurrency queues overlapping runs of this flow only.
Kestra 2.0.6 and 2.0.5 with Helm 4.3.0 and Kubernetes 1.31.5. A real upgrade was killed during a sleeping hook; the next CLI upgrade was blocked. Recovery restored deployed status and the next upgrade succeeded. A fresh cluster reproduced revision 2 to 3 recovery, preserving 2 payload values and an unrelated release. Declined approval did not write. Refused rollback failed. Stale approval failed before rollback. A killed native rollback left pending-rollback and a held fence; a fresh run recovered after manual reconciliation. Two servers contending for one fence produced one rollback.
Helm Secret storage, a reachable API, Docker workers and the Helm, Kubernetes and Slack plugins. Read access needs Secret get/list. Rollback needs Secret create/update/delete plus the verbs required by the chart and its hooks. Fence get/patch is required. Helm may prune old history at its default retention limit.
K8S_MASTER_URL, K8S_CA_CERT (base64 CA), K8S_TOKEN and SLACK_WEBHOOK_URL. The token input is SECRET.
release_name/release_namespace select one target. Grace defaults to 1800 seconds, history lookback to 20 (maximum 100). Defaults are dry_run: true, auto_remediate: false. docker_network defaults to bridge.
helm-recovery-<release> in the release namespace. Set annotations helm-recovery-release: <release> and helm-recovery-holder: "". Every release writer must acquire it conditionally and hold it through its operation.Add a service smoke test before releasing the fence. Limits: no fence expiry, no protection from writers ignoring the contract and no reversal of external hook/data effects. Pending-install and failed states are spared. The plugin reads the full release manifest; deployed status is not application-health proof. The disabled schedule forces safe mode.
This blueprint was created by zkasuran.
