Allow for injected of bindings

[arthurdm]

In the spec we have taken the more secured approach and only supported mounting of binding data.

However, there can be cases where the binding data is not necessarily sensitive data - it could simply be an URL of an in-cluster service, or a public external service.

Also - while there's consensus of environment variables not being as secured as persisted volumes, supporting this method will improve the modernization of existing applications.

[Avni-Sharma]

For

servicebinding/secret/<binding_property>: {.status.<status_property>} (where <binding_property> is any property from the binding schema, and <status_property> refers to the path to the correspoding status property)

we can have something like servicebinding/secret/as_env/<binding_property>: {.status.<status_property>}
or servicebinding/secret/as_volumemount/<binding_property>: {.status.<status_property>}

[arthurdm]

hey @Avni-Sharma - I was wondering if perhaps the decision of injecting "as env" versus "as volume" is something that the bindable service shouldn't be concern with, since that only affects the consumer and each consumer could be different?

I am thinking about if this is just an option on the ServiceBinding CR - so from the perspective of the bindable service its job is to make its bindable properties available, and the consumer decides (via the request CR) how to consume that.

What do you think?

[sbose78]

Very interesting points.

We did try taking the approach as you had outlined initially but then we realized that backing services may always have a mix of environment variables and "files", and maybe the operator author knows best?

Example, certificates ideally will be "files", usernames could be environment variables.

So, such scenarios where we need both would be hard to express in a Service Binding.

So how about having the specification look like the following:

1. Ask operator authors to specify volume or env ( as we have now )
2. Support a blanket override field in Service Binding CRD which says "I don't care what the operator author recommends I want everything to be a volumeMount or everything to be an envVar" kinda thing.

[arthurdm]

that's a good point - basically, if the bindable Operator makes that suggestion (env / volume) then it saves the extra work from every consumer to make the decision. I like that. 👍

Other related questions:

• what is the key called inside ServiceBinding CR that toggles envVar vs volumeMount?
• what should the default for that key be?

[arthurdm]

Following the SBO convention, we could update the spec saying that bindable services MAY add the prefifx env or mount to their x-descriptors or annotations.

@Avni-Sharma @sbose78 - thoughts?

[arthurdm]

after thinking more about it, we may have some obstacles in allowing the bindable resource pick which items are env versus which are mounted. In the case where someone creates a ServiceBinding CR but turns off application injecting (so just lets SBO create the Secret), how would they know which items of the Secret were intended to be injected as env var versus mounted?

[sbose78]

but turns off application injecting (so just lets SBO create the Secret)

If SBO is being asked to skip injecting, then that information is effectively lost 🤔
However, we can 'copy' over the information into the secret's annotations and leave it for consumers to interpret ?

[arthurdm]

I think that's a good approach. @navidsh - that would mean our Runtime Component could check if there are any annotations in the Secret, and process those.

[Avni-Sharma]

Shall we then look at supporting the same annotation format in the sbr cr as annotations as well? so the resolution would be that the sbr cr annotations > (crd annotations/x descriptor ) or can we have it in customEnVar / dataMapping so we can have something like

dataMapping:
   - Name: CUSTOM_NAME
     Value: go template/json-path
     InjectAs: Env/VolumeMount

wherein the user is telling that I want the variables as env var or a volume mount. So what the backing service's annotations provide us with, is something that should be ideally followed. Anything else (customizable or the user's wish) can then go to customEnvVar / dataMapping

[sbose78]

Good idea, the override staircase could then be:

• read guidance from operator author
• read global SBR configuration
• read customEnvVar BindAs/InjectAs ?