[Feature]: Korifi API users can create service bindings of type 'key'

[danail-branekov]

Blockers/Dependencies

No response

Background

Currently when a user creates a service binding korifi assumes that it is of type "app". However the cf api docs define two types of service bindings - "app" and "key". We should support both types of service bindding.

Acceptance Criteria

GIVEN I have pushed and app and created a service instance
WHEN I execture the following request

curl "https://api.example.org/v3/service_credential_bindings" \
  -X POST \
  -H "Authorization: bearer [token]" \
  -H "Content-type: application/json" \
  -d '{
    "type": "key",
    "name": "some-binding-name",
    "relationships": {
      "service_instance": {
        "data": {
          "guid":
          "7304bc3c-7010-11ea-8840-48bf6bec2d78"
        }
      },
      "app": {
        "data": {
          "guid": "e0e4417c-74ee-11ea-a604-48bf6bec2d78"
        }
      }
    }
  }'

THEN I get 202 Accepted and a json response describing a key binding

GIVEN I have created a key service binding
WHEN I try to list all key bindings

curl "https://api.example.org/v3/service_credential_bindings/?type=key" \
  -X GET \
  -H "Authorization: bearer [token]"

THEN I get 200 OK and a list of key bindings only

Dev Notes

• do not create service binding io secret for key bindings

[georgethebeatle]

Understand more about what type "key" means. It looks like the key bindings should not be mounted to any app, but just serve as credential storage. It is also interesting to understand more about how the MTA uses these.

[georgethebeatle]

This doc explains what service keys are and how they are managed. In short, this is a way to generate credentials for a service instance, without having to push an app. After doing that user are free to use them from outside the system or to create UPSI in other spaces or whatever else they might want to do with them. It sounds like type key is a thing in the managed service instances world and does not make too much sense for user provided instances.

[danail-branekov]

The initial PR to support key service bindings creates the service binding io secret that is not needed for the key bindings. As a next step creating that secret should be omitted for such bindings as it is not used