You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I run Ambassador in a variety of on-premises Kubernetes clusters where Secrets objects are strictly access controlled. Further, my infrastructure terminates TLS outside of Ambassador, and so I do not need any certs/secrets to run Ambassador.
Describe the solution you'd like
I would like for Ambassador to be able to run without trying to list or watch Secrets objects.
I am currently implementing this by removing secrets from the kubewatch line in entrypoint.sh
We could instead support an environment variable to toggle this behavior.
Describe alternatives you've considered
I haven't considered any meaningful alternatives.
Additional context
I think eliminating the need to read Secrets would make Ambassador easier to deploy and adopt at organizations that strictly lock down API access to Secrets objects.
The text was updated successfully, but these errors were encountered:
A PR that modifies entrypoint.sh to manage secrets under environment-variable control would be welcome! If you look at the way 0.52.0's entrypoint.sh handles endpoints, it should be pretty clear -- the only difference would be that the environment variable should prevent watching secrets, rather than allow it.
Please describe your use case / problem.
I run Ambassador in a variety of on-premises Kubernetes clusters where Secrets objects are strictly access controlled. Further, my infrastructure terminates TLS outside of Ambassador, and so I do not need any certs/secrets to run Ambassador.
Describe the solution you'd like
I would like for Ambassador to be able to run without trying to list or watch Secrets objects.
I am currently implementing this by removing
secrets
from thekubewatch
line in entrypoint.shWe could instead support an environment variable to toggle this behavior.
Describe alternatives you've considered
I haven't considered any meaningful alternatives.
Additional context
I think eliminating the need to read Secrets would make Ambassador easier to deploy and adopt at organizations that strictly lock down API access to Secrets objects.
The text was updated successfully, but these errors were encountered: