argoproj / argo-cd

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

Web Shell - Terminal log for auditing purposes #9918

Open marcelofabricanti opened 2 years ago

marcelofabricanti commented 2 years ago

Summary

In v2.4.0 version, ArgoCD brought us a much waited (and awesome) feature that enables you to shell into containers. Now developers can have access to their pods freely.

Motivation

Grant access to people dig into their pods in production environments led us to a few concerns about security and accountability. Perhaps we need to have visibility about the commands inputed into the pods, since now much more people (from another teams) will have access to do it.

Proposal

I think would be nice to have a feature that saves an audit log on each command executed in web shell feature.

Suggestion of fields: Timestamp / User Id / argocd project name / argocd app name / cluster of pod / namespace of pod / name of pod / command executed

I'm not sure if store the audit logs somewhere inside the cluster is the best choice. Or even if store (and make possible search on it afterwards) is a responsability inside Argocd project objectives.

Maybe it's simpler to just export these logs to somewhere else like an AWS S3 Bucket or post to a queue (AWS SQS). Anyone have a better idea to accomplish this?

crenshaw-dev commented 2 years ago

Adding good-first-issue labels because I think the most naiive implementation is very easy - add an env var to the API server to enable logging commands and then add the log statement.

I think logging is a fine first choice rather than another service. If someone has exec access, they are already somewhat trusted. And if they want to fill up logs, they probably have other ways to do so.

TheSwarnim commented 2 years ago

Hi @crenshaw-dev, please assign this issue to me. I would like to work on it.

notfromstatefarm commented 2 years ago

My initial thoughts on this is that it won't be as straightforward as simply recording the commands executed. All we have is an stdin channel - we don't know if a command was executed or if the user is simply passing input to a command they've already started.

You could record all input, split on newlines, but I can't imagine a way to strictly record commands executed. And that has the potential for a ton of spamminess that probably wouldn't be appreciated in the argocd-server logs. Imagine if I was editing a file.

crenshaw-dev commented 2 years ago

Yep, I forget that this is a stream of characters rather than lines.

awx-fuyuanchu commented 1 year ago

Upvote Could be a killer feature if we could have detailed inputs logged. Complete the missing part of the cluster audit log. Maybe we can save the detailed inputs and outputs per session.

eucleciojosias commented 1 year ago

I would love this feature, I'm struggling to config the SSO with Teleport to make the audit possible

crenshaw-dev commented 1 year ago

I think we have to solve the problem of "how do we know what is a command" before we can implement this feature. Logging a series of keystrokes and then backspaces seems maybe worse than no logs at all.

Hronom commented 11 months ago

Can we record some how when user hit enter?

Very needed feature, we love to see it implemented

crenshaw-dev commented 11 months ago

I think we'd want to maintain a cache of keystrokes, applying backspace characters as they arrive. We'd want to flush to logs at a certain cache size limit to avoid filling up memory.

Hronom commented 11 months ago

@crenshaw-dev this makes sense too, I think what you described is works. Even if it corrupt line endings and brings two records in logs, I think it will be something instead of nothing