Per container generated secrets (idea)

Archive Rancher 1.x
1

I read yesterday Alarms in rancher#930.
I am wondering if similar approach would allow for providing secrets? I have studied vault and other approaches on distribution of secrets in docker but most of them are quite complicated or impossible to setup for custom secrets providers.

Let say I have app service that needs access to custom cdn service.
Specifying label com.example.allow.cdn.read=CDN_CREDENTIALS container would get either in env CND_CREDENTIALS_TOKEN and CND_CREDENTIALS_SECRET_TOKEN or in metadata service under ie.> /cdn/{,secret_}token.

Theory:

  1. I have agent that is able to setup access to service A read and write.
  2. Agent watches for containers with certain labels.
  3. Service B is scheduled via its label it is clear its containers need read access to service A.
  4. Agent creates read access for containers of service B and provides it each of them.
  5. profit
  6. Service B is removed
  7. Agent deletes read access for containers of service B.

Assuming secrets are not necessary for removing access and each container gets own unique access key.

Would this be of some value?

EDIT: There is project called conjur that replaces secrets in ENVs.

2

Sorry, but I fail to see the benefit here. If all you need is to launch a container with a certain label to get access… how’s that more secure than, say, using ENV vars with the credentials directly?

3

DevOps benefit is that you can delegate its management to secrets service.
Security benefits include separate credentials per container/service, removing burden of generating access tokens from configuration tool. And opens up other possibilities such as audit trails, revoking secrets etc.

For example to utilize vault you can have sidekick with configuration and token that will provide all the secrets via volumes. But you have to setup sidekick tokens in the configuration before the deployment, along with creating necessary security groups in vault.

That’s where such label would be useful. It would signal to secrets service that it needs new account for role X.Y. Secrets service would generate all necessary secrets that come with X.Y role and send back token that allows access to them.
That could be done on per service or container level ie. sharing same account for service or all containers having own accounts. And by monitoring service/container lifecycle secrets could live only for necessary time.

EDIT: Another use-case could be debugging via Rancher UI. For example I need same access to database as has some service. I could do that by spawning adminer.org container with label to have a look without need to copy passwords or access token.