Chris;

- We're not yet sure how instances would count towards quotas, but
this is on our list of things we will investigate as we move forward.
- This is true, however our research has shown that this isn't
perceived as a problem. When an intance is shared into a space, running *cf
service xxx* will also show a message saying where the instance was
shared from (in case you need to get in contact with someone from that
other space). Again, we asked a number of CF users about this and they were
happy with this.
*However, if you think this is a problem or have had other feedback
about this please pass it on asap!*
- Another good point, and you're right - we are making it easier for
developers to be malicious here. When we started working on this feature,
we designed a much more explicit permissions system where admins had to
explictly enable sharing of a particular service (and/or plan) from one
space to another. However the feedback on this was that this is overly
restrictive and would be a burden to admins. The solution we have ended up
with for this first version is using a feature flag to enable this in an
environment (i.e. *cf enable-feature-flag service_sharing*).
*Do you think this gives admins enough control, or would you still be
worried about malicious developers sharing instances into your space? Would
you be concerned that developers would accidentally bind to these
instances?*


Sergio;

- The more explicit permissions model we investigated would require
the CF admin to setup sharing rules, rather than OrgManager's. So in your
example, the Org1 and Org2 managers would have to go to their admin
together with an agreement to ask for the sharing rule to be put in place.
As for costings, we were hoping to leave this up to organisations to handle
internally. *Do you see this being an issue for any users you know
about?*
- We want to empower developers to manage their service instances as
much as possible. We already allow them to create services on-demand via *cf
create-service*, and the feedback we have supports our desire to
further empower developers to be as self-service as possible. However, due
to the cost implications you raise, we agree that admins need some level of
control over this, and so we are planning on enhancing the permissions
model following this first version.


Thanks all.

On Wed, Aug 30, 2017 at 7:14 AM Rozenszajn, Sergio <
sergio.rozenszajn(a)sap.com> wrote:

Hi all,



Good proposal, it rises some questions:

- Org1 probably pays money for the service and when sharing the
service to Org2 the payment should be shared as well à how can this
be structured?
- You say: " To manage any security concerns around this, a CF admin
would have to enable one-way sharing between two spaces" à I see it
more like: Org2 admin says to Org1 admin: "I'm interested in using service
ABC (and I'm ready to pay my part for it)". If they both agree, Org2 admin
enables sharing from Org1 to Org2. After that Org1 admin (or a Org1
developer) shares Org1 service instance to Org2.
- à I believe that sharing services can be done by a developer but it
is actually an admin decision due to the costs impact



Sergio



*From:* Christopher Brown [mailto:cbrown(a)pivotal.io]
*Sent:* יום ג 29 אוגוסט 2017 20:22
*To:* Discussions about Cloud Foundry projects and the system overall. <
cf-dev(a)lists.cloudfoundry.org>
*Subject:* [cf-dev] Re: [Proposal] Sharing service instances across orgs
and spaces



Hi there,



Interesting proposal, thank you for suggesting it! I have a few questions
around some of the practicalities:

- How would shared services count towards the service instance quotas
in the respective spaces?
- Does the ability to share a service into a space that you do not
have access to cause a sensitive information leak? e.g. I can try and share
a service into organizations and spaces until it is successful which
confirms the existence of that organization, space, and possibly service
name.
- Does the ability to share a service into a space that you do not
have access to open developers up to abuse where someone else shares
malicious services into their spaces?

At the risk of the configuration becoming tedious: perhaps space
developers should be able to configure where they can accept service
sharing requests from?



Christopher



On Thu, Jun 29, 2017 at 6:35 AM, Matthew McNeeney <mmcneeney(a)pivotal.io>
wrote:

Many Cloud Foundry users have expressed a desire to share service
instances across orgs and spaces. Whilst this could be considered an
anti-pattern for some data services, there are many use cases for which the
ability to do this is important. Two examples are sharing config servers
and messaging queues.



The workarounds that exist today (e.g. creating user-provided services)
require credentials to be passed around in some out-of-band way and will
prevent the platform from being able to do things like automatic rotation
of credentials in the future.



We'd like to propose a new workflow that looks like this:



$ cf share-service SERVICE_INSTANCE TARGET_ORG TARGET_SPACE



A SpaceDeveloper in the target org/space will only be able to bind/unbind
to/from the shared service instance, and running cf service will show
that the service instance has been shared.



To manage any security concerns around this, a CF admin would have to
enable one-way sharing between two spaces with a command like:



$ cf enable-service-sharing SERVICE SOURCE_ORG SOURCE_SPACE TARGET_ORG
TARGET_SPACE





We'd love to hear feedback from the community on this proposal. If you
have any other use cases that this could help with, please let us know
about those too.



Matt

Regarding the unsharing workflow, the app developers we've spoken to

suggested that they would be frustrated if they were not able to unshare or
delete a service instance that they had created. When deleting a service
instance that has bindings in the same space, the *delete-service *command
fails and shows an error stating the service instance has bindings. A
developer can then, if they want to, unbind any applications and then retry
the delete i.e. they are enabled to delete the service instance at any
time; they may just have to run some other commands first. When the service
instance has bindings from another space, that they may or may not have
access to, we'd like to still fully empower developers in the 'owning'
space, and ensure they are never blocked by having to run a command in a
space that they cannot access. (This same logic would apply for deleting a
service instance that has bindings in a shared space).

Does that logic make sense? What are your thoughts on this?

I think the logic of auto-unbinding the service makes sense as long as the
user doing the delete has a way to know that other applications
(potentially in other spaces) are bound to the service and acknowledge that
they wanted to unbind and delete anyway. However, to help even out the
workflow for both shared and unshared services I would recommend having the
CLI team look into changing the current behavior for local service
bindings to match that of shared service binding. That change would be, if
I attempt to delete a service that has local and/or shared service bindings
then the user should be notified of those bindings and confirm the desire
to unbind and delete the service instance anyway.

All that above assumes all unbind requests succeed. Today if an unbind
fails for a local service bound to a local application then the user is
unable to delete that service until the unbind can succeed or they ask an
administrator to "purge" the service instance. I think the behavior should
be the same for a shared service instance binding. If a shared unbind
fails then the service should not be allowed to be deleted until that
unbind succeeds. Unless an administrator purges the service instance.

Thoughts?

Mike

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!

Thanks Matt. It also helps to know that bind will include space and org
guid. Any thoughts on my other comments? For your convenience I've pasted
them below.

Mike


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?

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

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

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

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