Korifi API users should be able to consume any managed service credential

[georgethebeatle]

Blockers/Dependencies

Blocked by managed service support!

Background

As of today korifi is assuming that service credentials are key-value string mappings. However according to the v3 api spec the credential can be a more complex json object.

Here is an example of a service binding secret using more complex credentials:

{
  ".metadata": '{"credentialProperties":[{"name":"foo","format":"json"},{"name":"bar","format":"text"}],"metaDataProperties":[{"name":"md1","format":"text"},{"name":"md2","format":"json"}]}',
  "foo": '[{"a": "b"}]',
  "bar": "yes, please",
  "md1": "first metadata",
  "md2":'[{"md2": "md2value"}]'
}

Korifi should not assume a flat map as the structure of the service binding credentials

Action to take

Think of a better way of modeling thet service binding credentials. A map[string]any sounds like a better option.

[julian-hj]

FWIW, here's some OSBAPI client code for binding responses. Credentials should be a map of string to interface.

[tcdowney]

I left a comment on Slack about this as well: https://cloudfoundry.slack.com/archives/C0297673ASK/p1680190415283189

Basically Cloud Controller in CF for VMs is storing credentials as serialized JSON in a TEXT column in the database, so any valid JSON object type should be supported. One thing I think we could do is actually store the original input off on the UPSI Secret under a key like KORIFI_SERIALIZED_CREDENTIALS or CF_SERIALIZED_CREDENTIALS (or something) and use that when constructing VCAP_SERVICES. We should still break out the credentials into individual keys/values on the Secret for K8s Service Binding support, but having what was originally provided through cf cups SERVICE_NAMED -p '{"some-cred": "some-value", "other-cred": 9000"}' feels like what we need to do here.

[georgethebeatle]

It would be better to defer the modeling of the service binding credentials to when we start writing the managed service proposal