[RFC0040] Service Credential Binding Rotation for Applications

[beyhan]

This is a tracking issue for RFC0040.

Delivered with:

• CF-Deployment version:
• CLI version:
• CF Docs:

Tasks

CF API

• Move service binding uniquness validation into ccng cloud_controller_ng#4521
• Filter active service bindings per instance on dataset level cloud_controller_ng#4570
• Lock app when creating service bindings cloud_controller_ng#4577
• Remove service binding unique constraints to allow multiple bindings cloud_controller_ng#4528
• Add config parameter to configure number of service bindings capi-release#568
• Multiple service bindings cloud_controller_ng#4586

CLI

• [v8] Add "--strategy" parameter to "bind-service" command cli#3654
• [main] Add "--strategy" parameter to "bind-service" command cli#3655
• [main] Enhance "service" command for multiple service bindings cli#3658
• [v8] Enhance "service" command for multiple service bindings cli#3660
• [main] Command "services": Eliminate duplicate app names cli#3662
• [v8] Command "services": Eliminate duplicate app names cli#3663
• [main] Command "unbind-service" can handle multiple bindings cli#3664
• [v8] Command "unbind-service" can handle multiple bindings cli#3665

cf-deployment

• enable in cf-deployment

[johha]

We should consider to add s feature flag to allow app developers to decide if they want to have support for multiple bindings.

Once ccng PR #4521 is merged and operators allow multiple bindings by setting max_service_credential_bindings_per_app_service_instance > 1 there could be a unexpected behavior for users:

$ cf s  
                                                                                                                                                                            
Getting service instances in org binding / space binding-space as admin...

name             offering        plan              bound apps                                               last operation     broker   upgrade available
async-instance   fake-service    fake-async-plan   hello-nodejs                                             create succeeded   cats     no
other-instance   other-service   fake-async-plan   hello-nodejs, hello-nodejs, hello-nodejs, hello-nodejs, hello-nodejs   create succeeded   other    no

#-> App has 5 bindings to other-instance 

$ cf unbind-service hello-nodejs other-instance                                                                                                                                     
Unbinding app hello-nodejs from service other-instance in org binding / space binding-space as admin...
OK


$ cf s                                                                                                                                                                   
Getting service instances in org binding / space binding-space as admin...

name             offering        plan              bound apps                                                             last operation     broker   upgrade available
async-instance   fake-service    fake-async-plan   hello-nodejs                                                           create succeeded   cats     no
other-instance   other-service   fake-async-plan   hello-nodejs, hello-nodejs, hello-nodejs, hello-nodejs   create succeeded   other    no

#-> App has 4 bindings to other-instance 

A unbind-service command should always result in removing all bindings for the given service instance and app. Furthermore once the required changes according to RFC0040 are implemented in the CF CLI users might still use older versions resulting in the same unexpected behavior. Adding a feature flag puts the developer in control.

[johha]

We had further discussions on the app feature flag for multiple service bindings and came up with an alternative.
There could be an additional parameter for POST /v3/service_credential_bindings like allow-multiple and only if this parameter is set and max_service_credential_bindings_per_app_service_instance is set > 1 then multiple bindings would be created.