We’re setting up HashiCorp Vault, but some credentials arrive from another team or an external vendor. How do you decide who owns them, who puts them in Vault, and how to avoid making the platform team handle every update?
Who should own credentials that come from vendors or other teams?
Asked by
R4!Mastodon
Answers
Separate custody from ownership. The team that can create or rotate a credential should usually be accountable for keeping it current. Your platform team can provide the Vault path, policies, and process without becoming the owner of every password it stores.
Write down the owner, rotation responsibility, consuming application, and escalation contact for each secret. That small bit of metadata helps when someone leaves or a credential stops working.
Reply to this answer
Let teams manage their own narrowly scoped paths, but don't hand out broad Vault access. Give each app or team an identity with only the permissions it needs, and keep path creation, policies, and authentication setup under a reviewed platform process.
For a small setup, a configuration repository and pipeline can make the routine work self-service while preserving review history. Be careful about putting secret values in source control, even encrypted ones, unless that workflow is deliberately designed and protected.
FennelMeter:
Would you give the app team read and write access to the same path?
Reply to this answer
I'd avoid making manual credential handoffs the normal design if there is another option. Ask the issuing team or vendor for a dedicated account, a supported rotation mechanism, or a way for your service to retrieve credentials directly. Shared accounts make attribution and rotation harder.
That won't be available in every vendor relationship, so have an import process for the exceptions. Record who supplied the credential and how replacements are delivered.
Reply to this answer
Think about rotation before deciding who gets write access. If a vendor changes a password without a coordinated handoff, storing it in Vault doesn't prevent an outage. Agree on timing, notification, testing, and rollback steps with whoever controls the account.
For credentials your own team can rotate, automate it where the system supports that. For ones you cannot rotate, make the dependency explicit and review it periodically.
Reply to this answer
There's no single ownership model that fits every organization. A useful split is for the platform team to own Vault's structure and guardrails, while application teams own their consumers and the relevant credential workflow. The issuing team or vendor may still own the account itself.
Start with a small, documented path and access pattern, then check whether teams can use it without platform staff handling every change. Compliance requirements may affect who is allowed to approve or perform each step.
Reply to this answer
Add your answer
Answers are reviewed before publication.
R4!Mastodon:
That distinction helps. What if the vendor controls rotation and only sends us replacement credentials?
D3xter+:
Then treat the vendor as the rotation owner and your team as responsible for importing the replacement and confirming the application can use it. Set an agreed update channel and escalation path rather than assuming rotation will happen automatically.