When we want to use a Secret Store CSI driver, we need to include a 'csi' block in the 'secrets' section of the values.yaml. This will inject some content into the Volume and Environment Variables sections of the deployment.
I created a template test to check if the YAML is correctly built ✅
We now accept 'secret.as' to have the type 'csi'. This will add an environment variable to the container for each secret and also include the 'csi' block in the volume.
My issue (and the reason, in my humble opinion, why nobody picked up this ticket) arises when creating the integration test.
In our organization's use-case, we are using AWS Secret Manager, but the implementation of this injection should be generic.
For that reason, within the test, we would need to provision Minikube with Consul Vault and the Secret Store CSI driver Helm charts before we can add a custom resource that includes the secret provider class.
It feels like it's beyond the scope to add custom resources, but it's necessary to be able to test the pod was created correctly and the secrets mounted as env vars
integration test hasn't been added ❌
waiting for confirmation that provisioning consul+Vault on minikube and adding the secret store crd is the correct approach for adding an integration test. Another thing, is it necessary to provide an integration test for this case?
Related
Add support for CSI volume mounts - https://github.com/gruntwork-io/helm-kubernetes-services/issues/118
Description
When we want to use a Secret Store CSI driver, we need to include a 'csi' block in the 'secrets' section of the values.yaml. This will inject some content into the Volume and Environment Variables sections of the deployment.
I created a template test to check if the YAML is correctly built ✅
We now accept 'secret.as' to have the type 'csi'. This will add an environment variable to the container for each secret and also include the 'csi' block in the volume.
My issue (and the reason, in my humble opinion, why nobody picked up this ticket) arises when creating the integration test.
In our organization's use-case, we are using AWS Secret Manager, but the implementation of this injection should be generic.
For that reason, within the test, we would need to provision Minikube with Consul Vault and the Secret Store CSI driver Helm charts before we can add a custom resource that includes the secret provider class.
It feels like it's beyond the scope to add custom resources, but it's necessary to be able to test the pod was created correctly and the secrets mounted as env vars
integration test hasn't been added ❌
waiting for confirmation that provisioning consul+Vault on minikube and adding the secret store crd is the correct approach for adding an integration test. Another thing, is it necessary to provide an integration test for this case?