service binding with profile

[nicola...@gmail.com]

Hi all

Backgroud
Many inhouse and customer development teams have production apps installed on premise and want to migrate to our Cloud Foundry offering.
They run databases accessed by several apps or clients with different users having appropriate user rights on the database.
If keeping different level of access rights is a hard requirement, the only solution we are currently able to offer them is user-provided services.
In many cases, however, this is not an option as the app cloud networks are in zones which are stricly separated from the zone where they currently store their data, so no db connection possible.

Discussion and Suggestion
We had some discussions about the way the service binding is currently done in Cloud Foundry using service broker v2 specifications. We think this solution overall covers 80% of the requirements.
An additional 15% could be covered if we we able to offer three categories of service bindings (let me call them profiles): "admin" (x), "read/write" (w), "read only" (r).
The names are meant as suggestions, they are taken from UNIX file system rwx attributes.

USAGE:
   gcf bind-service APP SERVICE_INSTANCE [PROFILE]

The v2 Service Broker would then be called with the profile value as additional parameter.
It would provide credentials for a service connection with the appropriate rights/grants on the service instance.
For example:
  admin (x): all grants
  read/write (w): CRUD
  read only (r): only SELECT

Any comments on this topic would be very welcome. Also welcome any ideas how to solve the mentioned requirements taking any other approach.

Thanks!
Nic

[James Bayer]

nic,

it seems that there are multiple issues in-play here:

1) restricted network access to connect to particular data services from DEAs

2) you would like credentials provided by services to be scoped to appropriate permission levels that can vary by situation

these issues should be able to be addressed separately from what i can tell. any reason they can't be?

for 1), the placement pools concept [1] will hopefully allow groups of DEAs to be associated with particular org/spaces such that those DEAs will be assured to only run apps that should have network access to a particular data service using a firewall, vLAN, etc. that work has not been implemented yet.

for 2) i'd like to hear shannon's thoughts, but i'm unclear why using multiple user-provided services to the same database, but just with different permissions levels will not work. eg. my-db-admin, my-db-rw, my-db-ro and just binding the appropriate service instance to the app. you could even separate the apps into different spaces using this approach. we have had requests for additional specific and opaque options to services. i believe shannon is trying to find an approach that covers as many use cases as possible before introducing an API that will hopefully live a long time.

[1] https://docs.google.com/a/gopivotal.com/document/d/1S1J9zsGr-01MxGM01iRg2FphRFYaYZpAM30VObmh2Us/edit#

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

--

Thank you,

James Bayer

[Shannon Coen]

I agree with James, it's not clear to me why user-provided services wouldn't solve this use case now. A DBA could create a user with read-only permissions and gives those creds to a developer who creates a user-provided service instance and gives it a meaningful name. The DBA could create a second user with read/write privs and gives those creds to a developer who creates another user provided service instance. 

Longer term, we've been planning to solve this use case with a feature we're calling 'arbitrary provision and bind parameters'. In this way a developer could pass parameters with the bind operation that the service broker interprets as requesting a user with appropriate permissions. So if your service broker wants to use profiles, then the developer would run:

$ cf bind-service myapp mydb -p '{"profile":"x"}'

Another service which wants to be more explicit might support the following command:

$ cf bind-service myapp mydb -p '{"read":true, "write":false}'

 

The point is that Cloud Foundry doesn't need to know the meaning of these parameters, or be prescriptive about their implementation, thus supporting an infinite number of options broker authors would like to support.

Thank you,

Shannon

[nicola...@gmail.com]

James, Shannon.

Many thanks for your insightful replies.

I agree there are two separate topics in my post. The relationship between the two I missed to mention in my initial post: We are going to provide on-demand services of relational database systems. If we were able to supply service-bindings with profiles, then the teams would be willing to abandon their on premise dbs in favor of our offering.

Shannon, this is awesome news and fulfills our requirements fully. Additionally, in my opinion, it is a smart approach, I like it!
Is "-p" on the roadmap, by when?

Best regards,
Nic

[Shannon Coen]

Hello Nic,

It is on the roadmap, but I don't have a timeline for it. Within the next six months is the best I can do. I will make a note that you have requested it, though. This does help with my prioritization.

Best,

Shannon

Shannon Coen

Product Manager, Cloud Foundry

Pivotal, Inc.

mobile: 415.640.0272

skype: shannoncoen