Great! I just thought of some questions and didn't see them listed in the
thread.

* I assume that the space that originally created the service would be a
kind of "owning" space right? So that space probably wouldn't be able to
delete the service unless it was unbound from other space's apps? Would
the service also need to be unshared before deleted?
* I assume a target space developer can unshare a service shared in their
space but not delete, right?
* Is it possible for a service to opt out or in of being shared perhaps
with a CF specific "requires" service permission? I'm thinking of Vivek
Anand's question about. If on create a service adds a security group to
the space creating it the broker would need to be changed to support
sharing.
* Does a space developer wishing to share a service need to be a space
developer in the space they are sharing into?

Great work keeping this much needed feature moving along!

Mike


On Thu, Aug 24, 2017 at 12:25 PM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

Hi all,

I'm pleased to say that work will shortly be starting on the following
sharing service instances workflows:

$ cf share-service SERVICE_INSTANCE TARGET_ORG TARGET_SPACE
$ cf unshare-service SERVICE_INSTANCE TARGET_ORG TARGET_SPACE

We will feature flag this work so that this can be enabled or disabled in
a Cloud Foundry deployment. Note that a key change from the workflows we
initially shared is that this feature will now be enabled/disabled for *all
services and service plans in a deployment*. The more explicit *enable-service-sharing
*workflows we initially proposed will likely be developed in a future
version of this feature. This stripped back permissions model will mean
that a Space Developer will be able to share a service instance in their
space into any other org and space.

Please let me know if anyone has any further thoughts on this. Your
feedback is always very much appreciated.

Many thanks,
Matt

On Mon, Jul 10, 2017 at 6:12 AM Matthew McNeeney <mmcneeney(a)pivotal.io>
wrote:

Thanks all for the great feedback. There are a lot of good ideas here
that we will use to help guide the implementation of this.

Gabriel; the relationship service instances have with ASGs is
interesting. I don't think we should automatically modify security groups
when service instances are shared, as there could be security implications
in doing so. But this is definitely something we will look into in detail.

Jouke; permanent migrations of services isn't something we've taken into
account in this sharing proposal, however I can see the use cases. I wonder
if these could be mitigated via another solution to another CF CLI command,
for example, making backing up and restoring data services easier or
available to application developers.

Daniel; I believe that idea has been raised a few times but, as I'm sure
you know, breaking the services layer out of the cloud controller could be
very tricky and time consuming. Zach R would have more thoughts on this I'm
sure.

Dies; we believe enforcing service sharing to be enabled by default is a
more secure approach. I appreciate your point that right now application
developers can effectively workaround this and share services via passing
credentials and using *cf cups*, but we know that some CF users are
looking to hide credentials as best as possible. In a more secure world
where credentials are not visible to application developers and are
protected in something like CredHub, this new workflow would be the only
way to share services, and we'd like to ensure that this new workflow is as
secure as possible.


On Wed, Jul 5, 2017 at 6:37 AM tommyoshields71 <tommyoshields71(a)gmail.com>
wrote:

Tell me is this that expensive coin that I have

On Jul 4, 2017 12:40 AM, "Koper, Dies [via CF Dev]" <[hidden email]
<http:///user/SendEmail.jtp?type=node&node=7101&i=0>> wrote:

Hi Matt,



Can you explain the background of the service sharing enabling feature?

Who would want to disable this and for what reason?



I can imagine there are services that should not be bound to multiple
apps, maybe because of locking issues.

If that’s not a limitation/feature of the service, it may be a
constraint of the (initial) developer who created this service for a
single-user purpose.

For those cases, I feel it would make sense for the “enable” flag to be
an attribute of the service itself, or of the person (role) creating it.



How does the Org Manager come in play?

Wouldn’t I currently be copying the credentials over to another
org/person (maybe to another app developer) to store in a user-provided
service, so the additional enable step just creates an additional step
offering no protection?



Regards,

Dies Koper
Cloud Foundry Product Manager - CLI

*From:* Matthew McNeeney [mailto:[hidden email]

<http:///user/SendEmail.jtp?type=node&node=7097&i=0>]

*Sent:* Thursday, June 29, 2017 11:36 PM

*To:* Discussions about Cloud Foundry projects and the system overall. <[hidden

email] <http:///user/SendEmail.jtp?type=node&node=7097&i=1>>

*Subject:* [cf-dev] [Proposal] Sharing service instances across orgs
and spaces

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

------------------------------
If you reply to this email, your message will be added to the
discussion below:
http://cf-dev.70369.x6.nabble.com/cf-dev-Proposal-Sharing-
service-instances-across-orgs-and-spaces-tp7076p7097.html
To start a new topic under CF Dev, email [hidden email]
<http:///user/SendEmail.jtp?type=node&node=7101&i=1>
To unsubscribe from CF Dev, click here.
NAML
<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>

*IMG_20170704_081255.jpg* (1M) Download Attachment
<http://cf-dev.70369.x6.nabble.com/attachment/7101/0/IMG_20170704_081255.jpg>

------------------------------
View this message in context: Re: [cf-dev] Re: [Proposal] Sharing
service instances across orgs and spaces
<http://cf-dev.70369.x6.nabble.com/Re-cf-dev-Re-Proposal-Sharing-service-instances-across-orgs-and-spaces-tp7101.html>
Sent from the CF Dev mailing list archive
<http://cf-dev.70369.x6.nabble.com/> at Nabble.com.