Enable users to inject "all" binding information as environment variables.

[sbose78]

The spec has strong opinions on projecting binding information as "files". There's no way for a user of ServiceBinding to express the desire to Get me everything as environment variables.

While I understand the rationale behind everything being made available as "files" 📁 , a lot of app developers use frameworks/languages which are very sticky towards "environment variables" example, Golang devs.

I would propose we have a new field in the ServiceBinding CRD/API called

• .spec.bindAs: files|env or
• .spec.bindAsFiles: true or
• .spec.bindAsEnv : true

In other words, it would be good to have something that would enable ServiceBinding users to have everything as environment variables too, instead of having to express the desire for the same with individual keys.

[sbose78]

FYI: Service Binding operator is already implementing this. ( some of it planned, not done yet )

• A global switch in the ServiceBinding CR
• A switch specific to backing services in the ServiceBinding CR
• A switch specific to fields in a backing service in the backing service's CR / CRD

[scothis]

Do you have a proposal for how bindAs: env should behave?

[sbose78]

bindAs: env should make all binding secret contents available in the workload, and possibly have a reasonable prefix ( name of the ServiceBinding ) to keep the injected environment variables unique enough for the container.

[navidsh]

Hi @sbose78, we discussed this today during the community call and based on the conversation, would you be able to provide the following?

• some details on the user story
• some details on how the conversion from key/value entries ("Each key must consist of alphanumeric characters, '-', '_' or '.'") in the secret to environment variables

[sbose78]

Sorry, missed this message, I will @navidsh !

[sbose78]

For applications to discover, we could encourage use of an environment variable "SERVICE_BINDING_ENV_MAP" which would tell the runtime which env vars are of interest.

[sbose78]

some details on how the conversion from key/value entries ("Each key must consist of alphanumeric characters, '-', '_' or '.'") in the secret to environment variables

• All alphabets would be uppercase.
• Special characters would be converted to "_".

[baijum]

I think for the 1.0 release, we should proceed with the current approach of configuration as files. And there is limited support for creating environment variables pointing to the keys in the Secret resource. There are pros and cons to both approaches. Post 1.0 release, if the requirement comes up strongly from the community, we can revisit this issue.

Meanwhile, I was thinking of creating "environment variable transformation rules" to construct environment variables from the Secret resource entries. We could add an optional section like this:

envKeyTransformationRules:
  prefix: "STAGE_" # default empty string
  suffix: "_V2" # default empty string
  upperCase: true # make all character upper case
  replace:  # default empty array, replace the left character with the right one
    - ".": "_"
    - "-": "_"

If at least one rule exists, there MUST be environment variables corresponding to all the Secret entries. The transformation rules MUST NOT be applied to the environment variables defined in the .spec.env. The environment variable defined in .spec.env MUST overrides any environment variable constructed through the transformation rule.

Note: This option is not going to disable projecting files. That makes the change backward compatible.

[baijum]

One advantage of using file over environment variable is that mounted Secrets are updated automatically. The same benefit is not there for environment variable without restarting the container. To really make use of this behavior, the application should have some retry logic (probably with exponential backoff) implemented.

Note: this advantage completely depends on the implementation. The current spec is not making a mandate or recommendation to directly use the original Secret from Provisioned Service or Direct Secret Reference.