Currently, we have to hard code the remoteNetworkName or remoteNetworkId. It would be nice if we could fetch this from a existing k8s secret like we can with the Twingate API key.
Why do we need it?
The way our automation works, it's easier to fetch dynamic values from a resources that already exists on the cluster rather than set it as a value in a Helm chart. If we were able to fetch the remote network name/ID from a k8s secret, we could hydrate the cluster with that information dynamically before deploying any Helm applications to it. That would allow us to use the same values.yaml file for each cluster with different remote network rather than create a file for each cluster.
Additionally, it may be nice to have twingateOperator just read it all its settings from a pre-existing ConfigMap, but that's irrelevant to our use case.
What is missing?
Currently, we have to hard code the
remoteNetworkName
orremoteNetworkId
. It would be nice if we could fetch this from a existing k8s secret like we can with the Twingate API key.Why do we need it?
The way our automation works, it's easier to fetch dynamic values from a resources that already exists on the cluster rather than set it as a value in a Helm chart. If we were able to fetch the remote network name/ID from a k8s secret, we could hydrate the cluster with that information dynamically before deploying any Helm applications to it. That would allow us to use the same
values.yaml
file for each cluster with different remote network rather than create a file for each cluster.Additionally, it may be nice to have
twingateOperator
just read it all its settings from a pre-existingConfigMap
, but that's irrelevant to our use case.Environment
Twingate Kubernetes Operator version:
39d499d684694abd5df762834b7e6a57b81ed9fb
Anything else we need to know?: