-
Notifications
You must be signed in to change notification settings - Fork 302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
allow_k8s_contexts not properly enforced when changing context with kubectl #6295
Comments
hmmmmm....i was not able to reproduce the behavior you're describing. But I think there's a bit of confusion about the expected behavior. Here's what I tried:
The behavior I would expect is that Tilt reads the kubeconfig at startup, and continues to deploy to the same cluster, even if your current context changes. Do you have additional repro steps? |
Unfortunately after playing around a bunch I also can't reproduce the bug.
To me this feels like a very weird race condition. I am not familiar with the codebase, but do you know how tilt handles the context internally? Are kubectl commands always applied with a pinned context? |
Is tilt maybe working with tokens to authenticate to the api and because >14h passed, it expired and it had to renew it bypassing the checks and using the current-context? |
tilt reads the kubeconfig at startup, minifies it (removing all the other kube contexts), writes a new minified kubeconfig to a different place on disk, and uses that one for all future connection settings. If you run |
The config it writes to: |
Expected Behavior
Assume tilt is already running with a allow_k8s_contexts allowing docker-desktop. Changing the context now on my system using
kubectl config use-context example
. I would assume it checks before applying an operation that it is still in the correct context. However I just deployed some stuff to a cluster that I should only modify with caution.Current Behavior
I do not know too much about tilt internals but I would assume it runs the check when starting up tilt and not before applying resources. Therefore there is always a window where tilt applies stuff to a cluster that is not explicitly enabled.
I added the allow_k8s_contexts when tilt had already started which might be the key to this issue.
When running
tilt down
it correctly recognized that it should not touch that cluster, so I deleted the created resources manually.Steps to Reproduce
kubectl config use-context asdf
Context
tilt doctor
OutputAbout Your Use Case
I forgot that tilt was still running somewhere in the background. I did some troubleshooting on another cluster and tiggered a tilt update through renaming a file. Then Tilt installed the deployment on the cluster it is not allowed to use.
We could remember the allowed context when allow_k8s_contexts is used and always set
--context=<allowed-context>
.Though I can also see that this may lead to other people running into issues that change their clusters when developing.
Another approach would be to reverify that an allowed context is used before applying resources.
The text was updated successfully, but these errors were encountered: