Creating "master" token which can create new policies and subtokens with the policies

1,032 views
Skip to first unread message

upi...@gmail.com

unread,
May 17, 2017, 5:24:29 AM5/17/17
to Vault
Hi,

My company has a bunch of teams and I need to give each team its own "master" token, such that a token can create new policies and new child tokens (with the policies). The plan is that each team manages its own secret/teamX/* secret space and doesn't have access to other team's secret spaces. The complication is that each team can has multiple services and each service should be able to read only its own secret/teamX/serviceY/* subspace. The team's "master" token will be used to write all the services configurations, create a new policy for each service and then a new token with the policy.

The configuration I tried (below) doesn't work:

teamA_master_policy.hcl:

path "secret/teamA/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

path "auth/token/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

path "sys/policy/*" {
  capabilities = ["create"]
}

The problem is when I create a new teamA_service1_policy and use it to create new token for service1, the token cannot be created because policy teamA_service1_policy is new and not in "master" token.

I've read carefully Vault documentation and google groups and have not found a solution which would not break security requirement that teams are not allowed to read each others subspaces. Is it possible to create such "master" keys in Vault?

Jeff Mitchell

unread,
May 17, 2017, 5:30:24 AM5/17/17
to Vault
Hi,

It is not, currently. We hope to get there eventually. We know what this capability would look like but it's waiting on some other pieces to fall into place first.

Best,
Jeff

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/13f16fe4-a603-4624-b1ac-2ec1830d57b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

upi...@gmail.com

unread,
May 17, 2017, 5:40:57 AM5/17/17
to Vault
Thanks, Jeff.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.

Alessandro Scuderetti

unread,
May 17, 2017, 10:08:59 AM5/17/17
to Vault
You could add "sudo" capability in "auth/token/create*" in "master token" policy

In this way you should be able to generate token with policy that are not in "master" token.

Right?

Jeff Mitchell

unread,
May 17, 2017, 10:19:33 AM5/17/17
to Vault
Actually the better way to do that (*much* better way) is with roles in the token backend.

However the part that Vault doesn't address right now is the other part: policy creation. He can't give a team admin the ability to create or manage policies without that team admin theoretically being able to grant himself/herself or team members access all over Vault, including to other team spaces, or to dangerous endpoints.

Best,
Jeff

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/619b3436-2ad2-426d-a0b2-b567363cef02%40googlegroups.com.

Paul Archer

unread,
May 17, 2017, 12:58:21 PM5/17/17
to Vault
What about mounting multiple 'secret' backends? EG: vault mount -path=teamX secret
Then the ACL covers the whole mount, and adding a new service would still be part of the mount?

Paul
Reply all
Reply to author
Forward
0 new messages