Authentication
note
This functionality is available starting from version 0.10.0. Make sure to upgrade before you use this.
#
Authentication ProvidersPyroscope 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 ProvidersThe 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 KeyWhen 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.
#
Authenticate Agents with an API KeyPyroscope 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 VersionsIn 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:
If you only use OAuth providers, we recommend you to change
auth.signup-default-role
toAdmin
at the first launch. Alternatively, you can enable the internal authentication provider via theauth.internal.enabled
option, log in using the defaultadmin
credentials, and grantAdmin
role to eligible users.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 setauth.signup-default-role
toReadOnly
(the default value).