Open keriksson-rosenqvist opened 1 year ago
I'm not sure if this would meet your goal since the secret would still need to be present in Keyvault, but it is possible to create an empty secret in Keyvault which can be pulled in by AKV2K8S and would just simply make the resulting environment variable empty.
I'm not sure if this would meet your goal since the secret would still need to be present in Keyvault, but it is possible to create an empty secret in Keyvault which can be pulled in by AKV2K8S and would just simply make the resulting environment variable empty.
In short, No. As we discussed in the Slack thread:
The problem I'm trying to solve is having to rely on the secret existing at all. E.g. if we push an update before the DevOps people have updated the secrets or if for some reason a new resource group is created for which the secret is not applicable. Short term I will likely use some helm field and if statement to define if we require that record to exist or not. :thinking:
I would like to be able to define a kubernetes resource that allows me to optionally fetch an akv object if it exists but does not cause the deployment to fail if the object is not there. If I output the akv object as a k8s secret then that can be optionally referenced in the deployment environment variable list, but that means the secret value is readable in k8s which I want to avoid.
TLDR: Implement
optional
support for directly ingested akv objects, e.g.Which provides parity with
N.B. The
default
field is not needed but would be a nice option for assigning a default value if the akv record isn't found.