Command to create project and group access tokens

Problem to Solve

Sometimes it is necessary to create tokens for a project or group to perform certain actions. Currently there is no support for creating access tokens from glab.

Proposal

Add the option to create a project or group (personal access tokens are not supported) via command.

• project access tokens api
• group access tokens api

command structure should probably be:

glab token <action> --project/group

Created by: zemzale

Hey @ryanprior.

So GitLab doesn't support creating personal access tokens programmatically using the API, only using the rails console, which is not a thing we are gonna even try to do because that is for GitLab administration and it can mess up the whole GitLab instance if you do something wrong. See here and here

BUT we can support creating a group or project access tokens using the API which would scope the API to a specific group or project. See here and here. I don't know if this is sufficient for your needs, but this can be done.

@kerrizor a token scoped to a specific group or project (either way) would be sufficient and very handy for me. I use gitlab.com so the rails console option is out of the question for me anyhow.

Would you welcome an MR implementing this? I might be able to work on it some time this month.

Looks like @zemzale's comment was assigned to me during import..

changed the description

changed milestone to %Backlog

added [deprecated] Accepting merge requests cli devopscreate featureenhancement groupcode review sectiondev typefeature labels and removed enhancement label

changed title from Command to create a short-lived auth token to Command to create project and group access tokens

removed time estimate

removed [deprecated] Accepting merge requests label

I'm going to try and work on this in the next few days

Initial thoughts.

• glab token [--group gid] list
• glab token [--group gid] get <token-name>
• glab token [--group gid] revoke <token-name>
• glab token [--group gid] create --name <token-name> --expiry <date> --access-level <access_item>[,access_item>]... --scope <scope_item>[,<scope_item>]...

1. When --group is not present then it's assumed to be a project level access token (the current project)

2. access_item are descriptive strings rather than magic integers

3. Is it worth implementing a --user option for maintainers to manage personal access tokens?

4. What are the security implications of the list and get sub-commands for access tokens?

What say you all?

@alecthegeek Excited to see you in the project and this sounds great! A few thoughts:

Initial thoughts.

• glab token [--group gid] list
• glab token [--group gid] get <token-name>
• glab token [--group gid] revoke <token-name>
• glab token [--group gid] create --name <token-name> --expiry <date> --access-level <access_item>[,access_item>]... --scope <scope_item>[,<scope_item>]...

These make sense and follow the current convention

When --group is not present then it's assumed to be a project level access token (the current project)

This is reasonable, there's only a project and group API so that would be inline with how we've handled other commands for groups.

access_item are descriptive strings rather than magic integers

I'm conflicted here... we try to match the API as much as possible, but we do define what those numbers represent in the docs. Maybe it makes sense to accept both values in the command? WDYT?

Is it worth implementing a --user option for maintainers to manage personal access tokens?

AFAIK there isn't an API for personal access tokens... so I'm not sure what would even be possible here? Maybe an admin level API lets you adjust for other users?

What are the security implications of the list and get sub-commands for access tokens?

My quick read of the docs is that we don't actually provide the token value in the list or get commands. We only give you the token value when you create one... after that it's hidden forever.

Thanks for taking the time to reply @phikai

access_item are descriptive strings rather than magic integers

I'm conflicted here... we try to match the API as much as possible, but we do define what those numbers represent in the docs. Maybe it makes sense to accept both values in the command WDYT?

Both makes sense, not sure how easy that is to implement

The reason I am keen on supporting a descriptive string it to make scripts as self documenting as possible. It saves people having to look up the values in the docs if they are not familiar with that part of the API. Not so much when you are writing the script, but when you are reading it six months later.

Is it worth implementing a --user option for maintainers to manage personal access tokens?

AFAIK there isn't an API for personal access tokens...

Actually there is

https://docs.gitlab.com/ee/api/personal_access_tokens.html

However some thinking probably needs to occur on how we expose that on the CLI.

