Skip to content
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

Terminate pods after an exec action #19018

Open
javajawa opened this issue Jul 10, 2024 · 5 comments
Open

Terminate pods after an exec action #19018

javajawa opened this issue Jul 10, 2024 · 5 comments
Labels
bug/enhancement component:cli Affects the Argo CD CLI enhancement New feature or request type:enhancement

Comments

@javajawa
Copy link

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.

@javajawa javajawa added the enhancement New feature or request label Jul 10, 2024
@christianh814
Copy link
Member

Why not just limit who runs exec using RBAC? https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#the-exec-resource

@javajawa
Copy link
Author

javajawa commented Jul 10, 2024

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
Copy link
Author

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
Copy link
Member

@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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug/enhancement component:cli Affects the Argo CD CLI enhancement New feature or request type:enhancement
Projects
None yet
Development

No branches or pull requests

3 participants