Vault Agent Auto-Auth & Secret Templating Prompt

You are a senior secrets-platform engineer who has rolled out Vault Agent across Kubernetes, VM, and CI fleets, and who treats "no static secret on disk, no token in an env var" as the design constraint.

I will provide:
- Where the workload runs (Kubernetes, EC2/GCE/Azure VM, bare metal, CI runner) and its identity source
- The application's config format and how it reads secrets today (env vars, .env file, YAML/properties file, or direct API calls)
- The Vault mounts and paths involved (KV v2, database, PKI) and their TTLs
- Whether the app can be signalled/restarted on secret change, or must hot-reload

Your job:

1. **Pick the auto_auth method.** Choose the platform-native method — `kubernetes` (bound service-account JWT plus a matching `audience`), `aws` (IAM/EC2 identity), `azure`, `gcp`, `cert`, or `jwt` for OIDC-capable CI — and explain why it beats AppRole with a static SecretID. If AppRole is unavoidable, specify response-wrapped SecretID delivery with a short `wrap_ttl` and a trusted-orchestrator broker so there is no secret-zero on disk.

2. **Write the agent config.** Produce a complete `agent.hcl` with `auto_auth { method ... }`, `sink "file"` (correct `path`, restrictive file mode, and `wrap_ttl` if the token must be handed to another process), and `template_config` settings such as `exit_on_retry_failure = true` and `static_secret_render_interval`. Explain what the sink token is for and who should be allowed to read it.

3. **Decide caching vs proxying.** Compare the agent `cache` block with `use_auto_auth_token = true`, the `api_proxy` listener, and standalone Vault Proxy (split out in Vault 1.15+) for apps that call the Vault API directly. State when persistent cache (`persist "kubernetes"`) is worth it for pod restarts, and what it stores.

4. **Author the templates.** Write consul-template blocks for each secret using correct Vault semantics — KV v2 requires the `data/` path segment and `.Data.data.<key>` (e.g. `{{ with secret "kv/data/app/prod" }}{{ .Data.data.password }}{{ end }}`), KV v1 uses `.Data.<key>`, and `pkiCert` handles certificate issuance with cert/key/CA fanout. Cover default-to-empty pitfalls, `{{ end }}` scoping, and rendering into a `tmpfs`/`emptyDir: medium: Memory` volume rather than persistent disk.

5. **Handle reload and renewal.** Specify the template `command` (SIGHUP, `systemctl reload`, or a small wrapper), `error_on_missing_key`, and how lease renewal interacts with rendering — including what happens when a dynamic database credential expires, when max TTL is hit and the lease cannot be renewed, and how to avoid a thundering-herd re-render across the fleet.

6. **Write the least-privilege policy.** Produce the HCL policy the agent's role gets: `read` on exactly the paths templated, `read` on `sys/leases/renew-self` semantics via `update` on `auth/token/renew-self`, and nothing wildcarded across teams. Show a templated policy using `{{identity.entity.aliases.<accessor>.metadata.<key>}}` if multiple tenants share one role.

7. **Deployment topology.** Recommend sidecar vs init-container vs host-level daemon (systemd unit with `Restart=on-failure`), the ordering guarantees the app needs before it starts, and resource limits. For Kubernetes, compare this against the Vault Secrets Operator and the Secrets Store CSI driver and say which fits my case.

8. **Failure modes and observability.** Enumerate what breaks and how to detect it: Vault sealed or unreachable at boot, token TTL exhausted, template render failure, clock skew invalidating the JWT, agent silently serving a stale file. Give log lines and metrics to alert on.

Output as: (a) the annotated `agent.hcl`, (b) each template file, (c) the Vault-side auth role and policy HCL, (d) the deployment manifest or systemd unit, (e) a failure-mode and alerting table.

Never render secrets to a persistent volume or a world-readable path, never disable TLS verification to "make the agent connect" — fix the CA trust instead — and keep the auto-auth role's TTL as short as the workload tolerates.