A proposal for new default user roles

[Scott Truitt]

Hi all,

I put together a proposal for new default user roles in Cloud Foundry. This document [1] details the goals / non-goal of the proposal and this spreadsheet [2] maps the roles to current functionality. Long story short, I'm looking to greatly simplify what is now a confusing mess.

Note that none of this work is currently scheduled or even prioritized. 

Looking forward to your feedback. 

Scott

[1] https://docs.google.com/a/gopivotal.com/document/d/1C8maLOAXYIbCrxY4zoPjgifoE1CPZsyN4ey8W-VERwA

[2] https://docs.google.com/a/gopivotal.com/spreadsheet/ccc?key=0AgPnby2s20OGdHZIMzZweTZmV2NtOGJSdHhwVW5RZWc

[Ken Ojiri]

Very good proposal. Thank you, Scott!
I also have been confused about user roles in CFv2.

I added some comments about 'create-user' privelege on google docs.

Ken @NTT


2014年3月28日金曜日 8時35分29秒 UTC+9 Scott Truitt:

[Mike Youngstrom]

Looks good Scott.  Though I don't have a big issue with the current user roles.  I do have issue with bugs and apparent lack of consistency in the current roles.  So, if redefining the roles helps to fix and provides a test suite for the roles in the cloud controller then I'm all for it. :)

I cannot comment on the document so here are some thoughts:

* Have you considered just making Org Owner a space manager of all spaces in the org also?  It seems a bit odd that you would require the org owner to give himself Space Developer or Manager access to do stuff in a space.  This could also simplify access for simple orgs where one or two person just do everything.  Wouldn't the justification to merge Space manager and space developer apply to Org Owner as well?

* I would like special rules for service binding credentials.  At the very least service binding credentials shouldn't be accessible to Org or Space Viewers from the UI or a CC service invocation.  But, the Space Viewer should have access to apps and what services are bound to that app. https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/W_0jaAJV2j0/m5BndGPl8SoJ

* Any particular reason why a space viewer cannot see files?  I can see a reason to remove file access if env.log exists.  But I'd like to see env.log go away.  If env.log goes away is there a reason to restrict "files" access?

* It would be nice if a Space Viewer could see "env" but not env values.

* Should Org members be able to see all quotas?  Or just the one currently assigned to them?

Thanks,

Mike

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

[Scott Truitt]

Thanks, Mike. Great questions as always. Answers inline.

On Fri, Mar 28, 2014 at 9:29 AM, Mike Youngstrom <you...@gmail.com> wrote:

Looks good Scott.  Though I don't have a big issue with the current user roles.  I do have issue with bugs and apparent lack of consistency in the current roles.  So, if redefining the roles helps to fix and provides a test suite for the roles in the cloud controller then I'm all for it. :)

I cannot comment on the document so here are some thoughts:

I just checked again that the sharing settings allow anyone with the link to comment. lmk if you're still having trouble. 

 

* Have you considered just making Org Owner a space manager of all spaces in the org also?  It seems a bit odd that you would require the org owner to give himself Space Developer or Manager access to do stuff in a space.  This could also simplify access for simple orgs where one or two person just do everything.  Wouldn't the justification to merge Space manager and space developer apply to Org Owner as well?

I hadn't considered that, Mike, but I can see the rationale. It does go against my goal of differentiating orgs and spaces. Perhaps I pushed the 'manager' metaphor to far on the Org Manager role... 

There is a certain symmetry in saying that Org Owner is also a Space Owner in all spaces, and likewise, Org Viewer is also a Space Viewer in all spaces. Anyone object to that? 

 

* I would like special rules for service binding credentials.  At the very least service binding credentials shouldn't be accessible to Org or Space Viewers from the UI or a CC service invocation.  But, the Space Viewer should have access to apps and what services are bound to that app. https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/W_0jaAJV2j0/m5BndGPl8SoJ

There's definitely a level of detail missing in the spreadsheet. A Space Viewer should be able to 'see' high-level details about apps and services, but nothing sensitive like credentials and env values (to your point below). That would solve your issue here, correct? 

 

* Any particular reason why a space viewer cannot see files?  I can see a reason to remove file access if env.log exists.  But I'd like to see env.log go away.  If env.log goes away is there a reason to restrict "files" access?