We do probably need to manage impersonation tokens.

https://docs.gitlab.com/ee/api/users.html#create-an-impersonation-token

Maybe Phase 2? Again some thought maybe required.

What are the security implications of the list and get sub-commands for access tokens?

My quick read of the docs is that we don't actually provide the token value in the list or get commands. We only give you the token value when you create one... after that it's hidden forever.

True dat. Forget I asked.

Now a personal opinion that is not directly related to this ticket

we try to match the API as much as possible

I'm not sure that is always a good idea.

The CLI tool UX should be focused around the use cases that make sense on the CLI and the way that a project admin would think about managing their projects. Hopefully there is a 75%+ overlap, but if it makes sense to "break" the API model then that should be OK?

Both makes sense, not sure how easy that is to implement

The reason I am keen on supporting a descriptive string it to make scripts as self documenting as possible. It saves people having to look up the values in the docs if they are not familiar with that part of the API. Not so much when you are writing the script, but when you are reading it six months later.

Yeah - I understand that, but then we have to maintain the relationship/documentation on our side vs. in the GitLab API documentation. So if GitLab changes what the string means or something else, it becomes extra work on our side to maintain that parity. Particularly I'm hedging around &4035 - which may make this more complicated in the future to maintain descriptive parity.

The CLI tool UX should be focused around the use cases that make sense on the CLI and the way that a project admin would think about managing their projects. Hopefully there is a 75%+ overlap, but if it makes sense to "break" the API model then that should be OK?

I agree. So far, I think most things match and what we've altered is really on the output side. I don't necessarily want to be in the business of duplicating slightly divergent documentation from the API. I think keeping the UX and workflows in mind makes sense, but we also want it to be familiar to what would happen if you used the API directly.

It's something we'll have to keep in mind, but I gave more details on why I hedged in this particular case.

@phikai I was going to make this part of the Hackathon later this month. Is that cool?

Separate question: should the issue be assigned to me?

Thanks

@alecthegeek Sure! I can take care of that. Looking forward to it.

assigned to @alecthegeek

Here are some useful notes and links

All about project and group token

https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html

https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html

API for project and group tokens

https://docs.gitlab.com/ee/api/project_access_tokens.html

https://docs.gitlab.com/ee/api/group_access_tokens.html

Compare and contrast with variables

https://docs.gitlab.com/ee/api/project_level_variables.html

https://docs.gitlab.com/ee/api/group_level_variables.html

API client lib

https://pkg.go.dev/github.com/xanzy/go-gitlab

API client Project Access Tokens

https://pkg.go.dev/github.com/xanzy/go-gitlab#ProjectAccessToken

API client Group Access Tokens

https://pkg.go.dev/github.com/xanzy/go-gitlab#GroupAccessToken

added documentation twtriaged labels

added UI text label

added 1 deleted label

All SUS-impacting issues need to have a proper severity label set. Please add a severity label, remove the automation:ux-missing-labels label, and then reply to this comment briefly explaining your reasoning for providing this severity.

If you are not the DRI for this area and would like help determining the best severity, please @ the appropriate person for assistance.

This message was generated automatically. You're welcome to improve it.

added automation:ux-missing-labels label

added severity4 label

removed automation:ux-missing-labels label

unassigned @alecthegeek

added 1 deleted label

mentioned in issue gitlab-ui#2553

removed 1 deleted label

mentioned in merge request !1577 (closed)

mentioned in merge request !1583 (closed)

@farodin91 We started roughly at the same time to create a PR for this issue.

I also have an implementation of the list and rotate command, and unit tests for the create and rotates. Perhaps we can cooperate on this feature?

Checkout !1583 (closed)

mentioned in merge request !1640 (merged)

mentioned in merge request !1641 (merged)

mentioned in merge request !1642 (merged)

mentioned in merge request !1643 (merged)

mentioned in commit 09c24006

closed with merge request !1640 (merged)