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