argoproj / argo-cd

Declarative Continuous Deployment for Kubernetes
https://argo-cd.readthedocs.io
Apache License 2.0
17.33k stars 5.26k forks source link

Terminate pods after an `exec` action #19018

Open javajawa opened 1 month ago

javajawa commented 1 month ago

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.

christianh814 commented 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

javajawa commented 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

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.

javajawa commented 1 month ago

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.

christianh814 commented 1 month ago

@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)

javajawa commented 1 month ago

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).