Feature Narrative: Fine-granular & custom platform roles for Cloud Foundry
|
Klevenz, Stephan <stephan.klevenz@...>
Hi CF,
Here is a feature narrative and it is called "Fine-granular & custom platform roles for Cloud Foundry".
https://docs.google.com/document/d/1isfsSWvF8xDU0G69k4MqB3o5c2vB0P3Vbi79W0yvqFQ/edit?usp=sharing
This proposal is the result of direct feedback we have received from many CF users. It addresses the problem that every space developer can delete a service. And there may be important data attached to this service. Oops. Comments, feedback, suggestions, and questions very welcome and appreciated!
Regards, Stephan
|
|
|
|
Peter Burkholder
This is really a promising step. cloud.gov uses "service accounts", https://cloud.gov/docs/services/cloud-gov-service-account/, which are implemented with: https://github.com/cloudfoundry-community/uaa-credentials-broker. Usually these are used in CI/CD systems for deployments. The service accounts are way too over-powered using the Developer role, so this is a great step to scoping deployer accounts to, well, deployments in a CD system. However, I think the Operator account is too restrictive for any real human operator, and too expansive for a CI deployer account. I'd like to see Operator renamed to Deployer and have some further rights removed, like viewing other spaces or or other users and roles, perhaps. Or if there's a real need for the Operator role, then maybe add yet another role for Deployers (but that seems to be getting into IAM-level scope creep). --Peter On Wed, Dec 2, 2020 at 11:27 AM Klevenz, Stephan <stephan.klevenz@...> wrote:
-- - Peter Burkholder | cloud.gov compliance & security please use cloud-gov-compliance@... for cloud.gov matters |
|
|
|
Duncan Mcintyre <mcintyredu@...>
I’m all for anything which gives finer grained control. At present customers like RBS wrap the cf api with their own tooling in order to limit who can do what – which is obviously not optimal.
Shame we never implemented the ability to define custom roles in the database rather than have them hard-coded.
D
From:
cf-dev@... <cf-dev@...> This is really a promising step.
cloud.gov uses "service accounts",
https://cloud.gov/docs/services/cloud-gov-service-account/, which are implemented with:
https://github.com/cloudfoundry-community/uaa-credentials-broker. Usually these are used in CI/CD systems for deployments. I'd like to see Operator renamed to Deployer and have some further rights removed, like viewing other spaces or or other users and roles, perhaps.
Or if there's a real need for the Operator role, then maybe add yet another role for Deployers (but that seems to be getting into IAM-level scope creep).
--Peter
On Wed, Dec 2, 2020 at 11:27 AM Klevenz, Stephan <stephan.klevenz@...> wrote:
- Peter Burkholder | cloud.gov compliance & security please use cloud-gov-compliance@... for cloud.gov matters
|
|
|
|
Thanks Stephan for this proposal. I'm concerned that adding new roles will further increase complexity and degrade UX. This will likely increase the current feeling of combinatorial explosion when reading the role reference table [1]. I've contributed detailed comments in the documents to proceed as a community with analysing related use-cases and try to converge to a better proposal from the UX perspective. Hope this helps, Guillaume. On Wed, Dec 2, 2020 at 5:26 PM Klevenz, Stephan <stephan.klevenz@...> wrote:
|
|
|
