Summary
The argo-server SSO RBAC audit line records the user, but not what the user did. The action and the target are logged in separate lines that share nothing with it except a millisecond timestamp, so with concurrent users "who" and "what" cannot be joined reliably from stdout.
Current behavior (v3.6.10, --auth-mode=sso, sso.rbac.enabled: true, SSO_DELEGATE_RBAC_TO_NAMESPACE=true). Submitting a workflow from a template in the UI produces three lines:
level=info msg="selected SSO RBAC service account for user" email=user@example.com loginServiceAccount=user-default-login serviceAccount=argo-trigger-sectests
level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=SubmitWorkflow grpc.service=workflow.WorkflowService
level=info method=POST path=/api/v1/workflows/sectests/submit size=2256 status=0
None of them carries a request or trace id. The created Workflow gets workflows.argoproj.io/creator-email, which is great, but that record disappears with the object unless the archive is enabled, and it does not cover reads, deletes or denied calls.
Proposed change, either of:
A request id shared by the three existing lines would also solve it.
Use Cases
Compliance needs an exportable trail (stdout → log pipeline, e.g. Elasticsearch) of who ran which workflow, when, and whether it was allowed, without standing up the workflow archive database and without correlating log lines by timestamp. Related: #16741 proposes actor attribution for controller-performed actions; this request covers the server side of the same need.
Message from the maintainers:
Love this feature request? Give it a 👍. We prioritise the proposals with the most 👍.
Summary
The argo-server SSO RBAC audit line records the user, but not what the user did. The action and the target are logged in separate lines that share nothing with it except a millisecond timestamp, so with concurrent users "who" and "what" cannot be joined reliably from stdout.
Current behavior (v3.6.10,
--auth-mode=sso,sso.rbac.enabled: true,SSO_DELEGATE_RBAC_TO_NAMESPACE=true). Submitting a workflow from a template in the UI produces three lines:None of them carries a request or trace id. The created Workflow gets
workflows.argoproj.io/creator-email, which is great, but that record disappears with the object unless the archive is enabled, and it does not cover reads, deletes or denied calls.Proposed change, either of:
claims.Emailinto gatekeeper audit log entry #7748) withgrpc.method,namespaceand, where known, the resource name and the referencedworkflowTemplateRef;msg="audit" user=<email> serviceAccount=<sa> method=SubmitWorkflow namespace=<ns> template=<name> workflow=<name>.A request id shared by the three existing lines would also solve it.
Use Cases
Compliance needs an exportable trail (stdout → log pipeline, e.g. Elasticsearch) of who ran which workflow, when, and whether it was allowed, without standing up the workflow archive database and without correlating log lines by timestamp. Related: #16741 proposes actor attribution for controller-performed actions; this request covers the server side of the same need.
Message from the maintainers:
Love this feature request? Give it a 👍. We prioritise the proposals with the most 👍.