During my recent work on extending our GitLab packaging capabilities, I came across various types of tokens that can be used to authenticate users, services, and pipelines while using GitLab CI/CD. Each token has its unique features and use cases that can help ensure the security and integrity of your GitLab environment. By understanding the features and use cases of each token, you can leverage them to enhance your GitLab CI/CD workflows and ensure the security of your GitLab environment.
What are Personal Access Tokens?
Personal Access Tokens are one of the most common types of GitLab tokens. You can use them to authenticate users and provide secure access to GitLab. Personal Access Tokens can be created with different scopes, ranging from read-only access to full control over a user’s account. This allows users to create Personal Access Tokens with the appropriate level of access for their needs. Personal Access Tokens can also be revoked at any time, making them ideal for temporary authentication. If two-factor authentication is enabled, it is required to use these tokens to access the GitLab API. Create a Personal Access Token by going into your user’s personal settings and selecting “Access Tokens” from the left-hand menu.
How and when should I use Personal Access Tokens?
Personal Access Tokens should be used when you need to authenticate users and provide secure access to GitLab without revealing their password. They are ideal for use cases where your users or different services need to access GitLab APIs temporarily. For example, if you want to give a user read-only access to a specific repository, you can create a Personal Access Token with read-only access scoped to that repository.
Impersonation tokens?
Impersonation tokens are a special type of Personal Access Token that can be used to impersonate another user or service account. They provide a way to test GitLab features and troubleshoot issues without using the actual user’s credentials. You can use these tokens to automate tasks on behalf of other users or service accounts. Impersonation tokens have the same scope and permissions as the user or service account they impersonate, allowing you to perform actions on their behalf.
When creating an impersonation token, you can specify the user or service account that the token should impersonate. Impersonation tokens can also be created with a time limit, allowing you to provide temporary access to the impersonated user or service account.
You should only use impersonation tokens when necessary and you should tightly control their use. It is important that you restrict access to the impersonation token to only those who need it and to revoke the token when it is no longer needed. GitLab provides audit logs that allow administrators to track the usage of impersonation tokens and identify any potential misuse.
What are Project Access Tokens and Group Access Tokens?
Project Access Tokens are tokens that provide secure access to a specific GitLab project. You can create these with different scopes too, depending on the level of access required. The same applies to Group Access Tokens, just with a different scope – it provides access to a specific GitLab group. You can create them by selecting “Access Tokens” in the settings menu of either a group or a project in your GitLab environment.
How and when should I use Project Access Tokens and Group Access Tokens?
Project Access Tokens and Group Access Tokens should be used when you need to provide secure access to a specific GitLab project or group. They are ideal for use cases where your users or services need to perform actions within a project or a group without having full access to the GitLab environment. Project Access Tokens and Group Access Tokens can be created with different scopes, allowing you to create tokens with the appropriate level of access for your needs.
What are Deploy Tokens?
Deploy Tokens are used to authenticate automated deployments to GitLab independent of a user account. Use them to give your deployment tools or scripts access to GitLab repositories and perform deployments. Deploy Tokens are scoped to specific projects or groups, and they can have read-only or read-write access, depending on the level of access required for the deployment. Deploy Tokens are also limited in lifespan, and they can be revoked at any time. You can create them by going to either the project or the group setting and selecting “Deploy Tokens” from the left-hand menu.
How and when should I use Deploy Tokens?
They are ideal for use cases where you want to provide secure access to your repositories for deployment tools or scripts without them being tied to a user. You can use them to interact with repositories in groups or projects via git, but not with the GitLab API.
What are CI/CD Job Tokens?
CI/CD Job Tokens are tokens that are used to authenticate runners and jobs in your GitLab CI/CD pipeline. They are generated automatically by GitLab and are used to authenticate runners and jobs when they communicate with GitLab during the CI/CD process. CI/CD Job Tokens are specific to a single job and have a limited lifespan to enhance the security of your pipelines.
How and when should I use CI/CD Job Tokens?
The CI/CD Job Tokens have limited access to the GitLab API, you can extract information concerning the job, artifacts or even start a multi-project pipeline by using the CI/CD Job Token as authentification.
An example
The following is a command in which I use a Personal Access Token to get a list of repositories in a specific project, the Icinga packaging project in our GitLab.
curl --header "PRIVATE-TOKEN:<my-private-token>" https://git.icinga.com/api/v4/groups/packages/ | jq -r ".projects[].http_url_to_repo" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 81130 0 81130 0 0 98209 0 --:--:-- --:--:-- --:--:-- 98339 https://git.icinga.com/packages/icinga-x509.git https://git.icinga.com/packages/icinga-jira.git https://git.icinga.com/packages/icingaweb2-module-monitoring.git https://git.icinga.com/packages/icinga-selinux-common.git https://git.icinga.com/packages/icinga-l10n.git https://git.icinga.com/packages/icinga-php-thirdparty.git https://git.icinga.com/packages/icinga-reporting.git https://git.icinga.com/packages/icingadb-redis-selinux.git https://git.icinga.com/packages/icingadb-redis.git https://git.icinga.com/packages/icinga-php-common.git https://git.icinga.com/packages/icinga-generictts.git https://git.icinga.com/packages/icingadb.git https://git.icinga.com/packages/icinga-graphite.git https://git.icinga.com/packages/icinga-vsphere.git https://git.icinga.com/packages/icinga-php-incubator.git https://git.icinga.com/packages/icingaweb.git https://git.icinga.com/packages/icinga-cube.git https://git.icinga.com/packages/icinga2.git https://git.icinga.com/packages/icinga-php-library.git https://git.icinga.com/packages/icingadb-web.git https://git.icinga.com/packages/icinga-director.git
In this case, several of the tokens could have been used, I used a Personal Access Token, because it was readily available to me. Once my project is in production though, we will have switched to a Group Access Token, which is more reasonable – all of our packages are located in a single GitLab group.
