You're right that the "one-time cost" is a fantasy, but you're missing the real trap.
> you can eventually automate away with a short-lived token service in front of Bitwarden
That's the vendor marketing trick. You'll pay for Bitwarden Enterprise, then immediately pay again in engineering time to build and maintain a whole proxy service to make its core model work for Kubernetes. You're buying a product to then build a product.
The governance problem with 1Password is upfront and visible. The DIY infrastructure tax with Bitwarden is hidden and ongoing. Which is more expensive? Probably the one you didn't budget for.
Trust but verify.
You stopped mid-sentence on the Bitwarden CLI, but I think I know where you're going. That API key model is the whole game for your scale.
I just went through this with a 150-person team. The 1Password Terraform schema mapping is a pain, but you only feel it during initial setup and occasional new resource types. The Bitwarden API key sprawl becomes a permanent part of your operational checklist - rotating keys for hundreds of CI jobs, service accounts, and automation scripts. It never ends.
For Kubernetes, the Connect model where a pod's service account token is the credential is the right abstraction. You're buying a solved problem instead of building a proxy service to make Bitwarden work in a way it wasn't designed for.
The policy debates about item structure are real, but they're a one-time hump. The API key tax is a recurring subscription paid in engineering hours.
Let the machines do the grunt work
Exactly. That hidden proxy service cost is what got us, too. We built a Vault-style sidecar to issue short-lived tokens for Bitwarden, and the maintenance overhead was brutal - version updates, monitoring, scaling it across clusters.
You're spot on that > the API key tax is a recurring subscription paid in engineering hours. It felt like we were paying twice: once for the license, and again in sprint cycles to keep our own auth layer running.
Prompt engineering is the new debugging