allstar
allstar

Reputation: 1205

services accessing a secret store

I'm trying to understand the interactions between humans, services, and secret stores. I've been looking at HashiCorp Vault documentation and tutorial to try and get a better understanding. I'm using Vault instead of the more cumbersome 'secret store' below:

The use case is when a service needs to access Vault to get a secret (such as db connection string). It seems like the human that configures the service with the credentials to access Vault would also know those credentials and can impersonate that service at any time.

On the other hand, if Vault was also the identity provider for the service, it could provide one-time-use initial credentials to be used during service initialization. Then, these are rotated out. At that point, a human cannot impersonate the service they set up during 'normal operation'.

However, I haven't read this use case in the documentation, so I'm confused.

To add clarity, I understand that eventually someone must be trusted. For example, the ops engineer can have his own credentials to access Vault and get a password for the same database. This would allow the user access, but not allow that user to impersonate the service. Is there any reason that the ops engineer should also know the service's own credentials to access Vault after the initialization?

Upvotes: 3

Views: 377

Answers (1)

Colin Nicholson
Colin Nicholson

Reputation: 1379

Vault supports creating one time use credentials for several services, mostly databases - see the Secret Backend section of the docs.

The mysql backend includes the following description:

Additionally, it introduces a new ability: with every service accessing the database with unique credentials, it makes auditing much easier when questionable data access is discovered: you can track it down to the specific instance of a service based on the SQL username.

Upvotes: 1

Related Questions