In order to choose to reduce exposure of service binding credentials
I need that service binding credentials to not be stored after being returned to OSB clients
As a osb-cmdb operator
In order to provide access to support multi-tenancy among 3rd party service providers (see #792) while preserving multi-tenancy among service providers
I need service binding credentials read access to be restricted and reduced in time.
Possible design
Limitation with osb-cmdb 1.X architecture
With osb-cmdb 1.0, osb-cmdb get backing credentials through a service key created through cloudfoundry and stored in cloudfoundry. Deleting the service key will trigger a OSB unbinding request, and therefore preventing osb client from using the returned credentials.
Usage of a backing service binding (e.g. bound to a fake app) instead of a backing service key won't help much:
service binding credentials are still stored in cloudfoundry
service binding credentials can be access through CF CLI in environment variable of the bound app
deleting the backing service binding will also prevent the osb client from using the returned credentials.
Rearchitecting osb-cmdb for direct backing broker access
Alternative architectures that would support not having CF store credentials:
use a dedicated inventory storage (i.e. don't use CF anymore) and direct OSB calls to backing brokers
keep usage of CF for service instance, but make direct broker access for service bindings
Alternative UX
Service provider use the OSB catalog field "bindings_retrievable" :true to have their service keys being stored in the osb-cmdb inventory past the service binding completion, and be able to access them for troubleshooting purposes
This implies that paas-templates existing service brokers which do not return "bindings_retrievable" :true in their catalog need maintenance or won't have service keys available for troubleshooting
Workaround is for a service provider/operator to manually create a new service key on the backing service when there is a need to troubleshoot. However, this does not support troubleshooting a given credential returned to an osb-client
Expected behavior
See downstream issue https://github.com/orange-cloudfoundry/paas-templates/issues/937
As a osb service provider
As a osb-cmdb operator
Possible design
Limitation with osb-cmdb 1.X architecture
With osb-cmdb 1.0, osb-cmdb get backing credentials through a service key created through cloudfoundry and stored in cloudfoundry. Deleting the service key will trigger a OSB unbinding request, and therefore preventing osb client from using the returned credentials.
Usage of a backing service binding (e.g. bound to a fake app) instead of a backing service key won't help much:
Rearchitecting osb-cmdb for direct backing broker access
Alternative architectures that would support not having CF store credentials:
Alternative UX
"bindings_retrievable" :truein their catalog need maintenance or won't have service keys available for troubleshootingAffected release
Reproduced on version 1.1.0 -->