Keystone Fernet to JWS Token Provider Migration Prompt
Plan a safe cutover from the Fernet token provider to JWS (asymmetric) tokens across a multi-node Keystone deployment without invalidating live sessions.
- Target user
- Advanced Keystone operators evaluating JWS tokens
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior Keystone operator who has migrated production clouds between token providers. I will provide: - OpenStack release and current `[token] provider` plus Fernet key repository layout - Number of Keystone nodes, load-balancer setup, and how keys are distributed today (rsync/Barbican/config-mgmt) - Token TTL, `allow_expired_window`, and any services with long-running token reuse (Heat trusts, Nova, Cinder) - The driver for migrating (key-distribution pain, stateless validation, audit) and your maintenance-window constraints Your job: 1. **Impact analysis** — explain exactly what changes between Fernet and JWS (symmetric key repo vs asymmetric keypair, validation model, token size) and what breaks at cutover. 2. **Key strategy** — design the JWS keypair repository and rotation/distribution scheme across all nodes; map it against your current Fernet distribution. 3. **In-flight tokens** — determine the fate of existing Fernet tokens at switchover and how to drain or bridge them (TTL wait vs forced re-auth). 4. **Cutover plan** — an ordered, node-by-node sequence that keeps the LB pool consistent (all nodes must agree on provider + keys before they serve). 5. **Validation** — a `openstack token issue` / `token revoke` test matrix to run after each node flips. 6. **Rollback** — the exact steps and time window to revert to Fernet if validation fails. Output as: (a) a Fernet-vs-JWS impact table, (b) a node-by-node cutover runbook with LB drain steps, (c) a validation + rollback checklist. Do not flip the token provider on a node still in the LB pool serving live traffic; drain, flip, validate, re-add.
Why this prompt works
Token-provider migrations look like a one-line config change and are anything but. The hidden risk is that Keystone nodes behind a load balancer must all agree on the provider and the validating keys simultaneously; the moment two nodes disagree, every service in the cloud gets intermittent 401s that are maddening to diagnose. This prompt makes that LB-consistency constraint the spine of the cutover plan, forcing a drain-flip-validate-readd sequence instead of a naive parallel config push.
The in-flight-token question is the part most operators forget. Fernet and JWS tokens are validated differently, so existing tokens have a defined fate at cutover — and long-lived consumers like Heat trusts and autoscaling can break if you force re-auth without inventorying them first. By demanding an explicit impact table and a token-reuse inventory, the prompt surfaces these dependencies before they surface as a 2 a.m. page.
The rollback discipline is what makes this usable on a production cloud. Because the prompt insists you keep the Fernet key repository intact until JWS validation passes, reverting stays a config flip rather than a key-material restore. That single constraint converts a scary, irreversible-feeling migration into a staged, reversible one — which is exactly the posture you want when an AI drafted the plan and a human is executing it.