Security features

Overview

SonarQube Community Build comes with a number of global security features:

• On-board authentication and authorization mechanisms.
• The ability to force users to authenticate before they can see any part of a SonarQube Community Build instance.
• The ability to delegate to authentication (for more see Authentication).

Additionally, you can configure at a group or user level who can:

• See that a project even exists.
• Access a project's source code.
• Administer a project (set exclusion patterns, tune plugin configuration for that project, etc.).
• Administer Quality Profiles, Quality Gates, and the SonarQube Community Build instance itself.

Another aspect of security is the encryption of settings such as passwords. SonarQube Community Build provides a built-in mechanism to encrypt settings.

Authentication

By default, SonarQube Community Build forces user authentication. You can disable forced user authentication, and allow anonymous users to browse projects and run analyses in your instance. To do this, log in as a system administrator, go to Administration > Configuration > General Settings > Security, and disable the Force user authentication property.

Disabling the Force user authentication can expose your SonarQube Community Build instance to security risks. We strongly recommend forcing user authentication on production instances or carefully configuring the security (user permissions, project visibility, etc.) on your instance.

API endpoints authentication

If the Force user authentication property is set to false, the following API endpoints are accessible without authentication (click API endpoints below to expand the list):

We advise keeping Force user authentication enabled if you have your SonarQube Community Build instance publicly accessible.

Authentication mechanisms

Authentication can be managed through a number of mechanisms:

• Via the SonarQube Community Build built-in users/groups database.
• Via several delegated authentication method, see the Authentication and Provisioning section for more information

Technical users

When you create a user in SonarQube Community Build's own database, it is considered local and will only be authenticated against SonarQube Community Build's own user/group database rather than against any external tool (LDAP, Active Directory, Crowd, etc.). By default, admin is a local account.

Similarly, all non-local accounts will be authenticated only against the external tool.

An Administrator can manage tokens on a user's behalf via Administration > Security > Users. From here, click in the user's Tokens column to see the user's existing tokens, and either revoke existing tokens or generate new ones. An Administrator can only create user tokens on behalf of another user. Once established, a token is the only credential needed to run an analysis. Tokens should be passed as the value of the sonar.token property.

See Authentication for details on revoking tokens for deactivated users and deleting personal user information.

Token maximum lifetime

The ability to configure a maximum lifetime for tokens is available starting in Enterprise Edition.

An Administrator can define a maximum lifetime for any newly generated token. Non-administrator users can also set a time-to-live, as long as it is less than or equal to the maximum lifetime set by the administrator. Tokens generated after updating this setting will expire either at the maximum lifetime set by the administrator or at the time set by the user, whichever comes first. 

Important note: Updating this setting does not affect any existing tokens. It will only impact newly generated tokens.

Default admin credentials

When installing SonarQube Community Build, a default user with Administer System permission is created automatically:

• Login: admin
• Password: admin

Reinstating admin access

If by mistake, you have no users able to access SonarQube Community Build with the global ‘Administer system’ permission level, you must re-grant the ‘Administer system’ permission to an existing, active user with the following query (myLogin in the query sample represents the login of the user who should become a system administrator):

insert into user_roles(uuid, user_uuid, role)
values ('random-uuid', (select uuid from users where login='mylogin'), 'admin');

If you changed and then lost the password to the local admin account or deactivated this user, you can activate the user and reset the password using the following query, depending on the database engine:

PostgreSQL and Microsoft SQL Server

update users set
crypted_password='100000$t2h8AtNs1AlCHuLobDjHQTn9XppwTIx88UjqUm4s8RsfTuXQHSd/fpFexAnewwPsO6jGFQUv/24DnO55hY6Xew==',
salt='k9x9eN127/3e/hf38iNiKwVfaVk=',
hash_method='PBKDF2',
reset_password='true',
user_local='true',
active='true'
where login='admin';

Oracle

update users set
crypted_password='100000$t2h8AtNs1AlCHuLobDjHQTn9XppwTIx88UjqUm4s8RsfTuXQHSd/fpFexAnewwPsO6jGFQUv/24DnO55hY6Xew==',
salt='k9x9eN127/3e/hf38iNiKwVfaVk=',
hash_method='PBKDF2',
reset_password=1,
user_local=1,
active=1
where login='admin';

Authorization

The way authorization is implemented in SonarQube Community Build is pretty standard. It is possible to create as many users and groups of users as needed. The users can then be attached (or not) to (multiple) groups. Groups and/or users are then given (multiple) permissions. The permissions grant access to projects, services, and functionalities.

To administer groups and users, choose Administration > Security, and use the sub-menu items.

For details about linking groups from your ALM service to SonarQube Community Build, see the SonarQube Community Build documentation on group synchronization.

User

Multiple integrations that allow the delegation of authentication are available (see the Plugin version matrix), but you can manually create and edit users at Settings > Security > Users. For manually-created users, login and password can be set at creation. Manually-created users can edit their passwords.

