search

servicebinding / spec

Specification for binding services to k8s workloads
https://servicebinding.io
Apache License 2.0
92 stars 35 forks source link

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

Open sbose78 opened 3 years ago

sbose78 commented 3 years ago

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

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 commented 3 years ago

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

scothis commented 3 years ago

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

sbose78 commented 3 years ago

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 commented 3 years ago

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

sbose78 commented 3 years ago

Sorry, missed this message, I will @navidsh !

sbose78 commented 3 years ago

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 commented 3 years ago

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

baijum commented 3 years ago

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 commented 3 years ago

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.