Makes sense. I added files to the Space Viewer role. 

 

* It would be nice if a Space Viewer could see "env" but not env values.

Yes.  

 

* Should Org members be able to see all quotas?  Or just the one currently assigned to them?

Hmm, I can't think of a reason why not. Anyone object to that? 

[James Bayer]

* Should Org members be able to see all quotas?  Or just the one currently assigned to them?

Hmm, I can't think of a reason why not. Anyone object to that? 

the api endpoint for all quotas is currently open to any user with a valid OAuth token. the only reason i can think of to not have it open is that you may not want some depts to get jealous of another depts quota. that's really stretching things in my view. seems fine to keep it open.

$ cf curl /v2/quota_definitions
{
  "total_results": 6,
  "total_pages": 1,
  "prev_url": null,
  "next_url": null,
  "resources": [
    {
      "metadata": {
        "guid": "8c4b4554-b43b-4673-ac93-3fc232896f0b",
        "url": "/v2/quota_definitions/8c4b4554-b43b-4673-ac93-3fc232896f0b",
        "created_at": "2013-11-19T18:53:48+00:00",
        "updated_at": "2013-11-19T19:34:57+00:00"
      },
      "entity": {
        "name": "free",
        "non_basic_services_allowed": false,
        "total_services": 0,
        "total_routes": 1000,
        "memory_limit": 0,
        "trial_db_allowed": false
      }
    },
    {
      "metadata": {
        "guid": "7dbdcbb7-edb6-4246-a217-2031a75388f7",
        "url": "/v2/quota_definitions/7dbdcbb7-edb6-4246-a217-2031a75388f7",
        "created_at": "2013-11-19T18:53:48+00:00",
        "updated_at": "2013-11-19T19:34:57+00:00"
      },
      "entity": {
        "name": "paid",
        "non_basic_services_allowed": true,
        "total_services": -1,
        "total_routes": 1000,
        "memory_limit": 10240,
        "trial_db_allowed": false
      }
    },
    {
      "metadata": {
        "guid": "2228e712-7b0c-4b65-899c-0fc599063e35",
        "url": "/v2/quota_definitions/2228e712-7b0c-4b65-899c-0fc599063e35",
        "created_at": "2013-11-19T18:53:48+00:00",
        "updated_at": "2014-01-13T18:25:49+00:00"
      },
      "entity": {
        "name": "runaway",
        "non_basic_services_allowed": true,
        "total_services": -1,
        "total_routes": 1000,
        "memory_limit": 153600,
        "trial_db_allowed": false
      }
    },
    {
      "metadata": {
        "guid": "b72b1acb-ff4f-468d-99c0-05cd91012b62",
        "url": "/v2/quota_definitions/b72b1acb-ff4f-468d-99c0-05cd91012b62",
        "created_at": "2013-11-19T18:53:48+00:00",
        "updated_at": "2013-11-19T19:34:57+00:00"
      },
      "entity": {
        "name": "trial",
        "non_basic_services_allowed": false,
        "total_services": 10,
        "total_routes": 1000,
        "memory_limit": 2048,
        "trial_db_allowed": false
      }
    },
    {
      "metadata": {
        "guid": "39d630ba-66d6-4f6d-ba4e-8d45a05e99c4",
        "url": "/v2/quota_definitions/39d630ba-66d6-4f6d-ba4e-8d45a05e99c4",
        "created_at": "2014-01-23T20:03:27+00:00",
        "updated_at": null
      },
      "entity": {
        "name": "25GB",
        "non_basic_services_allowed": true,
        "total_services": -1,
        "total_routes": 1000,
        "memory_limit": 25600,
        "trial_db_allowed": false
      }
    },
    {
      "metadata": {
        "guid": "81226624-9e5a-4616-9b9c-6ab14aac2a03",
        "url": "/v2/quota_definitions/81226624-9e5a-4616-9b9c-6ab14aac2a03",
        "created_at": "2014-03-11T00:13:21+00:00",
        "updated_at": "2014-03-19T17:36:32+00:00"
      },
      "entity": {
        "name": "25GB:30free",
        "non_basic_services_allowed": false,
        "total_services": 30,
        "total_routes": 1000,
        "memory_limit": 25600,
        "trial_db_allowed": false
      }
    }
  ]
}

