Open javajawa opened 1 month ago
Why not just limit who runs exec
using RBAC? https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#the-exec-resource
Why not just limit who runs
exec
using RBAC? https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#the-exec-resource
Because developers may need to debug running pods, but leaving those pods in an untracked tainted state for an indefinite amount of time makes handling any future alerts more confusing.
We're considering this as a pre-req before giving developers exec access to the clusters.
In the broad sense, I trust developers to poke around and debug, and I don't trust them or myself to not leave something in a debug mode or with some features turned off.
Having had some more time to think, I actually don't need Argo to do any of the deleting (though that would still be nice). A less opinionated very of this idea would be to apply labels/annotations to the pods that have active and completed exec sessions.
My instinct would be a label indicating state, and annotations indicating any metadata (user who logged in etc.) This can then be used in a variety of ways including having an external process that ensures these pods get rotated out according to some conditions of its own divising.
@javajawa This problem extends beyond just Argo CD. You can do something with Kyverno (terminate a pod when someone execs into it)...but only with a TTL.
Meaning, from what I gather, K8S knows when exec
is called but not when someone exits a pod. So the best you can do with Kyverno is "When someone execs
into a Pod, terminate it in X seconds" (where X is a value you can supply)
K8S knows when exec is called but not when someone exits a pod
That is why I'm asking for the state tracking to be added to Argo, which should be aware of the UI closure? (Otherwise, there's going to be dangling session issues).
Summary
When a user uses argocd's
exec
functionality to execute commands on a pod, that pod's state becomes less well defined relative to the git-ops nature of ArgoCD. Therefore, I think there should be an option to have ArgoCD request the termination of a pod when the exec session is ended.Motivation
This is primarily to prevent developers leaving pods either with code changes to the apps they are directly running, additional processes in the background, or with extra tools installed that could compromise the security of the pod.
Proposal
Given a new deletion option being enabled, when ArgoCD closes the terminal session, it should perform the equivalent of a
kubectl delete pod/{id}
to trigger the graceful termination of the pod.