Mike:

If this service were to be shared I would need to instead listen on bind

get the application the service is being bound to and add an ASG to that
space. Then on unbind I'd need to see if all the applications in the space
with the binding are unbound from the service and remove the ASG or to
cleanup I'd need to continually scan the CC to see if there are any spaces
with this ASG without an instance of the service and clean it up. Not
impossible but a pain for a service that I might not be worth the effort
enable sharing on.

this is what we have implemented into sec-group-broker-filter[0]

Matt:

Some feedback: this feature seems pretty useful to us. We'll have to make
some adaptations to our broker before enabling it:

The current service plan visibility feature [1] would be affected by CF
instances that enable the service sharing feature. Up to now, admins were
controlling visibility of service plans (when disabling the space-scoped
service broker flag). With the service sharing feature turned on, a space
developper granted visibility into a service plan will be able to
transitively share it with other orgs.

We have multiple use-cases for the service plan visibility feature at
orange:
a- restrict service offering whose service instances imply large/costly
amount of resources.
b- restrict service offering whose service instances provide access to
confidential data. For example, a vault service offering for org1 should
not be shared to org2.
c- restrict service offerings to apply corporate security policies. For
example, orgs that have access to public internet domains for inbound
traffic are not granted outbound intranet access through the associated
service plan not being visible in these orgs

Service instance sharing is fine for a), but more problematic for b) or c).

However, most of our service brokers are proxied with our
sec-group-broker-filter [0] which could be enhanced to opt-out service
instances shared among orgs [3]. So our admins should be able to enable the
service sharing flag, and still be able to reject binding of shared service
instances on some service plans.

And some questions:

Q1: Would the service instance feature also enable sharing of service
instances instanciated from space-scoped service brokers ?

Q2: Is it planned that specific audit events be available in both the
originating and target spaces as to be able to trace the "actor" of the
sharing/unsharing/create-binding/delete-binding operations ?

Q3: Is is planned that space developers listing service instances in their
space will be able to clearly identify the ones they own from the ones that
are shared to them ?

If not, one could also imagine an edge case, where a malicious space
developer who gained a list of org/spaces of a public CF instance would try
to perform some phishing on target orgs/spaces by sharing a malicious route
service instance (possibly named close to a common service such as "akamai"
or "cloudflare"), and hope to sniff some app traffic.

[0] https://github.com/orange-cloudfoundry/sec-group-broker-filter
[1] http://docs.cloudfoundry.org/services/access-control.html
[2] http://docs.cloudfoundry.org/services/managing-service-brokers.html
[3] https://github.com/orange-cloudfoundry/sec-group-broker-filter/issues/49

Thanks,

Guillaume.

On Mon, Aug 28, 2017 at 11:39 AM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

Peter: The org and space GUIDs will be sent to brokers in the bind request
using the same context object that is sent when provisioning a service
instance (this work is underway now). Good spot though!

Mike: Thanks for explaining how your brokers would need modifications for
sharing to work as desired. I'll investigate how we can allow brokers to
explicitly opt in to sharing (either via the requires field or some other
mechanism). I'll also look into a workflow where a space developer who has
an instance shared into their space can trigger an I share/remove. Thanks
for the great feedback!


On Mon, 28 Aug 2017 at 07:27, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hi,

So far it was safe to assume that a service instance and bound
applications are in the same space. If a service instance is shared across
args/spaces, this is no longer true.
Currently a service broker does not receive *organization_guid* and
*space_guid* in Bind
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.md#binding>
operation. It receives only the *app_guid*. CC sends *organizarion_guid*
and *space_guid* only in Provision
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.md#provisioning>
operation.
So, unless the service broker API is extended, there will be no easy way
for the broker to get this data.

Best regards,
Petar


On Mon, Aug 28, 2017 at 12:19 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

That said, this isn't a big deal. if it were a difficult thing for the
platform to allow a broker to opt out of sharing then I would say forget
about it. I'm only thinking that since the platform already has a
mechanism seemingly purpose built for this type of scenario (requires
permissions) why not be on the safe side and take the simple step of
utilizing that solution to help alleviate the issues this feature may
present to a small number of brokers?

Again, if adding a simple broker permission introduces some complexity
I'm not seeing then go ahead and drop the whole idea. I don't want this
feedback to derail the momentum in place to get shared services
implemented. This is too important of a feature to have delayed because of
feedback as minor as this.