During both user creation and editing, you can set an account's screen name and email address. User login and email address will be implicitly recognized as SCM accounts if applicable, but you can set additional SCM accounts explicitly.

Group

A group is a set of users.

To administer groups, go to Administration > Security > Groups.

To edit the membership of a group, click the icon next to the membership total.

Two groups have a special meaning:

• Anyone is a group that exists in the system, but that cannot be managed. Every user belongs to this group, including anonymous users.
• sonar-users is the default group to which users are automatically added.

Global permissions

To set global permissions, log in as a System administrator and go to Administration > Security > Global Permissions.

• Administer System: All administration functions for the instance: global configuration.
• Administer Quality Profiles: Any action on quality profiles, including delegating permissions to specific Quality Profiles.
• Administer Quality Gates: Any action on quality gates, including delegating permissions to specific quality gates.
• Execute Analysis: Access to all settings required to perform analysis and the ability to push analysis results to the SonarQube Community Build. This includes private project settings but excludes secured settings like passwords.
• Create Projects: Initialize the structure of a new project before its first analysis. This permission is also required when doing the very first analysis of a project that has not already been created via the GUI.
• Create Applications: Create a new Application. 
• Create Portfolios: Create a new Portfolio.

Users with any explicit create permission will see a + item in the top menu giving access to these functions. If these permissions are removed from global administrators, they will lose quick access to them via the + menu, but retain access to creation via the Administration menu.

Creating an item does not automatically grant rights to administer it. For that, see Creators permission below.

Project permissions

Project permissions are available from the project-level Administration menu: Project Settings > Permissions.

Project visibility may be toggled between public and private. Making a project private hides its source code and measures from the Anyone group. 

By default, any newly created project will be public. It means every SonarQube Community Build user, authenticated or not, will be able to:

• Browse: Access a project, browse its measures and issues, and perform some issue edits (see Issues).
• See Source Code: View the project's source code.

If you want to be sure only a limited list of groups and users can see the project, you need to mark it Private. Once a project is private you will be able to define which groups and users can Browse the project or See Source Code.

If you want all newly created projects to be private, you can change the default visibility in Administration > Projects > Management.

For both public and private projects, four different permissions can be set:

• Administer Issues: Mark issues as accepted or false positives (users also need Browse permission).
• Administer Security Hotspots: Change the status of a Security Hotspot.
• Administer: Access project settings and perform administration tasks (users also need Browse permission).
  By default, a user with this Administer permission can manage both configuration and permissions for the current project. To only allow project administrators to update the project configuration, go to Administration > Configuration > General Settings > Security and disable the Enable permission management for project administrators property.
• Execute Analysis: Access to all settings required to perform analysis and the ability to push analysis results to the SonarQube Community Build. This includes private project settings but excludes secured settings like passwords.

Private projects have two additional permissions:

• Browse: Access a project; browse its measures, issues, and Security Hotspots; perform some issue edits (confirm/resolve/reopen, assignment, comment); comment on or change the user assigned to a Security Hotspot.
• See Source Code: View the project's source code.

Note that permissions are not cumulative. For instance, if you want to be able to administer the project, you also have to be granted the Browse permission to be able to access the project (which is the default for public projects).

You can either manually grant permissions for each project to some users and groups or apply permission templates to projects.

Permission templates for default permissions

SonarQube Community Build ships with a default permissions template, which automatically grants specific permissions to certain groups when a project, portfolio, or application is created. See Managing project-related permissions through templates in Managing permissions.

Settings encryption

Encryption is mostly used to remove clear passwords from settings (database or SCM credentials for instance). The implemented solution is based on a symmetric key algorithm. The key point is that the secret key is stored in a secured file on disk. This file must be owned by and readable only by the system account that runs the SonarQube Community Build.

The encryption algorithm used is AES with 256-bit keys.

Generate the secret key

A unique secret key must be shared between all parts of the SonarQube Community Build infrastructure. To generate it, go to Administration > Configuration > Encryption and click on the Generate Secret Key button.

Store the secret key on the SonarQube Community Build

• Copy the generated secret key to a file on the machine hosting the SonarQube Community Build. The default location is ~/.sonar/sonar-secret.txt. If you want to store it somewhere else, set its path through the sonar.secretKeyPath property in <sonarqubeHome>/conf/sonar.properties.
• Restrict file permissions to the account running the SonarQube Community Build (ownership and read-access only).
• Restart your SonarQube Community Build.

Generate the encrypted values of your settings

Go back to Administration > Configuration > Encryption and use the form that has been added to the interface to generate encrypted versions of your values.

Use the encrypted values in your SonarQube Community Build configuration

Encrypted values can either be set in SonarQube Community Build or copied into <sonarqubeHome>/conf/sonar.properties

sonar.jdbc.password={aes-gcm}CCGCFg4Xpm6r+PiJb1Swfg==  # Encrypted DB password
...
sonar.secretKeyPath=C:/path/to/my/secure/location/my_secret_key.txt