--

Thank you,

James Bayer

[Mike Youngstrom]

I just checked again that the sharing settings allow anyone with the link to comment. lmk if you're still having trouble. 

It appears I can comment in the Document but not in the matrix where I was trying to comment.  Sorry.  Any comments beyond the ones I put here I"ll add to the document.

 

There is a certain symmetry in saying that Org Owner is also a Space Owner in all spaces, and likewise, Org Viewer is also a Space Viewer in all spaces. Anyone object to that? 

I was only considering making the Org Owner == space managers.  Since the org owner can make themselves space managers of any space they want it could eliminate some unnecessary effort to simply give them the same power as space managers.  I don't feel as strongly about Org Viewers == space viewers but I'm not necessarily against it.

There's definitely a level of detail missing in the spreadsheet. A Space Viewer should be able to 'see' high-level details about apps and services, but nothing sensitive like credentials and env values (to your point below). That would solve your issue here, correct? 

Correct.  I think in our org we'd like to use the space viewer role as a role people can use to diagnose and troubleshoot issues but not be able to break anything or see anything sensitive.  So, if we can get that fine grained in the data the CC returns then that would work for me.

 

Thanks,

Mike

[Mike Youngstrom]

Yeah, I guess a quota doesn't really tell anyone how much someone is actually using the service or how much they are paying for it.  Organizations pay us up front for a larger quota since we don't have a good charge back model yet.  So, being able to see other quotas let other orgs see how much space on the cloud they are paying for in relation to each other.  This isn't a big deal in a private deployment like ours.  But if a public deployment wished to govern things in a similar manner it could be problematic.

Not a big deal at all.  Just a thought.

Thanks,

Mike

[Daniel Grippi]

This is great, Scott!  Hierarchy would be an awesome step forward.

Daniel

[Aristoteles Neto]

On 30/03/2014, at 6:42 pm, Scott Truitt <str...@gopivotal.com> wrote:

* Have you considered just making Org Owner a space manager of all spaces in the org also?  It seems a bit odd that you would require the org owner to give himself Space Developer or Manager access to do stuff in a space.  This could also simplify access for simple orgs where one or two person just do everything.  Wouldn't the justification to merge Space manager and space developer apply to Org Owner as well?

I hadn't considered that, Mike, but I can see the rationale. It does go against my goal of differentiating orgs and spaces. Perhaps I pushed the 'manager' metaphor to far on the Org Manager role... 

There is a certain symmetry in saying that Org Owner is also a Space Owner in all spaces, and likewise, Org Viewer is also a Space Viewer in all spaces. Anyone object to that? 

From what I understood you Scott, they would still be two distinct roles, but Org Owners would imply Space Owners (on all spaces) and that means a user can still be given solely Space Owner on a single space (without having the ability to create other spaces) - correct?

The original Org Manager role allowed for an “administration” person to be assigned a somewhat high level role, which allowed them to manage the organisation (billing, users, etc), without having access to the Apps… I can still imagine that being needed across enterprises…

* Any particular reason why a space viewer cannot see files?  I can see a reason to remove file access if env.log exists.  But I'd like to see env.log go away.  If env.log goes away is there a reason to restrict "files" access?

Makes sense. I added files to the Space Viewer role. 

Does that mean file contents as well? Certain files may contain sensitive information.

* Should Org members be able to see all quotas?  Or just the one currently assigned to them?

Hmm, I can't think of a reason why not. Anyone object to that? 

Personally, I can imagine a scenario where ’special quotas’ have been created and applied to specific Orgs, that isn’t publicly available - having them visible could be problematic.

I think the more useful information for an Org (member or otherwise), would be to see things like which quota is assigned to the Org, and how much of it is used up, or being able to set their own quotas.

But I understand thats beyond the scope of this conversation.

-- Neto

[Scott Truitt]

On Sun, Mar 30, 2014 at 2:36 PM, Aristoteles Neto <aristote...@webdrive.co.nz> wrote:

On 30/03/2014, at 6:42 pm, Scott Truitt <str...@gopivotal.com> wrote:

