Support for delegation

[JensRantil]

This is a feature request. I skimmed the issues but couldn't find if this has been discussed:

Use case 1: A company has some passwords that need to be accessible in plain text. They can be root passwords or other sensitive material that needs to be stored somewhere. Generally secrets like this are stored in a safe, in something like 1Password in multiple developer/ops machines, or even worse in text files somewhere.

Problem: The above solutions all have their issues, mostly related to access control, synchronization, auditability.

Use case 2: An application/user that that occasionally needs one-off access to a secret manually triggered by an ops person. This can for example be the backup restore script that needs decrypt key or an appplication being deployed that needs to be given access to an in-memory injection key at startup.

Proposal: That vault supports delegation of access to secrets something like this:

1. Configure Vault ACL to allow secrets to a certain instance as long as user X, Y, Z has approved.
2. The instance (such as backup restore script) authenticates with Vault and asks for the secret. Delivering the secret blocks with a required timeout.
3. Either user X, Y, Z approves the read of the secret; or
4. A timeout occurs and the secret is denied to the instance.

Considerations:

• As much information as possible should be available to the approvers to assert that the requester is who it claims to be.

Remarks:

• Clearly this would add some orchestration to Vault. I think an initial solution would be fine if it didn't support HA as approvals always will be manual.

Is this a feature that would be within the scopes of Vault? I have searched for a solution that basically would allow interactive Shamir's Secret Sharing Scheme interactivelly in a web interface. So far I haven't found anything like that. If Vault implements delegation, adding a web interface for general secrets to root passwords etc. would be a relative easy thing to do. Let me know what you think!

[JensRantil]

Configure Vault ACL to allow secrets to a certain instance as long as user X, Y, Z has approved.

Should probably also support at least n approvals. Quorum of users could also be an idea.

[sethvargo]

Hi @JensRantil

I think you have a few options here.

1. Vault recently added the ability to have limited-use tokens. For example, you can give a user a token that is only valid to read from Vault once, then self-expires. This would be beneficial for that "one-time-password-sharing" use case.
2. Vault has a fairly rich ACL system, so you can restrict which paths a token can read/write/sudo. Combined with the first point, this means you could use the transit backend and have the operator write to a know path and have the user read from the known path.
3. The transit backend is the backend that behaves most similar to tools like LastPass or 1Password. You can read more about how we use it in Atlas as well. In this backend, Vault holds the keys, but you still store the encrypted data. So users could still store the encrypted passwords in text files on their system, but they need Vault to decrypt back into plain-text. The entire process is audited.

I think having Vault "block" until approval is a bit outside of the scope of Vault and not one of the primary use cases. Instead, I think it would trivial to build a tiny application around Vault that acted as this gatekeeper.

What do yout hink?

[JensRantil]

Late answer here; Sounds like my use case can be solved some other way. Great! Closing this...