1. Messages
  2. Do your service brokers leverage the Org and Space fields in the broker API?

Re: Do your service brokers leverage the Org and Space fields in the broker API?

Guillaume Berche
 

We also use the org and space guids in some brokers:

1- In autosleep [1], as to opt in for space level features (as an
alternative to the usual app or route level opt-in provided through current
binding process).
2- In sec-group-broker-filter [2] to dynamically open security groups in
the associated space in order to allow consumption of the returned
credentials by the broker.
3- In db-dumper-service [3], as a work around the lack of authentication
support in the current service broker API: from the space_id field securely
provided by the CC we infer the requester as SpaceDeveloper permission on
the space, and hence is allowed to access other services in that same
space, in this particular example to dump them.

Use-cases 1) and 2) are pretty specific to CF and would be hard to provide
in a portable way to other platform such as K8S, so preserving the
organization_guid and space_guid fields as CF-specific extensions is useful
and important to us. This is a better alternative than an opaque platform
independent string that could be a normalized low denominator: we would not
be able to trust its semantics (i.e. that CC is indeed garanteeing that
request originated from this space and org guids).

Use-case #3 might be more generic: authenticating users both in dashboards
and in [un]provision/[un]bind/update request could be made generic and
enable brokers to interact with users from multiple platforms in the same
way. I hope we can resume the related proposals discussions initiated at
https://docs.google.com/document/d/1DoAbJa_YiGIJbOZ_zPzakh7sc4TB9Tmadq41cfSX0dw/edit?usp=sharing
as part of the Open Service Broker API work and find ways to make it
applicable to other platforms (e.g. leveraging openId connect protocol)

[1] https://github.com/cloudfoundry-community/autosleep
[2] https://github.com/orange-cloudfoundry/sec-group-broker-filter
[3] https://github.com/orange-cloudfoundry/db-dumper-service


Guillaume.

On Fri, Nov 4, 2016 at 1:25 AM, Dubois, Jan <jan.dubois(a)hpe.com> wrote:

We also use these fields in a credentials broker that hands out separate
credentials in test vs. production spaces. It Is a somewhat specialized use
case, where credentials must not be written to disk or passed in env
variables and even should not be easily accessible to admins either (ssh is
disabled in the prod spaces).



Therefore we would favor keeping these values around in an optional,
platform-specific mapping as well.



Cheers,

-Jan



*From: *Mike Youngstrom <youngm(a)gmail.com>
*Reply-To: *"Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
*Date: *Thursday, November 3, 2016 at 1:17
*To: *"Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
*Subject: *[cf-dev] Re: Do your service brokers leverage the Org and
Space fields in the broker API?



We used them in a bunch of insignificant places and in one significant
place.



Our significant use case is that we have a billing system that associates
internal billing codes with organizations and spaces. When a service is
provisioned we lookup the billing code for a space or org and pass that
along to the third party system we are provisioning the service on.



We could probably rework how this system functions but it would take some
effort and would probably require our thirdparties to change their
provisioning request process to allow us to either update the billing token
outside of the provision request or impact our users by making them provide
a billing code as a service parameter in their provision request. Nothing
insurmountable but would be annoying.



I'm assuming the service guid isn't queryable against the CC until a
provision request is successful?



Perhaps these fields can be moved to a platform specific map of values in
the request? This would at least make it more obvious to broker developers
that if a broker needs to use these fields the broker may not work on other
platforms?



Mike



On Thu, Nov 3, 2016 at 12:23 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

The Open Service Broker API working group is exploring removal of
"CF-isms" from the CF broker API to support adoption of the broker API by
other platforms (e.g. Kubernetes). Our hope is that support from other
platform marketplaces will make implementation of the broker API more
compelling for service providers, as it would enable multiple sales
channels, growing the ecosystem of services available to CF operators.



The organization_guid and space_guid fields are sent to brokers with the
create and update operations. Please let me know if you are aware of
service brokers that leverage these fields, and for what purpose.



Thank you!


Shannon Coen

Product Manager, Cloud Foundry

Pivotal, Inc.


?
attachment.html

Join {cf-dev@lists.cloudfoundry.org to automatically receive all group messages.