As a customer in a regulated industry, you may need to respond to auditors by generating comprehensive reports. You can use GitLab to generate audit reports, which track a number of instance, group, and project events.
Problem to solve
Package events such as the ones below are not included in the audit report.
Change action (add, modify, delete, etc)
Who/what made the change (user, retention policy, etc)
What package was changed
When the package was changed
How the package was changed (manual, pipeline, API, etc)This is currently provided in Artifactory logs and UI (last known change).
Proposal
Consider adding Package Registry events to the GitLab Audit report so that customers have a way of auditing changes to packages.
@pprokic I don't have an estimate for this at the moment. It's not on our short term backlog. Good idea about splitting the issues. I updated the issue description on this one to focus on the Package Registry and opened #362290 (closed) for the Container Registry.
Tim Rizzichanged title from Add the Package and Container Registry to the list of audited events to Add the Package Registry to the list of audited events
changed title from Add the Package and Container Registry to the list of audited events to Add the Package Registry to the list of audited events
Tim Rizzichanged the descriptionCompare with previous version
Besides having all these data within the audit report, it would also be usefull to have information on who uploaded a particular package directly on the package information page perhaps with the auth type
eg: Deploytoken <group/projectname> < tokenname>
or
Personal token < username> < tokenname>
I've got the same answer as I provided for the newly split off issue. I'd love for the Compliance team to be able to implement all of these ourselves, but it just isn't feasible given the breadth of GitLab. If this is something that is incredibly important to customers, I have no problem working with the Package group in a cross-group effort to get it implemented. But, we can't take it on ourselves, since we aren't familiar with the code here.
Note: I'm going to update this issue to Category:Audit Events so we can track all open cases related to audit events, but we can keep the group label to indicate the responsible party.
Why interested: It is an audit and security requirement for the customer
Current solution for this problem: None
Impact to the customer of not having this: As indicated above, it is a requirement for the customer's information audit and security to have a correctly captured audit of who has uploaded a package, downloaded it, and/or modified in any way.
In which release this feature is expected to be available ? This is one of the legal and audit requirements to capture this information. Please advise.
@trizzi it seems like Container Registry has recently implemented audit events, are there any blockers currently for implementing the same for Package Registry?
@tmike It looks like @ahuntsman is working on the container registry implementation now via #362290 (closed). I'm not sure where this is in priority for the epic &736.
I imagine we can help contribute, especially once the container registry work is done.
@trizzi I started looking into this issue, and implemented a PoC locally, but before proceeding further, I have a couple of questions to refine the issue's scope:
Which events should we audit? The two main events are package publishing and package deletion. Should we start with these and add more later if needed?
What are the scopes that the events should be available for? There are 4 available scopes: Project, User, Group or Instance. For packages, we're likely choosing between Project & Group, but cannot decide whether we should go for one of them or both. Both means the event will be created twice in the database: one for the project, and one for the group. The growing size of the database table could be a concern here.
Should we provide an opt-in/opt-out setting at the group/project level? Considering the potential database impact, some self-managed instances might prefer not to have this feature enabled by default.
@mkhalifa3 Here are my initial thoughts. @ahuntsman@jdrpereira You both helped with the container registry implementation; what do you think about the plan below?
Events to Audit: Let's start with the core events that provide the most audit value while keeping the scope manageable:
Package publishing
Package deletion
Package version updates
This aligns with the customer's requirements for tracking "who uploaded a package" and modifications while giving us a foundation to expand later.
Audit Scopes: We should implement Group level auditing only since:
Group audit events will already capture all project-level activities within that group.
This avoids duplicate events in the database.
We still maintain complete audit visibility while being more efficient with storage.
The project context can be included in the audit event data itself.
Yes, we should provide an opt-in/opt-out setting at the group level to maintain consistency with the group-level audit scope. This:
It gives group owners control over their audit storage and overhead.
Aligns with the group-level nature of package registry auditing
Maintains clear ownership of the audit configuration
Allows different groups to have different audit requirements
For each audit event, we should capture:
Actor (user/token/deployment key with specific identification)
Thanks @trizzi for the great plan. A question on the Audit Scopes point, should we be restricted to the root group, or the direct parent group of the package?
@mkhalifa3 Let's start with the direct parent group. It follows GitLab's existing pattern of package registry permissions. If customers need root group visibility, we can:
Either traverse the group hierarchy to collect audit events
Extend the implementation to bubble events up to specified ancestor groups
This gives us the flexibility to evolve the feature based on actual usage patterns and customer feedback.
@trizzi That makes sense However, we have a case when projects belong to a user namespace not a group. And unfortunately, namespaces cannot be added as a scope for audit events. Should we save the events at the project level in this case?
So to summarise:
if a package is in a project that belongs to a group => audit events are saved on the group level
if a package is in a project that belongs to a user namespace => audit events are saved on the project level
For these actions, the audit logs should definitely contain precise information about the "who". I remember a while back that if packages were published by an external source, the UI only showed something like "External" with no way to reference which API key was used for the operation. This made us look for audit logs, ultimately leading to me watching this issue, so I thought I'd chime in.
I pushed the 1st MR to implement the package publishing audit events behind a feature flag and send it out for review. Next, I'm going to start on the package deletion audit events.