Enabling Service Instance Sharing

Page last updated:

This topic provides information on enabling sharing of service instances for authors of managed services for Cloud Foundry.

Overview

Service authors can allow instances of their services to be shared across spaces and organizations within Cloud Foundry. This allows applications running in different spaces and organizations to bind and unbind to the same service instance. Developers with SpaceDeveloper permissions in the space where the service instance was created are responsible for unsharing, updating, and deleting the service instance.

For more information about the developer and administrator tasks related to service instance sharing, see Sharing Service Instances.

Enabling Service Instance Sharing

Service brokers must explicitly enable service instance sharing by setting a flag in their service-level metadata object. This allows service instances, of any service plan, to be shared across organizations and spaces. The "shareable" flag must be set to true in the service-level metadata to enable service instance sharing. If the flag is set to false or is absent, sharing is disabled.

An example catalog is shown below:

{
   "services":[{
      "id":"766fa866-a950-4b12-adff-c11fa4cf8fdc",
      "name": "example-service",
      "metadata": {
         "shareable": true
      }
   }]
}

Binding Permissions Based on Instance Sharing

When a service instance is created in one space and shared into another, developers can bind their apps to the service instance from both spaces.

You may want to have the service broker return credentials with different permissions depending on which space an app is bound from. For example, a messaging service may permit writes from the originating space, but only reads from any spaces that the service is shared into.

To differentiate between the spaces, implement the following:

  1. During the provision request, the broker stores the organization and space GUIDs of the service instance by inspecting the context object.

  2. On a subsequent bind request, the broker compares the new context object’s organization and space GUIDs against the stored provision request information to determine if the bind request originated from a space the service instance is shared into.

Security Considerations

Service authors must consider the following before enabling service instance sharing:

  • Service keys can only be generated by users who have access to the space where the service instance was created. This ensures that only developers with access to this space have visibility into where, and how many times, the service instance is used.

  • Consider the impact of giving out excessive permissions for service bindings, especially bindings that originate from spaces that the service instance has been shared into. For example, a messaging service may permit writes from the originating space but only reads from any shared spaces. For more information, see Binding Permissions Based on Instance Sharing.

  • You should generate unique credentials on each binding. This ensures that developers can unshare a service instance at any time. Unsharing an instance deletes any service bindings and revokes access for those credentials. Unsharing an instance prevents unauthorized future access from developers and applications that saved the credentials they were previously provided using the service binding.

  • Consider the impact of a service instance dashboard being accessed by users of shared service instances. If authenticating through SSO, see Dashboard Single Sign-On.

Create a pull request or raise an issue on the source for this page in GitHub