Service instance permissions should distinguish between read and write

[svrc]

Issue (Enhancement request)

Many service instance dashboards are available that provide read-only diagnostic / monitoring information that should be made available to SpaceAuditors. Per #405 the current permissioning model is a "true/false" where only SpaceDevelopers have permission to service instances {manage: true}.

Context

Examples of this enhancement in action:

Spring Cloud Services Registry (Eureka) dashboards contain registered services across a peer replicated mesh. For debugging/diagnostic purposes, developers might have SpaceDeveloper Role in their main space but are interoperating with other microservices in other spaces, and should be able to be given SpaceAuditor role in other spaces so they can look at the dashboard of other interoperating peers.

Spring Cloud Services Circuit Breaker (Hystrix/Turbine) dashboards are read-only dashboards that should be made available to a broader group (SpaceAuditors) beyond just SpaceDevelopers.

Pivotal SSO dashboards may declare Oauth resource/scope mappings for microservices that may be browsed by those interoperating with these microservices.

Steps to Reproduce

1. Create a user with SpaceAuditor role only in a space.
2. Create a service instance with an available dashboard
3. Attempt to browse to that dashboard, it will be rejected

Expected result

1. Create a user with SpaceAuditor role only in a space.
2. Create a service instance with an available dashboard
3. Attempt to browse to that dashboard, user should be granted read-only rights

Possible Fix

Introduce a new field to /v2/service_instances/:guid/permissions such as {"read": "true"} that checks for an auditor role and allows newer service instance dashboards to provide a read-only view of their dashboard.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/141794109

The labels on this github issue will be updated when the story is started.

[zrob]

@shalako @avade

Would we consider this to be part of the broker api spec?

[avade]

@zrob No, I think this is a CF permissions issue

@svrc-pivotal when you say "Attempt to browse to that dashboard, it will be rejected", the SSO service is checking against CF's permissions to grant access to the dashboard, correct?

cc. more evidence of permission challenges with the current CF model.

@pivotal-mikegresham
@matthewmcnew

[svrc]

@avade I think any service with a dashboard (MySQL, Rabbit, SCS, SSO) is supposed to call /v2/service_instances/:guid/permissions to grant access to their dashboard, yeah (this happens after authentication via OAuth). So you could test this with any service broker that has a dash.

[zrob]

@avade I guess what I mean is that we specify a broker responsibility to check permissions with cf here

will we have a parallel in the open service broker spec? if so would there be a canonical list of permissions? for example we have manage today, perhaps read in the future.

[zrob]

@svrc-pivotal

I was able to sync up with @avade and we agreed that this is a platform specific behavior outside of the service broker spec.

I propose read would map to the following rolls

• SpaceDeveloper
• SpaceManager
• SpaceAuditor
• OrgManager

Does this meet your expectations?

[svrc]

Yes, that would be great.