Add the Package Registry to the list of audited events

Context

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.

changed milestone to %Backlog

added Category:Container Registry Category:Package Registry devopspackage grouppackage registry labels

added [deprecated] Accepting merge requests label

added sectionops label

added typefeature label

@trizzi Is there any estimate for which release version this feature could be on the table?

Also, any chance of splitting it into separate issues for Packages i.e. Containers, in case of a higher demand for one of them?

@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.

marked this issue as related to #362290 (closed)

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

changed the description

removed Category:Container Registry label

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>

we're a 100 seat premium customer, and we are looking forward too see this implemented especially if it could be combined with my previous comment

@trizzi is this something that would fall under the compliance group with @derekferguson?

I'm not sure, but the Package group doesn't currently have the capacity to work on this.

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.

Makes sense to me, thanks Derek!

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.

added to epic &736

added sectionci label and removed sectionops label

added Category:Audit Events label

Large GitLab Ultimate customer is interested in this feature: ZD(internal)

• Subscription: GitLab Ultimate
• Product: self-managed
• Link to request: https://gitlab.my.salesforce.com/00161000014vq4FAAQ
• Priority: customer priority7
• 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.
• PM to mention: @trizzi
• CSM to mention: @gavinpeltz @guillene