Access control to restrict groups of users to specified paths
Closed this issue · 7 comments
From @gdenn on October 13, 2017 7:25
Feature Request
Problem
We access the same credhub with multiple users through the credhub cli. But i don't want everyone to see all the variables in the credhub. E.g. we have credentials only relevant for specific Concourse Pipelines, credentials needed by an Administrator for our bosh deployment or simple credentials that help apps to access their dashboard.
As we are redeploying our bosh from time to time to include new features, it is important to us that the different people can access their passwords without conducting a system administrator.
But on the other hand we don't want to expose all credentials to everyone.
Solution
credhub cli could support different user groups. Each group gets e.g. access to a certain set of credentials that match a prefix. For our Concourse users this prefix would be /concourse.
With the different user groups i could create user accounts with only the access permissions i am comfortable to give.
best
Copied from original issue: cloudfoundry/credhub-cli#19
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/152004746
The labels on this github issue will be updated when the story is started.
From @cf-gitbot on October 13, 2017 7:25
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/151939991
The labels on this github issue will be updated when the story is started.
Hey @gdenn. Your problem as I understand from Dan's blurb is that you're using a single credhub cluster in a multitenant way, and you would like to be able to scope credentials appropriately so that some users can only see their needed subset of credentials? Do I have that right?
Similar to this, there is an issue where we'd like to allow multiple Concourse teams to self-serve effectively. Giving them the rights to manage their own credentials without accessing other teams' credentials would be a big step towards achieving that.
Otherwise we have to restrict access to CredHub and there's a bottleneck in teams wanting to maintain their own pipelines. Credentials then have to be transmitted from different teams to those with access to CredHub which increases the surface area for an attacker trying to steal credentials.
Piggybacking off @jshulver , we have the exact same problem. I'd like teams to be able to upload their Concourse credentials into CredHub, but I can't freely give teams credhub login access because then every team would have access to everyone's Concourse credentials. So to upload/change a single team's creds, they have to ask one of the platform admins (me) to do it for them, which creates bottleneck. Then they have to send me their creds via a private GitHub repo, and I upload it for them. If there were scoped access control, I could provision their Concourse teams & dole out credhub access such that teams could self-service themselves (and only themselves) & they could leave me out of the rest.
Hi @danjahner
I had a similar requirement (not exactly like the one above, but restrict read of only a select few creds to few users) and i was looking at using the attributes additional_permissions[].actor & additional_permissions[].operations[] API Doc. I was able to set the same with specific identities with specific access, however somehow these dont seem to be enforced and any random user with the scope of 'credhub.read' can read any creds. So what is the significance of additional_permissions and can it be used to effectively define required fine grained authorization?
Regards,
Jagadish
@jagadish-kb If the permissions aren't being respected it's probably because ACL's aren't being enabled. See the spec file for information on how to enable this. Prior to 2.0 this was not enabled by default.
These issues seem to be addressed in CredHub 2.0- you can now specify permissions on namespaces of credentials. See the release notes for more information.