The monitor, tentacle and script pod workloads don't seem to expose an ability to mount arbitrary volumes/volume mounts via input values.
Primary reason this is desirable for us is we are using Azure Key Vault to store our Polling URL, Tentacle Certificate, Monitor Installation GUID, etc.
Ideally we want to mount these Azure KV objects straight into the monitor / tentacle / script pods via the Azure Key Vault CSI driver using volume mounts and SecretProviderClass manifests, though as a workaround we're currently using pre-deployment scripting to pull these from Key Vault and inject them as helm values.
Exposing arbitrary vol/vol mount values keys would allow us to wire up our k8s agent pods directly to Key Vault with the existing Managed Identity/Azure Workload Identity bindings we have configured.
I did cross off the obvious workaround via attempting to ram volumes: ... and volumeMounts: ... structs into the various *.spec.* keys exposed in the chart, hoping that Helm would be smart enough to collapse my keys into the ones the chart already renders - unfortunately this is a dead end as Helm blindly renders out duplicate volume / volumeMount sections in the pod specs causing deployment errors.
As a secondary but relevant issue - I might just have missed it, but even if we do achieve the ability to mount Azure KV objects onto our k8s agent pods, it seems there are still some environment variables that do not support being mounted from pre-existing k8s secrets such as the polling URI and monitor installation ID.
Acknowledging our use case scenario might be a bit niche here - what we're doing is shoving all agent configuration into Azure Key Vault from Terraform when it provisions our agents, so it would be awesome to mount all of these unique agent values without using Helm values.
The
monitor,tentacleandscriptpod workloads don't seem to expose an ability to mount arbitrary volumes/volume mounts via input values.Primary reason this is desirable for us is we are using Azure Key Vault to store our Polling URL, Tentacle Certificate, Monitor Installation GUID, etc.
Ideally we want to mount these Azure KV objects straight into the
monitor/tentacle/scriptpods via the Azure Key Vault CSI driver using volume mounts andSecretProviderClassmanifests, though as a workaround we're currently using pre-deployment scripting to pull these from Key Vault and inject them ashelmvalues.Exposing arbitrary vol/vol mount values keys would allow us to wire up our k8s agent pods directly to Key Vault with the existing Managed Identity/Azure Workload Identity bindings we have configured.
I did cross off the obvious workaround via attempting to ram
volumes: ...andvolumeMounts: ...structs into the various*.spec.*keys exposed in the chart, hoping that Helm would be smart enough to collapse my keys into the ones the chart already renders - unfortunately this is a dead end as Helm blindly renders out duplicatevolume/volumeMountsections in the pod specs causing deployment errors.As a secondary but relevant issue - I might just have missed it, but even if we do achieve the ability to mount Azure KV objects onto our k8s agent pods, it seems there are still some environment variables that do not support being mounted from pre-existing k8s secrets such as the polling URI and monitor installation ID.
Acknowledging our use case scenario might be a bit niche here - what we're doing is shoving all agent configuration into Azure Key Vault from Terraform when it provisions our agents, so it would be awesome to mount all of these unique agent values without using Helm values.