Mike

On Sun, Aug 27, 2017 at 3:07 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

Could you share more on the service you have developed that will not
work if bound to from another org/space?

What extra information would it need to function correctly?

Good point. I should have clarified I have services today that won't
function *without modification*. That said, the modification in some
cases wouldn't be pretty. For example, I have a broker that today on
provision grants an ASG to the space the service is provisioned and removes
the ASG on deprovision. If this service were to be shared I would need to
instead listen on bind get the application the service is being bound to
and add an ASG to that space. Then on unbind I'd need to see if all the
applications in the space with the binding are unbound from the service and
remove the ASG or to cleanup I'd need to continually scan the CC to see if
there are any spaces with this ASG without an instance of the service and
clean it up. Not impossible but a pain for a service that I might not be
worth the effort enable sharing on.

I don't have this situation yet, but, this it is an idea my group has
had in the past. We've considered using unbindable services as a way to
add meta data like billing or CI information to a space. This might not be
a service we'd want shared because the meta data might be specific to the
space it was created in. With such a service we would probably have
validation logic in place to allow only one instance of this service to be
provisioned per space. The ability to share this service would circumvent
this validation logic and perhaps break the components that operate on this
service.

There may be other services who cannot have admin access to the CC.
These brokers might utilize the space guid in some way such as ensuring the
space is authorized to create instances of this service in some billing
system, for example, because this service hasn't been trusted with admin
access to the CC it would have no way to know that another space is also
using the service. This information might be significant to the billing
model of the service.

Adding service broker lifecycle events to notify a broker of sharing
and unsharing might help these types of use cases to be handled by a
broker. But, I think that would not be something prudent to attempt to
tackled for this initial release.

Since the service broker api is one of the few open/stable extension
points on the cloud controller you might be surprised at some of the the
odd things customers have done with custom service brokers. It seems to me
that instead of requiring all services to support sharing it would be
prudent to allow services to opt out (or in) to this new feature.

Thanks,
Mike

On 25 August 2017 at 17:08, Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks for the response! See comments inline:

On Fri, Aug 25, 2017 at 8:48 AM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

Thanks for the feedback Mike, and great questions! We're currently
working off slightly different assumptions, but are working through these
to validate that they are the expected behaviour for the majority of users:

* Space developers in the 'owning' space (this is the way we've
thought about this too!) *would *be able to delete or unshare a
shared service instance with bindings, but they would get a warning in the
CLI warning them that this will automatically delete bindings in other
spaces.

Interesting. That behavior is different for bindings in the owning
space. Today if a space developer wishes to delete a service in its owning
space, that is bound to applications, the operation will fail until that
service is unbound. I wonder if the CAPI or CLI team would consider
changing that behavior so that the functionality is equivalent between
shared and not shared services?

If the space developer in the owning space attempts to delete a
service and the unbind fails in a shared space then I assume the delete
service request will also fail correct?

* Space developers can only bind and unbind to service instances that

have been shared into their space. In this first version they wouldn't be
able to remove the service instance from appearing in their space without
asking the sharer to unshare it.

If the org manager of an org who has a space with a shared service in
it wishes to delete the space a service is shared in, then I assume that
would succeed without the owning space developer first unsharing the
service correct? If so it seems kind of strange they can unshare the
service by deleting the space but not by simply unsharing it individually.
Why not let the space developer of a space a service is shared into let
that space developer unshare the service? Is there some hidden complexity
I'm missing?

* We've investigated a number of sharing permission models, including

how both CF admins and service broker authors want to control this. Initial
feedback has suggested that for most use cases, service brokers shouldn't
care where the binding is coming from (it looks the same to them). There
are edge cases here with things like ASGs though which we will need to
consider.

IMO as a broker developer of services that will not function if
shared, I would really like a permission for the broker to opt in/out of
services of it's type being shared. I'd hate for my users to start sharing
services that don't support sharing and then be confused as to why the
shared service doesn't work. Granted I know there is the global flag that
can turn it all off. But, I have some services that may technically never
be able to be shared. I don't think a simple "requires" permission (
https://github.com/openservicebrokerapi/
servicebroker/blob/v2.12/spec.md#catalog-management) is too much to
ask. Unless there is some complexity I'm not seeing?


Thanks,
Mike