Skip to main content

Authentication

note

This functionality is available starting from version 0.10.0. Make sure to upgrade before you use this.

Authentication Providers#

Pyroscope server has a built-in user authentication system with support for external providers. By default, user authentication is disabled.

Internal authentication provider implements login-password authentication mechanism based on JSON Web Tokens using the internal database.

Supported Authentication Providers#

The list of external authentication providers includes:

Pyroscope also supports an internal authentication provider as well.

When the internal authentication provider is enabled, administrators can also allow users to sign up. On successful authentication with an external provider, user accounts are created in the internal database automatically, and administrators are able to manage them. By default, users are granted ReadOnly role on sign up, which can be changed in the server configuration.

Pyroscope Server has a built-in admin user with administrative permissions: the account is being created during the first launch and this can be altered by changing the configuration options. Please refer to the internal authentication provider documentation.

note

Users signed up via OAuth providers are not allowed to use password authentication.

Below you can see available configuration options and their default values.

auth:  # Specifies which role will be granted to a newly signed up user.  # Supported roles: Admin, ReadOnly. Defaults to ReadOnly.  # The parameter affects all authentication providers.  signup-default-role: ReadOnly
  # Specifies SameSite attribute for the JWT token cookie.  # Supported values: Lax, Strict, None. Default to Lax.  cookie-same-site: Lax
  # Specifies Secure attribute for the JWT token cookie.  # If cookie-same-site is set to None, Secure attribute  # will be set automatically. Default to false.  cookie-secure: false
  # JWT signing string. Generated at provisioning if not specified explicitly.  jwt-secret: ""
  # Amount of days after which user will be logged out. 0 means non-expiring.  login-maximum-lifetime-days: 0
  # Data ingestion authentication options.  ingestion:    enabled: false
  # Internal authentication provider settings.  internal:    enabled: false
  # Google OAuth2 authentication settings.  google:    enabled: false
  # Github OAuth2 authentication settings.  github:    enabled: false
  # Gitlab OAuth2 authentication settings.  gitlab:    enabled: false

The options can be also specified via CLI flags or environment variables. See the server configuration page for more details on the Pyroscope configuration.

note

Pyroscope Server stores user authentication tokens in Cookies. Be default, the cookie is attributed with SameSite: Lax value meaning that it is not sent on normal cross-site subrequests (for example to load images or frames into a third party site), but is sent when a user is navigating to the origin site (i.e., when following a link). This ensures that users have reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks.

You can configure auth.cookie-same-site parameter to override this.

Please see the documentation to learn more.

Generate an API Key#

When one of the authentication providers is configured, API clients should provide an authentication token. You can generate it via the UI, if you have Admin role. For more details check API key docs.

image

Authenticate Agents with an API Key#

Pyroscope Server can be configured to require authentication from the agents ingesting data in the push mode. By default, anyone can send data to Pyroscope Server without any authentication. for more details check API key docs.

Migrating From Previous Versions#

In versions before 0.10.0, Pyroscope Server only supported OAuth providers and had no concept of user management. If you already use OAuth authentication providers, after upgrading to 0.10.0, by default you will be granted ReadOnly role that does not allow you managing Users and API keys:

  1. If you only use OAuth providers, we recommend you to change auth.signup-default-role to Admin at the first launch. Alternatively, you can enable the internal authentication provider via the auth.internal.enabled option, log in using the default admin credentials, and grant Admin role to eligible users.

  2. If you decided to enable the internal authentication provider and allow users to signup via the auth.internal.signup-enabled option, we strongly recommend you to set auth.signup-default-role to ReadOnly (the default value).