Rotate Vault Secrets into Kubernetes with a Rolling Restart

Rotating credentials is only half the job: once a secret changes in HashiCorp Vault, the Kubernetes Secret that mirrors it and every pod that mounted the old value still need to catch up. This blueprint closes that gap end to end. It reads the current secret from a Vault HTTP endpoint, patches the matching Kubernetes Secret with the new base64-encoded value, triggers a rolling restart of the Deployment so running pods pick up the rotated credential, and reads the Deployment back to confirm the rollout landed. The result is a repeatable, auditable secret-rotation pipeline for Kubernetes workloads instead of a manual kubectl ritual nobody wants to own.

How it works

1. read_from_vault (io.kestra.plugin.core.http.Request) issues a GET to the vault_path URL, authenticating with the X-Vault-Token header so it returns the current secret payload.
2. patch_secret (io.kestra.plugin.kubernetes.kubectl.Patch) applies a JSON_MERGE patch to the secret named by secret_name, writing the value extracted from the Vault response (parsed with jq and base64encode) into the Secret's password key.
3. restart_deployment (io.kestra.plugin.kubernetes.kubectl.Restart) performs a rolling restart of the named Deployment, the same operation as kubectl rollout restart, so pods remount the refreshed Secret.
4. verify_rollout (io.kestra.plugin.kubernetes.kubectl.Get) reads the deployments resource back with fetchType: FETCH to confirm the new rollout.
5. A disabled io.kestra.plugin.core.trigger.Schedule trigger (weekly_rotation, cron 0 3 * * 0) is included so you can flip rotation to a weekly cadence.

What you get

• Vault-to-Kubernetes secret sync without hand-running kubectl patch.
• Automatic rolling restart so workloads actually consume the new credential.
• A verification step that reads the Deployment back after the restart.
• A ready-to-enable weekly schedule for recurring rotation.

Who it's for

• Platform and DevOps engineers managing Kubernetes secrets.
• SREs who own credential rotation and want it audited and repeatable.
• Security teams enforcing periodic secret refresh policies.

Why orchestrate this with Kestra

Vault can store and version secrets, and Kubernetes can mount them, but neither one reaches across the boundary to patch the cluster Secret and force the pods to reload it. Kestra wires the two together as one declarative YAML flow: event or schedule triggers drive it, retries and error handling cover transient API failures, and every run is logged with inputs and outputs for full rotation lineage. You get the cross-system glue that Vault's own lease renewal and Kubernetes' reconciler cannot provide on their own.

Prerequisites

• A Kubernetes cluster reachable via its API, with a Secret and Deployment that already reference it.
• A Vault HTTP endpoint that returns the secret JSON.

Secrets

• VAULT_TOKEN: token used to read the secret from Vault.
• K8S_MASTER_URL: Kubernetes API server URL.
• K8S_TOKEN: OAuth token for the Kubernetes API.

Quick start

1. Define VAULT_TOKEN, K8S_MASTER_URL, and K8S_TOKEN as secrets in your Kestra namespace.
2. Point vault_path at the Vault endpoint that returns your secret.
3. Run the flow with namespace, secret_name, and deployment_name set for your workload.
4. Inspect outputs.verify_rollout to confirm the Deployment rolled successfully.

How to extend

• Adjust the jq path in patch_secret to match your Vault secret layout, or patch multiple keys at once.
• Enable the weekly_rotation trigger, or swap it for a Flow trigger fired when Vault emits a rotation event.
• Add a notification task (Slack, email) that reports the rollout status from verify_rollout.
• Fan out across several Deployments or namespaces with a ForEach loop over a list input.

Links

• Kestra Kubernetes plugin
• Orchestrate Kubernetes with Kestra