-
Notifications
You must be signed in to change notification settings - Fork 874
feat: add workspace agent connect and app open audit types #16493
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
feat: add workspace agent connect and app open audit types #16493
Conversation
63cac18
to
8128b7e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach will work, however the downside is you cannot easily relate it to a workspace.
You can do a search query such as resource_id:57893b46-9763-498a-b22b-f208d7d719bc
in the audit logs to see the workspace audit logs.
If we set ResourceID
to return the workspace ID for these resources, then this would show up there. I do understand though that these resources are unique from each other... 🤔
My only comment is I wonder if we can relate it to the workspace somehow.
Edit: I had an idea a long time ago to "link" audit log entries: #5419
This approach might just be the way we do it without any linking.
@Emyrk thanks for raising the issue of associating the resource with a workspace, that's definitely something we want. While it sounds useful, It's not clear to me how we'd apply #5419 in the context of this feature. My guess is that being able to show the following information is more valuable than linking to the exact resource that was accessed:
So it sounds to me like we should just use the workspace ID (or is it workspace build ID?), although I'm not sure how we should reference the app. Do we just use additional fields in this case to add the context? (I.e. the connection type like editor/ssh or app slug) |
I agree it's not directly applicable. In short, I think there is some value in having "linked" audit entries, or possibly more complex audit entries to cover cases like this.
Using I was thinking from a product UX, it makes the most sense to put in the workspace uuid. The solution might be too much for this PR. It might be worth having some other effort to link things together, or add more uuids, or do w/e is required to allow "Workspace Audit Logs" be a view we support. |
de017dc
to
640a0c3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Emyrk if we are happy with the approach of:
- Tracking the app/agent resource for open/connect
- Including workspace_id, name, etc. in additional fields and improving search (Allow searching audit logs for "additional fields" values, e.g. workspace ID #16524)
I think this PR is ready for a proper review. Promoting from draft.
debcf9c
to
58f1d2a
Compare
This commit adds new audit resource types for workspace agents and workspace apps, as well as connect and open actions. The idea is that we will log new audit events for connecting to the agent via editor or SSH. Likewise, we will log openings of `coder_app`s. Updates #15139
a9b4adf
to
88f22b7
Compare
88f22b7
to
469e2cd
Compare
@Emyrk are there still any changes you would like to see in this PR? If not I think it’s ready for a final round. |
This commit adds new audit resource types for workspace agents and
workspace apps, as well as connect/disconnect and open/close actions.
The idea is that we will log new audit events for connecting to the
agent via SSH/editor.
Likewise, we will log openings of
coder_app
s.This change also introduces support for filtering by
request_id
.Updates #15139