Support group scoped SSH key audit visibility for non-enterprise GitLab.com users with organization access
Release notes
Summary
GitLab.com should support organization or top-level-group audit visibility for SSH key changes made by users who have access to that organization, even when those users are not enterprise users.
Problem to solve
Today, SSH key audit coverage is not sufficient for customers who:
- use GitLab.com
- rely on SAML or group membership for organization access
- intentionally allow users to retain standard community GitLab identities
- need organization-level auditability for compliance and incident response
For example, users are not always enterprise-managed users, but those users can still authenticate into and operate within the organization. If one of those users adds or removes an SSH key from their GitLab.com account, the organization cannot reliably observe that change at the organization level.
This creates a compliance gap for customers who need a clear audit trail of credential changes for users who can access their organization.
Existing behavior
GitLab has add_ssh_key and remove_ssh_key audit events, but the group-scoped visibility is tied to enterprise users.
That means the current implementation does not satisfy customers whose organization access model depends on standard GitLab accounts plus SAML or group access, rather than enterprise-user ownership.
Proposal
Provide one of the following:
- Preferred Allow
add_ssh_keyandremove_ssh_keyto surface at the top-level group or organization scope for users who are currently authorized in that organization, even if they are not enterprise users. - Acceptable alternative Emit an organization-relevant audit event during Git-over-SSH activity that includes the public key identifier used, so customers can detect that a user has changed keys even if the add/remove event itself cannot be directly tied to org membership at that exact moment.
Suggested event details
If implemented, the event should ideally include:
- user ID / username
- top-level group or organization context
- key ID and, if possible, fingerprint or title
- timestamp
- source IP
- whether the action was add or remove
- enough metadata to correlate with subsequent Git-over-SSH usage
Why this matters
Customers with regulated environments need to answer questions like:
- When did this user change SSH credentials?
- Was this user able to access our organization at that time?
- Which credential was later used for Git activity?
- Can we reconstruct a reliable audit trail during a security investigation?
Without this capability, customers must rely on partial workarounds that are difficult to operationalize and may still fail audit expectations.