Skip to content

UI Support for Managing Ghost-Owned Deploy Keys on GitLab.com

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Release notes

Add a self-service feature to GitLab.com that allows users to identify and manage deploy keys owned by the Ghost user (representing deleted or blocked users) directly from the UI, improving visibility and control over repository access permissions.

Problem to solve

When a user who created a deploy key is deleted or blocked, the key becomes owned by the Ghost user. Currently, on GitLab.com, there is no way for users to detect which deploy keys are owned by the Ghost user without access to the Rails console, which is unavailable to SaaS users. This lack of visibility creates confusion and operational issues, such as deploy keys retaining pull access but losing push access (related doc clarification #184091) without clear indication of the root cause. Users need a way to proactively identify and manage these orphaned keys to maintain secure and efficient workflows.

For example, in our case, a deploy key failed to push to a branch with a "pre-receive hook declined" error, despite having "Grant write permissions to this key" checked for the key. It was only after support investigation that we learned the key was owned by the Ghost user due to a deleted colleague’s account. This opacity delayed troubleshooting and resolution.

Proposal

Introduce a new feature in the GitLab.com UI under the Settings > Repository > Deploy Keys section of a project or group, adding a filter or column labeled "Owner" that indicates when a deploy key is owned by the Ghost user. Additionally, provide an optional notification or health check in the project dashboard when Ghost-owned deploy keys are detected, linking to the Deploy Keys settings page.

  • Technical Details: Display the ownership status of deploy keys in the UI, indicating when they are owned by the Ghost user due to a deleted or blocked account.
  • Design Proposal: Add a simple "Ghost" badge or filter toggle next to affected keys in the Deploy Keys list. Include a tooltip explaining: "This key is owned by the Ghost user because its original owner was deleted or blocked."
  • Related issue: Zendesk ticket(internal).

This feature would allow users to:

  1. Quickly identify Ghost-owned deploy keys without contacting support or using unavailable tools like the Rails console.
  2. Decide whether to rotate or reassign these keys to active users, restoring full functionality (e.g., push access).

Intended users

  • Primary Users: Platform Engineers (e.g., Priyanka) and Systems Administrators (e.g., Sidney) responsible for maintaining repository access and security.
  • Secondary Users: Development Team Leads (e.g., Delaney) and Release Managers (e.g., Rachel) who oversee CI/CD pipelines and deploy key usage in GitOps workflows.
  • Context: This is particularly relevant for organizations with frequent employee turnover or external consultants, where deploy keys tied to departed users or consultants become orphaned.

Feature Usage Metrics

Track basic usage, such as how often users access the Deploy Keys page to view Ghost-owned keys, and let the GitLab team define detailed metrics based on implementation.

Does this feature require an audit event?

Not sure.

Edited by 🤖 GitLab Bot 🤖