SonarQube Server
Understanding token types in SonarQube Server
This course explains the different types of tokens in SonarQube and how they're used for authentication and automation. You'll learn how these secure, string-based credentials function as digital keys for various SonarQube interactions, including running analyses and using Web API.
Transcript
(music) (pulse) Welcome! SonarQube utilizes various types of tokens for different authentication and authorization purposes, primarily for running analyses. These tokens also allow you to interact with its web services, such as the Web API. Let’s get started. In this video, you'll learn about the different types of SonarQube tokens and when to use each one. So, what are SonarQube tokens? SonarQube tokens work like special digital keys. They are secure, string-based credentials that allow your CI/CD pipeline to authenticate with SonarQube without needing your username and password. Tokens are essential for security and automation, and can be revoked if compromised or invalidated by expiration. There are three types of tokens in SonarQube: global analysis tokens, project analysis tokens, and user tokens. The global analysis token is the most powerful token of the three. It grants you, whether as a user or service account, permission to run an analysis on any project within your SonarQube instance. This token is an ideal choice for centralized CI/CD configurations, where a single pipeline template is used by administrators to analyze many different projects across an entire organization. Next, we have the project analysis token. This type of token is scoped to a single, specific project. It only grants permission to run an analysis on the project for which it was created. Using this token for project-specific CI/CD pipelines is a best practice, as it provides a higher level of security by limiting the token's access to just one project. For most automated CI/CD needs, a project analysis token is recommended. Finally, there's the user token. A user token is associated with your personal user account and has the same permissions as you. It’s primarily used for your own specific actions, such as running a manual analysis or invoking web services. While you can use a user token for automation, a project or global analysis token is often the more secure choice for CI/CD because you can limit its permissions and lifespan. When you create a token, you can configure its specific characteristics. For example, you can set an expiration date, which improves security by ensuring they’re regularly rotated. You can also configure the token permissions, depending on the type of token you select and the permissions of the person who generated it. In general, it's recommended to use the token with the least amount of permission necessary for the task at hand. By choosing the right token, you ensure both the security of your instance and the efficiency of your automated workflows. To summarize, let's look at the key differences between tokens: The global analysis token is for all projects, and it's best for centralized CI/CD. The project analysis token is for a single project, and it's the recommended, most secure choice for project-specific pipelines. The user token is for a user's permissions, and it's best for manual actions. And, that's it! See our additional videos to dive deeper into other Sonar topics!