* Have you considered just making Org Owner a space manager of all spaces in the org also?  It seems a bit odd that you would require the org owner to give himself Space Developer or Manager access to do stuff in a space.  This could also simplify access for simple orgs where one or two person just do everything.  Wouldn't the justification to merge Space manager and space developer apply to Org Owner as well?

I hadn't considered that, Mike, but I can see the rationale. It does go against my goal of differentiating orgs and spaces. Perhaps I pushed the 'manager' metaphor to far on the Org Manager role... 

There is a certain symmetry in saying that Org Owner is also a Space Owner in all spaces, and likewise, Org Viewer is also a Space Viewer in all spaces. Anyone object to that? 

From what I understood you Scott, they would still be two distinct roles, but Org Owners would imply Space Owners (on all spaces) and that means a user can still be given solely Space Owner on a single space (without having the ability to create other spaces) - correct?

The original Org Manager role allowed for an “administration” person to be assigned a somewhat high level role, which allowed them to manage the organisation (billing, users, etc), without having access to the Apps… I can still imagine that being needed across enterprises…

You're right, Neto. This was my original rationale for keeping them separate. I can see value in each approach depending on the context. In Mike's small team example, it makes sense to view them as one role. In your enterprise example, it makes sense to view them as two roles. Perhaps it's best to make them two distinct roles...? 

 

* Any particular reason why a space viewer cannot see files?  I can see a reason to remove file access if env.log exists.  But I'd like to see env.log go away.  If env.log goes away is there a reason to restrict "files" access?

Makes sense. I added files to the Space Viewer role. 

Does that mean file contents as well? Certain files may contain sensitive information.

Mike's stipulation is that a Space Viewer can only access files and env variables with all of the sensitive information omitted. I know that doesn't show up on the spreadsheet. 

 

* Should Org members be able to see all quotas?  Or just the one currently assigned to them?

Hmm, I can't think of a reason why not. Anyone object to that? 

Personally, I can imagine a scenario where ’special quotas’ have been created and applied to specific Orgs, that isn’t publicly available - having them visible could be problematic.

I think the more useful information for an Org (member or otherwise), would be to see things like which quota is assigned to the Org, and how much of it is used up, or being able to set their own quotas.

But I understand thats beyond the scope of this conversation.

An excellent feature request though! We'll be working on quota crud in the not-too-distant future. 

 

-- Neto

[Mike Youngstrom]

The original Org Manager role allowed for an “administration” person to be assigned a somewhat high level role, which allowed them to manage the organisation (billing, users, etc), without having access to the Apps… I can still imagine that being needed across enterprises…

 

Can you help me understand the value of an "administration" only role if this person has the ability to assign themselves as a space manager?  It wouldn't really be for security.  The only value I can think such a role would play is help keep a manager from accidentally breaking something.  Which could be useful I suppose....but lets be upfront about the value before deciding to go down that path.

Are there other reasons why an admin only role would be useful?

Mike

[Aristoteles Neto]

I’d be more than happy with a superadmin-style role myself, however I wouldn’t restrict it to the only possible role due to other possible use cases. I know this is outside scope, but I think the ideal would be a default superadmin account, with ACL-style permissions, allowing the superadmin to customise his own roles for his own needs (for example, creating a role and allowing a person to only view+billing, or another person to user management, etc). Even in that case, though, I’d still create default roles - to avoid the complexity that is AWS IAM :P.

Aristoteles Neto

ne...@orcon.net.nz

[Mike Youngstrom]

Agreed ACL-style permissions would be idea.

[James Bayer]

yes, as covered in the "Non-Goals" section of scott's roles doc we'd like to support CRUD of custom roles that map to fine-grained permissions. the roles could be assigned based on OAuth userid or scopes. the scopes could be derived from another ID source like AD/LDAP groups or OpenStack Keystone info. however that's a much larger effort than incrementally improving the more coarse-grained roles already in-place hence the tighter immediate scoping.

[Aristoteles Neto]

Hi James,

Agreed, which is why I was saying that it would be ideal, but understood it was out of scope - was just trying to exemplify a use case where it would be desirable to have Billing / Manager as separate roles.

What I’d really like, is for OrgManagers to be able to manage their own users, which is addressed by the proposal, so I can’t wait for this to be done :P

-- Neto