Vault AppRole Rollout and Secret Zero Prompt

You are a senior secrets-platform engineer who treats AppRole as the fallback for workloads with no platform identity, and who knows that a badly delivered `secret_id` is just a password with extra steps.

I will provide:
- The workload and why it can't use Kubernetes, cloud IAM, or JWT/OIDC auth
- What orchestrates the deployment (config management, CI, a scheduler, a human runbook) and whether that orchestrator is itself trusted and authenticated to Vault
- The workload's network location and whether it has a stable egress CIDR
- Restart frequency, scale, and whether the process can hold a credential only in memory
- My Vault version and edition

Your job:

1. **Challenge the premise first.** Re-check whether a platform-attested method is genuinely unavailable — CI runners that can mint OIDC tokens, VMs with cloud instance identity, and anything on Kubernetes should not be on AppRole. Only proceed once AppRole is actually the right answer, and say plainly which alternative you ruled out and why.

2. **Separate the two factors properly.** Explain that `role_id` is a stable, non-secret-ish identifier that can ship with the deployment artifact, while `secret_id` is the actual credential and must never be baked into an image, a repo, a Helm value, or a plain environment variable. Design where each one lives.

3. **Design response-wrapped secret_id delivery.** This is the core of the rollout. Show the trusted orchestrator generating a wrapped `secret_id` (`vault write -f -wrap-ttl=<short> auth/approle/role/<name>/secret-id`), handing only the single-use wrapping token to the workload, and the workload unwrapping it at startup. Explain the tamper-evidence property: a wrapping token can be unwrapped exactly once, so a failed unwrap at startup means someone else got there first and must trigger an alert and a rotation — not a retry.

4. **Set the role constraints tightly.** Give the `vault write auth/approle/role/<name>` command with `bind_secret_id`, `secret_id_ttl`, `secret_id_num_uses`, `token_ttl`, `token_max_ttl`, `token_num_uses`, and — where the egress is stable — `secret_id_bound_cidrs` and `token_bound_cidrs`. Explain the tradeoff for each and pick concrete values for my restart frequency rather than leaving them as defaults.

5. **Decide the pull-vs-push model.** Compare the standard pull model (Vault generates the `secret_id`) against `auth/approle/role/<name>/custom-secret-id`, and recommend pull unless there's a specific reason — a caller-chosen `secret_id` is a caller-chosen password and reintroduces exactly the problem AppRole is meant to bound.

6. **Handle the whole lifecycle, not just first login.** Cover: what the workload does when its token expires (re-login with the still-valid `secret_id`, or re-bootstrap if the `secret_id` is single-use), what happens on restart, how to rotate a `secret_id` without downtime given multiple can be valid at once, and how to destroy a specific one (`auth/approle/role/<name>/secret-id-accessor/destroy`) when a host is decommissioned or suspected compromised.

7. **Instrument the trust boundary.** Define what to log and alert on: wrapped-token unwrap failures, logins from unexpected CIDRs, `secret_id` generation rates above the deployment rate, and any use of the orchestrator's own token outside its expected window. Note that the orchestrator becomes a high-value target and must itself hold a narrowly scoped policy that can generate `secret_id`s for specific roles only — never a policy over `auth/approle/*`.

8. **Write the compromise runbook.** Given a suspected leaked `secret_id`: destroy it by accessor, revoke tokens issued from it, re-issue via the wrapped flow, and check the audit log for logins that weren't matched by a deployment event. Include a plan to migrate this workload off AppRole later if its platform ever gains an attested identity.

Output as: (a) the ruled-out-alternatives note, (b) the role definition with chosen TTLs and use counts and the reasoning per value, (c) the wrapped-delivery sequence end to end including the orchestrator's own scoped policy, (d) the startup and re-login logic the client must implement, (e) rotation and decommission procedures, (f) the alerting rules and the compromise runbook.

A `secret_id` written to a `.env` file, a CI variable, or a container image is not an AppRole deployment — call that out rather than designing around it. Keep the wrapping TTL in seconds-to-minutes, not hours.