Manage Chronograf security
To enhance security, configure Chronograf to authenticate and authorize with OAuth 2.0 and use TLS/HTTPS. (Basic authentication with username and password is also available.)
- Configure Chronograf to authenticate with OAuth 2.0
- Configure Chronograf to authenticate with a username and password
- Configure TLS (Transport Layer Security) and HTTPS
Configure Chronograf to authenticate with OAuth 2.0
After configuring OAuth 2.0, the Chronograf Admin tab becomes visible. You can then set up multiple organizations and users.
Configure Chronograf to use an OAuth 2.0 provider and JWT (JSON Web Token) to authenticate users and enable role-based access controls.
(For more details on OAuth and JWT, see RFC 6749 and RFC 7519.)
OAuth PKCE
OAuth configurations in Chronograf 1.9+ use OAuth PKCE to mitigate the threat of having the authorization code intercepted during the OAuth token exchange. OAuth integrations that do no currently support PKCE are not affected.
To disable OAuth PKCE and revert to the previous token exchange, use the
--oauth-no-pkce
Chronograf configuration option
or set the OAUTH_NO_PCKE
environment variable to true
.
Generate a Token Secret
To configure any of the supported OAuth 2.0 providers to work with Chronograf,
you must configure the TOKEN_SECRET
environment variable (or command line option).
Chronograf will use this secret to generate the JWT Signature for all access tokens.
-
Generate a high-entropy pseudo-random string.
For example, to do this with OpenSSL, run this command:
openssl rand -base64 256 | tr -d '\n'
-
Set the environment variable:
TOKEN_SECRET=<mysecret>
InfluxDB Enterprise clusters: If you are running multiple Chronograf servers in a high availability configuration,
set the TOKEN_SECRET
environment variable on each server to ensure that users can stay logged in.
JWKS Signature Verification (optional)
If the OAuth provider implements OpenID Connect with RS256 signatures, you need to enable this feature with the USE_ID_TOKEN
variable
and provide a JSON Web Key Set (JWKS) document (holding the certificate chain) to validate the RSA signatures against.
This certificate chain is regularly rolled over (when the certificates expire), so it is fetched from the JWKS_URL
on demand.
Example:
export USE_ID_TOKEN=true
export JWKS_URL=https://example.com/adfs/discovery/keys
Set configurations for your OAuth provider
To enable OAuth 2.0 authorization and authentication in Chronograf, you must set configuration options that are specific for the OAuth 2.0 authentication provider you want to use.
Configuration steps for the following supported authentication providers are provided in these sections below:
- GitHub
- Auth0
- Heroku
- Okta
- Gitlab
- Azure Active Directory
- Bitbucket
- Configure Chronograf to use any OAuth 2.0 provider
If you haven’t already, you must first generate a token secret before proceeding.
Configure GitHub authentication
-
Follow the steps to Register a new OAuth application on GitHub to obtain your Client ID and Client Secret. On the GitHub application registration page, enter the following values:
- Homepage URL: the full Chronograf server name and port.
For example, to run the application locally with default settings, set the this URL to
http://localhost:8888
. - Authorization callback URL: the Homepage URL plus the callback URL path
/oauth/github/callback
(for example,http://localhost:8888/oauth/github/callback
).
- Homepage URL: the full Chronograf server name and port.
For example, to run the application locally with default settings, set the this URL to
-
Set the Chronograf environment variables with the credentials provided by GitHub:
export GH_CLIENT_ID=<github-client-id> export GH_CLIENT_SECRET=<github-client-secret> # If using Github Enterprise export GH_URL=https://github.custom-domain.com
-
If you haven’t already, set the Chronograf environment with your token secret:
export TOKEN_SECRET=Super5uperUdn3verGu355!
Alternatively, set environment variables using the equivalent command line options:
For details on the command line options and environment variables, see GitHub OAuth 2.0 authentication options.
GitHub organizations (optional)
To require GitHub organization membership for authenticating users, set the GH_ORGS
environment variable with the name of your organization.
export GH_ORGS=biffs-gang
If the user is not a member of the specified GitHub organization, then the user will not be granted access. To support multiple organizations, use a comma-delimited list.
export GH_ORGS=hill-valley-preservation-sociey,the-pinheads
When logging in for the first time, make sure to grant access to the organization you configured. The OAuth application can only see membership in organizations it has been granted access to.
Example GitHub OAuth configuration
# Github Enterprise base URL
export GH_URL=https://github.mydomain.com
# GitHub Client ID
export GH_CLIENT_ID=b339dd4fddd95abec9aa
# GitHub Client Secret
export GH_CLIENT_SECRET=260041897d3252c146ece6b46ba39bc1e54416dc
# Secret used to generate JWT tokens
export TOKEN_SECRET=Super5uperUdn3verGu355!
# Restrict to specific GitHub organizations
export GH_ORGS=biffs-gang
Configure Google authentication
-
Follow the steps in Obtain OAuth 2.0 credentials to obtain the required Google OAuth 2.0 credentials, including a Google Client ID and Client Secret, by
-
Verify that Chronograf is publicly accessible using a fully-qualified domain name so that Google can properly redirect users back to the application.
-
Set the Chronograf environment variables for the Google OAuth 2.0 credentials and Public URL used to access Chronograf:
export GOOGLE_CLIENT_ID=812760930421-kj6rnscmlbv49pmkgr1jq5autblc49kr.apps.googleusercontent.com export GOOGLE_CLIENT_SECRET=wwo0m29iLirM6LzHJWE84GRD export PUBLIC_URL=http://localhost:8888
-
If you haven’t already, set the Chronograf environment with your token secret:
export TOKEN_SECRET=Super5uperUdn3verGu355!
Alternatively, the environment variables discussed above can be set using their corresponding command line options:
For details on Chronograf command line options and environment variables, see Google OAuth 2.0 authentication options.
Optional Google domains
Configure Google authentication to restrict access to Chronograf to specific domains.
Set the GOOGLE_DOMAINS
environment variable or the --google-domains
command line option.
Separate multiple domains using commas.
For example, to permit access only from biffspleasurepalace.com
and savetheclocktower.com
, set the environment variable as follows:
export GOOGLE_DOMAINS=biffspleasurepalace.com,savetheclocktower.com
Configure Auth0 authentication
See OAuth 2.0 for details about the Auth0 implementation.
-
Set up your Auth0 account to obtain the necessary credentials.
- From the Auth0 user dashboard, click Create Application.
- Choose Regular Web Applications as the type of application and click Create.
- In the Settings tab, set Token Endpoint Authentication to None.
- Set Allowed Callback URLs to
https://www.example.com/oauth/auth0/callback
(substitutingexample.com
with thePUBLIC_URL
of your Chronograf instance) - Set Allowed Logout URLs to
https://www.example.com
(substitutingexample.com
with thePUBLIC_URL
of your Chronograf instance)
-
Set the Chronograf environment variables based on your Auth0 client credentials:
AUTH0_DOMAIN
(Auth0 domain)AUTH0_CLIENT_ID
(Auth0 Client ID)AUTH0_CLIENT_SECRET
(Auth0 client Secret)PUBLIC_URL
(Public URL, used in callback URL and logout URL above)
-
If you haven’t already, set the Chronograf environment with your token secret:
export TOKEN_SECRET=Super5uperUdn3verGu355!
Alternatively, the environment variables discussed above can be set using their corresponding command line options:
Auth0 organizations (optional)
Auth0 can be customized to the operator’s requirements, so it has no official concept of an “organization.”
Organizations are supported in Chronograf using a lightweight app_metadata
key that can be inserted into Auth0 user profiles automatically or manually.
To assign a user to an organization, add an organization
key to the user app_metadata
field with the value corresponding to the user’s organization.
For example, you can assign the user Marty McFly to the “time-travelers” organization by setting app_metadata
to {"organization": "time-travelers"}
.
This can be done either manually by an operator or automatically through the use of an Auth0 Rule or a pre-user registration Auth0 Hook.
Next, you will need to set the Chronograf AUTH0_ORGS
environment variable to a comma-separated list of the allowed organizations.
For example, if you have one group of users with an organization
key set to biffs-gang
and another group with an organization
key set to time-travelers
, you can permit access to both with this environment variable: AUTH0_ORGS=biffs-gang,time-travelers
.
An --auth0-organizations
command line option is also available, but it is limited to a single organization and does not accept a comma-separated list like its environment variable equivalent.
Configure Heroku authentication
-
Obtain a client ID and application secret for Heroku by following the guide posted here.
-
Set the Chronograf environment variables based on your Heroku client credentials:
export HEROKU_CLIENT_ID=<client-id-from-heroku> export HEROKU_SECRET=<client-secret-from-heroku>
-
If you haven’t already, set the Chronograf environment with your token secret:
export TOKEN_SECRET=Super5uperUdn3verGu355!
Heroku organizations (optional)
To restrict access to members of specific Heroku organizations,
use the HEROKU_ORGS
environment variable (or associated command line option).
Multiple values must be comma-separated.
For example, to permit access from the hill-valley-preservation-society
organization and the-pinheads
organization,
use the following environment variable:
export HEROKU_ORGS=hill-valley-preservation-sociey,the-pinheads
Configure Okta authentication
-
Create an Okta web application by following the steps in the Okta documentation: Implement the Authorization Code Flow.
-
In the General Settings section, find the Allowed grant types listing and select only the Client acting on behalf of a user: Authorization Code option.
-
In the LOGIN section, set the *Login redirect URIs and Initiate login URI to
http://localhost:8888/oauth/okta/callback
(the default callback URL for Chronograf). -
Set the following Chronograf environment variables:
GENERIC_NAME=okta # The client ID is provided in the "Client Credentials" section of the Okta dashboard. GENERIC_CLIENT_ID=<okta_client_ID> # The client secret is in the "Client Credentials" section of the Okta dashboard. GENERIC_CLIENT_SECRET=<okta_client_secret> GENERIC_AUTH_URL=https://dev-553212.oktapreview.com/oauth2/default/v1/authorize GENERIC_TOKEN_URL=https://dev-553212.oktapreview.com/oauth2/default/v1/token GENERIC_API_URL=https://dev-553212.oktapreview.com/oauth2/default/v1/userinfo PUBLIC_URL=http://localhost:8888 TOKEN_SECRET=secretsecretsecret GENERIC_SCOPES=openid,profile,email
-
If you haven’t already, set the Chronograf environment with your token secret:
export TOKEN_SECRET=Super5uperUdn3verGu355!
Configure GitLab authentication
-
In your GitLab profile, create a new OAuth2 authentication service.
- Provide a name for your application, then enter your publicly accessible Chronograf URL with the
/oauth/gitlab/callback
path as your GitLab callback URL. (For example,http://<your_chronograf_server>:8888/oauth/gitlab/callback
.) - Click Submit to save the service details.
- Make sure your application has openid and read_user scopes.
- Provide a name for your application, then enter your publicly accessible Chronograf URL with the
-
Copy the provided Application Id and Secret and set the following environment variables:
In the examples below, note the use of
gitlab-server-example.com
andchronograf-server-example.com
in urls. These should be replaced by the actual URLs used to access each service.GENERIC_NAME="gitlab" GENERIC_CLIENT_ID=<gitlab_application_id> GENERIC_CLIENT_SECRET=<gitlab_secret> GENERIC_AUTH_URL="https://gitlab.com/oauth/authorize" GENERIC_TOKEN_URL="https://gitlab.com/oauth/token" TOKEN_SECRET=<mytokensecret> GENERIC_SCOPES="api,openid,read_user" PUBLIC_URL="http://<chronograf-host>:8888" GENERIC_API_URL="https://gitlab.com/api/v3/user"
The equivalent command line options are:
--generic-name=gitlab --generic-client-id=<gitlab_application_id> --generic-client-secret=<gitlab_secret> --generic-auth-url=https://gitlab.com/oauth/authorize --generic-token-url=https://gitlab.com/oauth/token --token-secret=<mytokensecret> --generic-scopes=openid,read_user --generic-api-url=https://gitlab.com/api/v3/user --public-url=http://<chronograf-host>:8888/
Configure Azure Active Directory authentication
-
Create an Azure Active Directory application. Note the following information:
<APPLICATION-ID>
,<TENANT-ID>
, and<APPLICATION-KEY>
. You’ll need these to define your Chronograf environment. -
Be sure to register a reply URL in your Azure application settings. This should match the calling URL from Chronograf. Otherwise, you will get an error stating no reply address is registered for the application. For example, if Chronograf is configured with a
GENERIC_NAME
value of AzureAD, the reply URL would behttp://localhost:8888/oauth/AzureAD/callback
. -
After completing the application provisioning within Azure AD, you can now complete the configuration with Chronograf. Using the metadata from your Azure AD instance, proceed to export the following environment variables:
Set the following environment variables in
/etc/default/chronograf
:GENERIC_TOKEN_URL=https://login.microsoftonline.com/<<TENANT-ID>>/oauth2/token TENANT=<<TENANT-ID>> GENERIC_NAME=AzureAD GENERIC_API_KEY=userPrincipalName GENERIC_SCOPES=openid GENERIC_CLIENT_ID=<<APPLICATION-ID>> GENERIC_AUTH_URL=https://login.microsoftonline.com/<<TENANT-ID>>/oauth2/authorize?resource=https://graph.windows.net GENERIC_CLIENT_SECRET=<<APPLICATION-KEY>> TOKEN_SECRET=secret GENERIC_API_URL=https://graph.windows.net/<<TENANT-ID>>/me?api-version=1.6 PUBLIC_URL=http://localhost:8888
Note: If you’ve configured TLS/SSL, modify the
PUBLIC_URL
to ensure you’re using HTTPS.
Configure Bitbucket authentication
- Complete the instructions to Use OAuth on Bitbucket Cloud, and include the following information:
- Callback URL: http://localhost:8888/oauth/bitbucket/callback
- Permissions: Account read, email
-
Run the following command to set Chronograf environment variables for Bitbucket in
/etc/default/chronograf
:export TOKEN_SECRET=... export GENERIC_CLIENT_ID=... export GENERIC_CLIENT_SECRET=... export GENERIC_AUTH_URL=https://bitbucket.org/site/oauth2/authorize export GENERIC_TOKEN_URL=https://bitbucket.org/site/oauth2/access_token export GENERIC_API_URL=https://api.bitbucket.org/2.0/user export GENERIC_SCOPES=account export PUBLIC_URL=http://localhost:8888 export GENERIC_NAME=bitbucket
Configure Chronograf to use any OAuth 2.0 provider
Chronograf can be configured to work with any OAuth 2.0 provider, including those defined above, by using the generic configuration options below. Additionally, the generic provider implements OpenID Connect (OIDC) as implemented by Active Directory Federation Services (AD FS).
When using the generic configuration, some or all of the following environment variables (or corresponding command line options) are required (depending on your OAuth 2.0 provider):
GENERIC_CLIENT_ID
: Application client identifier issued by the providerGENERIC_CLIENT_SECRET
: Application client secret issued by the providerGENERIC_AUTH_URL
: Provider’s authorization endpoint URLGENERIC_TOKEN_URL
: Provider’s token endpoint URL used by the Chronograf client to obtain an access tokenUSE_ID_TOKEN
: Enable OpenID id_token processingJWKS_URL
: Provider’s JWKS endpoint used by the client to validate RSA signaturesGENERIC_API_URL
: Provider’s OpenID UserInfo endpoint URL used by Chronograf to request user dataGENERIC_API_KEY
: JSON lookup key for OpenID UserInfo (known to be required for Microsoft Azure, with the valueuserPrincipalName
)GENERIC_SCOPES
: Scopes of user data required for your instance of Chronograf, such as user email and OAuth provider organization- Multiple values must be space-delimited, e.g.
user:email read:org
- These may vary by OAuth 2.0 provider
- Default value:
user:email
- Multiple values must be space-delimited, e.g.
PUBLIC_URL
: Full public URL used to access Chronograf from a web browser, i.e. where Chronograf is hosted- Used by Chronograf, for example, to construct the callback URL
TOKEN_SECRET
: Used to validate OAuth state response. (see above)
Optional environment variables
The following environment variables (and corresponding command line options) are also available for optional use:
GENERIC_DOMAINS
: Email domain where email address must include.GENERIC_NAME
: Value used in the callback URL in conjunction withPUBLIC_URL
, e.g.<PUBLIC_URL>/oauth/<GENERIC_NAME>/callback
- This value is also used in the text for the Chronograf Login button
- Default value is
generic
- So, for example, if
PUBLIC_URL
ishttps://localhost:8888
andGENERIC_NAME
is its default value, then the callback URL would behttps://localhost:8888/oauth/generic/callback
, and the Chronograf Login button would readLog in with Generic
- While using Chronograf, this value should be supplied in the
Provider
field when adding a user or creating an organization mapping.
Example: OIDC with AD FS
See Enabling OpenID Connect with AD FS 2016 for a walk through of the server configuration.
Exports for Chronograf (e.g. in /etc/default/chronograf
):
PUBLIC_URL="https://example.com:8888"
GENERIC_CLIENT_ID="chronograf"
GENERIC_CLIENT_SECRET="KW-TkvH7vzYeJMAKj-3T1PdHx5bxrZnoNck2KlX8"
GENERIC_AUTH_URL="https://example.com/adfs/oauth2/authorize"
GENERIC_TOKEN_URL="https://example.com/adfs/oauth2/token"
GENERIC_SCOPES="openid"
GENERIC_API_KEY="upn"
USE_ID_TOKEN="true"
JWKS_URL="https://example.com/adfs/discovery/keys"
TOKEN_SECRET="ZNh2N9toMwUVQxTVEe2ZnnMtgkh3xqKZ"
Do not use special characters for the GENERIC_CLIENT_ID
as AD FS may split strings at the special character, resulting in an identifier mismatch.
Troubleshoot OAuth errors
ERRO[0053]
A ERRO[0053] error indicates that a primary email is not found for the specified user. A user must have a primary email.
ERRO[0053] Unable to get OAuth Group malformed email address, expected "..." to contain @ symbol
Configure authentication duration
By default, user authentication remains valid for 30 days using a cookie stored in the web browser.
To configure a different authorization duration, set a duration using the AUTH_DURATION
environment variable.
Example:
To set the authentication duration to 1 hour, use the following shell command:
export AUTH_DURATION=1h
The duration uses the Go (golang) time duration format, so the largest time unit is h
(hours).
So to change it to 45 days, use:
export AUTH_DURATION=1080h
To require re-authentication every time the browser is closed, set AUTH_DURATION
to 0
.
This makes the cookie transient (aka “in-memory”).
Configure Chronograf to authenticate with a username and password
Chronograf can be configured to authenticate users by username and password (“basic authentication”). Turn on basic authentication access to restrict HTTP requests to Chronograf to selected users.
OAuth 2.0 is the preferred method for authentication. Only use basic authentication in cases where an OAuth 2.0 integration is not possible.
When using basic authentication, all users have SuperAdmin status; Chronograf authorization rules are not enforced. For more information, see Cross-organization SuperAdmin status.
To enable basic authentication, run chronograf with the --htpasswd
flag or use the HTPASSWD
environment variable.
chronograf --htpasswd <path to .htpasswd file>
The .htpasswd
file contains users and their passwords, and should be created with a password file utility tool such as apache2-utils
.
For more information about how to restrict access with basic authentication, see NGINX documentation on Restricting Access with HTTP Basic Authentication.
Configure TLS (Transport Layer Security) and HTTPS
The TLS (Transport Layer Security) cryptographic protocol is supported in Chronograf to provides server authentication, data confidentiality, and data integrity. Using TLS secures traffic between a server and web browser and enables the use of HTTPS.
InfluxData recommends using HTTPS to communicate securely with Chronograf applications. If you are not using a TLS termination proxy, you can run your Chronograf server with TLS connections.
Chronograf includes command line and environment variable options for configuring TLS (Transport Layer Security) certificates and key files. Use of the TLS cryptographic protocol provides server authentication, data confidentiality, and data integrity. When configured, users can use HTTPS to securely communicate with your Chronograf applications.
HTTPS helps prevent nefarious agents stealing the JWT and using it to spoof a valid user against the server.
Configure TLS for Chronograf
Chronograf server has command line and environment variable options to specify the certificate and key files. The server reads and parses a public/private key pair from these files. The files must contain PEM-encoded data.
All Chronograf command line options have corresponding environment variables.
To configure Chronograf to support TLS, do the following:
-
Specify the certificate file using the
TLS_CERTIFICATE
environment variable or the--cert
CLI option. -
Specify the key file using the
TLS_PRIVATE_KEY
environment variable or--key
CLI option.If both the TLS certificate and key are in the same file, specify them using the
TLS_CERTIFICATE
environment variable (or the--cert
CLI option). -
(Optional) To specify which TLS cipher suites to allow, use the
TLS_CIPHERS
environment variable or the--tls-ciphers
CLI option. Chronograf supports all cipher suites in the Gocrypto/tls
package and, by default, allows them all. -
(Optional) To specify the minimum and maximum TLS versions to allow, use the
TLS_MIN_VERSION
andTLS_MAX_VERSION
environment variables or the--tls-min-version
and--tls-max-version
CLI options. By default, the minimum TLS version allowed istls1.2
and the maximum version is unlimited.
Example with CLI options
chronograf \
--cert=my.crt \
--key=my.key \
--tls-ciphers=TLS_RSA_WITH_AES_256_CBC_SHA,TLS_AES_128_GCM_SHA256 \
--tls-min-version=tls1.2 \
--tls-max-version=tls1.3
Example with environment variables
TLS_CERTIFICATE=my.crt \
TLS_PRIVATE_KEY=my.key \
TLS_CIPHERS=TLS_RSA_WITH_AES_256_CBC_SHA,TLS_AES_128_GCM_SHA256 \
TLS_MIN_VERSION=tls1.2 \
TLS_MAX_VERSION=tls1.3 \
chronograf
Docker example with environment variables
docker run \
-v /host/path/to/certs:/certs \
-e TLS_CERTIFICATE=/certs/my.crt \
-e TLS_PRIVATE_KEY=/certs/my.key \
-e TLS_CIPHERS=TLS_RSA_WITH_AES_256_CBC_SHA,TLS_AES_128_GCM_SHA256 \
-e TLS_MIN_VERSION=tls1.2 \
-e TLS_MAX_VERSION=tls1.3 \
chronograf:1.10
Test with self-signed certificates
To test your setup, you can use a self-signed certificate.
Don’t use self-signed certificates in production environments.
To create a certificate and key in one file with OpenSSL:
openssl req -x509 -newkey rsa:4096 -sha256 -nodes -keyout testing.pem -out testing.pem -subj "/CN=localhost" -days 365
Next, set the environment variable TLS_CERTIFICATE
:
export TLS_CERTIFICATE=$PWD/testing.pem
Run Chronograf:
./chronograf
INFO[0000] Serving chronograf at https://[::]:8888 component=server
In the first log message you should see https
rather than http
.
Was this page helpful?
Thank you for your feedback!
Support and feedback
Thank you for being part of our community! We welcome and encourage your feedback and bug reports for Chronograf and this documentation. To find support, use the following resources: