search

argoproj / argo-cd

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

Better security audit logging #9616

Open crenshaw-dev opened 2 years ago

crenshaw-dev commented 2 years ago

Summary

Add security audit logging per OWASP recommendations. https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html

Motivation

For example, we currently don't log failed authz attempts. It would be good to log things like attempts to access Applications which the user does not have access to.

Proposal

Identify and list things that aren't currently logged which should be logged for security audit purposes.

Decide how to identify these logs to the reader as security related. I'd recommend logging all at the "warn" level and adding a security: <severity> field, where <severity> indicates how likely it is that the activity is malicious and/or the sensitivity of whatever is apparently being attacked.

riuvshyn commented 2 years ago

how do I enable audit logs for argocd? I can't find any docs related to audit logs configuration

crenshaw-dev commented 2 years ago

@riuvshyn depending on what you mean by "audit," they may be enabled by default. On Slack you mentioned you wanted a record of each request. Those logs are available at the INFO (default) log level in the Argo CD API server pods.

riuvshyn commented 1 year ago

is there any update on this?

@crenshaw-dev I am looking for a way to configure audit logs and tracing. Basically I want to be able to see some trace-id when user logged-in so then I can track any actions performed by a user, for example I want to be able to find who and when did some manual change on UI for a given application or any other configuration. That is crucial piece for a system that has influence on other systems every action must be auditable.

I was checking regular logs for various argo components but they are pretty useless from audit perspective, there is no even log for successful admin user login I can see it only for failed login attempts.

daniel-laszlo commented 9 months ago

Hi, this is also crucial for us. Especially that there is no way to granularly define on a Kubernetes resource level what a user can edit and what not. So we are left with the fact that all of our developers can edit all Kubernetes resources in their project without us (Devops team) having any way to observe this - or react in case of unauthorized access.

macmiranda commented 9 months ago

Should https://github.com/argoproj/argo-cd/issues/10210 be included in the scope of this issue?

luispabon commented 9 months ago

This is definitely a must. The native events should at least be recording who in addition to what when argo is being interacted with via the UI or the cli.

sk31337 commented 6 months ago

Kindly request to push this topic about audit logging, because we also need this very much :)

yesika-ramirez commented 5 months ago

We are also looking forward for audit logging in argocd

crenshaw-dev commented 5 months ago

Many API requests are already accompanied by a log line which includes a user identifier field: https://github.com/argoproj/argo-cd/blob/74a420dc611da31b7d57018982b55abe10ab10e5/util/argo/audit_logger.go#L123

andrii-korotkov-verkada commented 1 week ago

Currently, we have audit logs on the following events

    EventReasonStatusRefreshed    = "StatusRefreshed"
    EventReasonResourceCreated    = "ResourceCreated"
    EventReasonResourceUpdated    = "ResourceUpdated"
    EventReasonResourceDeleted    = "ResourceDeleted"
    EventReasonResourceActionRan  = "ResourceActionRan"
    EventReasonOperationStarted   = "OperationStarted"
    EventReasonOperationCompleted = "OperationCompleted"

It's conditional on whether event log is enabled, but it's enabled by default. We have user added to those.

Do you think we need to audit further and expand the coverage?

muawiakh commented 6 days ago

We would also like to have more granular audit logs. Currently, if someone updates an Application the log event only reports updated application spec e.g.

"time="<TIMESTAMP>" level=info msg="<USER> updated application spec" application=<APP_NAME> dest-namespace=<NAMESPACE> dest-server="https://kubernetes.default.svc" reason=ResourceUpdated type=Normal user=<USER>

We would like more details e.g. 

<USER> disabled auto-sync

In general, maybe all the buttons that are exposed on the Application Details Page could be separate auditable events e.g.

# Sync Policy Section in UI

- <USER> disabled auto-sync
- <USER> enabled auto-sync
  - <USER> enabled prune resources
  - <USER> disabled prune resources
  - <USER> enabled self heal
  - <USER> disabled self heal

But the most important for us is enable/disable auto sync.