## Summary In `12.6` we released the [credentials inventory](https://docs.gitlab.com/ee/user/admin_area/credentials_inventory.html), which aims to save `administrators` and `group owners` (of group-managed accounts) time and effort in managing user access and credential management for their instance or namespace. Based on customer feedback, we now need to make further improvements to this feature to include additional credentials, auditable data, and functionality similar to the improvements made for PAT and SSH credentials in https://gitlab.com/groups/gitlab-org/-/epics/3084 @gitlab-org/manage/compliance FYI since this affects our roadmap for this feature :smile: ### Background In %"13.4" we released https://gitlab.com/gitlab-org/gitlab/-/issues/227264 and https://gitlab.com/gitlab-org/gitlab/-/issues/216004 in support of this epic. These features were placed in ~"GitLab Ultimate" based on my assessment of who the buyer was. After customers read the release post, they took issue with this decision for a few reasons, chief among them: * The customer requesting the issue felt slighted because we placed it in a tier above the one they were in * These features are arguably InfoSec best practices that help secure the entire namespace ### Discussions I spoke with several TAMs (@jrreid, @mpower, @bmiller1) and one [customer](https://gitlab.my.salesforce.com/00161000004zoBW) (internal link) so far about this pricing-expectation discrepancy. Specifically, the features that caused heartburn for customers was [Allow admins to list PAT tokens via REST API](https://gitlab.com/gitlab-org/gitlab/-/issues/227264) and [Allow admins to revoke PAT tokens via API](https://gitlab.com/gitlab-org/gitlab/-/issues/216004). The key points made during this conversations: * Customers have no control over credentials to revoke them in the case of compromise or breach * This feature isn't even available for GitLab.com group owners (yet) * Customers need better enforcement capabilities for rotation and optional revocation to align with their company policies and compliance requirements * The features we released do not help GitLab.com customers for now for a few reasons * GitLab.com customers do not have access to the `administrator` role * The credential inventory only works for group-managed accounts right now * There are permissions/consent challenges to address for personal vs. organizational credentials so groups are not able to manage a personal credential and personal credentials cannot be used for organizational work * ~"group::access" is working on this with [project access tokens](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#project-access-tokens-core-only) and [group-scoped personal access tokens](https://gitlab.com/gitlab-org/gitlab/-/issues/22114) ### Rationale I think the move here that may make the most sense would be to * Downtier [Allow admins to list PAT tokens via REST API](https://gitlab.com/gitlab-org/gitlab/-/issues/227264) to ~"GitLab Core" * Downtier [Allow admins to revoke PAT tokens via API](https://gitlab.com/gitlab-org/gitlab/-/issues/216004) to ~"GitLab Core". * Take no action on/close [Personal Access Token Expiry Policy to Premium](https://gitlab.com/gitlab-com/Product/-/issues/886) The rationale here is that moving the API features to ~"GitLab Core" provides basic InfoSec functionality to a larger number of users. They can then build their own tooling to automate credential management. This is an experience that requires time and effort from users to build out what they need. Leaving the PAT expiry policy in ~"GitLab Ultimate" does two things: * Reduces the blast radius of this disruptive feature (automatic enforcement) * Does the heavy lifting on this (optionally) automated enforcement The credential inventory as it exists today: an in-app experience that consolidates all of the most important detail of the namespace's credentials, would remain in ~"GitLab Ultimate" and we could add additional features such as anomalous activity alerts, maybe usage windows, etc. These may still not be the right ideas for ~"GitLab Ultimate", but the point is to add additional value at the ~"GitLab Ultimate" tier that makes credential management more convenient, easy to report on, and easier to manage overall. ## Proposed change Admin Area ```patch - Deploy Keys Credentials + - Deploy Keys + - Deploy Tokens + - GPG Keys - Personal Access Tokens + - Project Access Tokens - SSH Keys + - Trigger Tokens