Open theseion opened 2 years ago
Hi, Thank you for reaching out. Yes you are right, this is not possible. The secret is not reachable outside of the application process. Is this a blocker for you? Maybe importing it as a secret and referencing that would solve your use case?
I managed to get around it for now, so this isn't high priority for me.
I think this can be fixed by skipping references, because they will be expanded later to the value of the referenced variable, which then will hold the secret.
I think I understand the suggestion now. If a ENV var has a parameter expansion referencing a secret yet to be injected, this should be delayed until the secret has been injected.
Stumbled across the same issue. Using interpolated secret-injected env vars was indeed not possible. So, this approach:
- name: MONGO_CS
value: mongo_cs@azurekeyvault$(REGION)
or this
- name: MONGO_CS
value: mongo_cs@azurekeyvault
- name: MONGO_URI
value: $(MONGO_CS)$(REGION)
did not work.
Worked around it by importing it as a secret and mounting it as an env var
- name: MONGO_CS
valueFrom:
secretKeyRef:
name: sct-mongo-cs
key: connection_string
- name: MONGO_URI
value: $(MONGO_CS)$(REGION)
It would be nice to have a few line about this issue in the Known Issues
Kubernetes allows for environment variables to be composed of references to other environment variables: https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#environment-variables. When such a composed variable references an injected variable an error occurs because the resulting string doesn't (usually) match any existing AzureKeyVaultSecret.
The following line produces the invalid AzureKeyVaultSecret string: https://github.com/SparebankenVest/azure-key-vault-to-kubernetes/blob/37f73d5ed967cb20b7b13a9be182c4728d162bc8/cmd/azure-keyvault-env/main.go#L292
Example:
A context this can appear in is when constructing the username for a Postgres database:
username@postgres-host
.