In #36742 (closed) we implemented a credentials inventory to enable administrators to list user access credentials, including Personal Access Token (PAT) records.
An HTML UI does not sufficiently support larger organizations that rely on GitLab's APIs to programmatically carry out many functions within the application.
Further details
Although GitLab is "GraphQL first", this feature is expected to be used in conjunction with the REST API for ApplicationSetting and should be implemented in the REST API on that basis.
Interesting Thanks for digging that out, it's always helpful to see how it's done elsewhere.
To be honest, I'm not a huge fan of that approach. It seems to me that a single endpoint /personal_access_tokens should be available and the result filtered by what the user is permitted to see. Admins could then filter by user, if they wanted to, e.g. [GET] /personal_access_tokens?user_id=xxxx.
To me, this feels more RESTful and gives us the most functionality for the least amount of work. I suspect it's a judgement call though.
@tancnle@asubramanian1 I'd be keen to get your views on this since you've both probably got more experience than me with the REST API.
Option
Two separate endpoints (not neccessarily to be tackled in this one issue.)
[GET] /personal_access_tokens - Only available to admins
[GET] /users/:id/personal_access_tokens - Available to everyone but returns an error when accessing a user you're not authorized to.
Option
One endpoint
[GET] /personal_access_tokens?user_id=xxxx - user_id is optional
Results are automatically scoped to whatever the current user can see. (Admins see everything, but can optionally filter by user_id)
(@djensen please shout if I've misrepresented your comment!)
I'm not sure if there is a reason that the Deploy Keys API splits them up
Yeah, that's a good question.
@djensen - I was looking at the Deploy Keys api, and realized that all of the CRUD operations are done at a project level. For e.g. add a deploy key to a project, delete a deploy key from a project, and so on.
Only the List api is available in the 2 forms.
It could be that the api was built for deploy keys scoped to projects initially, and then an api for instance admins to view the keys for all projects was introduced.
In generic REST perspective, one endpoint sounds as a good option to me. Also, it provides a way to extend the filters for other PAT attributes.
@mwoolf Great discussion. IMHO, Option 1 or 2 are not much different in terms of RESTful literature. In fact, I think it's all depending on use cases . If there is a strong hierarchical relationship between User and PAT, or in other words, we could not reliably get PAT without first identifying the User, I'd argue for Option 1. Option 1 has better support for caching, but I think it is less of a concern atm.
As @asubramanian1 has pointed out, I think we should be good with GET in either form. I am supportive of Option 2 as it offers better developer experience and flexibility.
{"personal_access_tokens":[{"id":2,"revoked":false,"expires_at":"2020-12-12","created_at":"2020-12-10","name":"Max's super secret token","user":{"id":10},"_links":{"user":"https://....../users/10"}},...]}
This sits somewhere between and IMO. It's a well-trodden and mature area of the codebase, but it's also a completely new endpoint that exposes potentially sensitive information so testing will need to be rigerous which could raise unexpected issues along the way.
Since this particular issue is in support of (blocks) #216004 (closed), do you think it makes sense to have this available in GitLab Ultimate or are there other factors here?
@mwoolf Gotcha. Yea that's why I asked because I couldn't recall if we discussed it and with all of the refinements/movements in this epic, I think this one just escaped me.
My feeling is to place this into GitLab Ultimate for now. We will need to re-visit pricing, regardless, when we re-open and engage on https://gitlab.com/gitlab-com/Product/-/issues/886. At that point we can delineate between the various components of this epic and make necessary adjustments there
@mwoolf@mattgonzales I just stumbled upon this issue via gitlab-docs!1056 (merged), and I was wondering about GitLab Ultimate here. Given that the main feature is in Core, I don't think it makes much sense to have its API in Ultimate :) Usually, those two are tied together. At least for users (not admins), it should be in Core I think.
@axil That's a great point! I hadn't considered users vs. admins here. We planned to revisit the pricing anyway as part of a larger discussion in https://gitlab.com/gitlab-com/Product/-/issues/886 but this seems like the type of thing we could expedite given users should have access in GitLab Core as you point out
@mwoolf Should we create a new issue to make this change and see if we could squeeze that into %13.4? WDYT?
@mattgonzales It's a small change, so feel free to throw it in to %13.4.
Now that revoking via API is very very close to merging, can we also allow that to go through with a downgrade in %13.4 too? (tbh, it'll be easier to do them both in a single issue/MR)
@mattgonzales@mwoolf if it's a small change, is it anyway possible to squeeze this into 13.3? I'm thinking about our docs and the release post entry. It would be weird to say Ultimate in 13.3 and Core in 13.4. Just thinking out loud, not sure about your schedule!
It's @mattgonzales' call, but with 1 full day left in %13.3 I don't think it's likely we'll get it done in time. It would also rely on this MR being merged (which is approved except for a docs approval).
@mwoolf@axil We could also just postpone the feature block until %13.4 to avoid confusion. I'm ok with that and it wouldn't put undue pressure on us to ship another, albeit small, change in the short time we have left
@mattgonzales Thanks for tagging me on this. Will administrators be able to see the full Personal Access Token (PAT) records or a redacted version (ie that they exist, their expiration date, etc)?
@mushakov It would be a redacted version with the same/similar data was what currently exists in the credentials inventory. Our thinking was: typical convention here would be to provide this metadata as exposing the full PAT could be a security risk and it wasn't clear to us what value could be added by exposing the full credential