Skip to main content
Version: 3.2

Authentication

User authentication in LogStream


Cribl LogStream supports local, Splunk, LDAP, and SSO/OpenID Connect authentication methods, depending on license type.

Local Authentication

To set up local authentication, navigate to global ⚙️ Settings (lower left) > Access Management > Authentication and select Local.

You can then manage users through the global ⚙️ Settings (lower left) > Access Management > Local Users UI. All changes made to users are persisted in a file located at $CRIBL_HOME/local/cribl/auth/users.json.

This is the line format, and note that both usernames and passwords are case-sensitive:

{"username":"user","first":"Elvis","last":"Bath","disabled":"false", "passwd":"Yrt0MOD1w8OzyMYB8WMcEleOtYESMwZw2qIZyTvueOE"}

The file is monitored for modifications every 60s, and will be reloaded if changes are detected.

Adding users through direct modification of the file is also supported, but not recommended.

If you edit users.json, maintain each JSON element as a single line. Otherwise, the file will not reload properly.

Manual Password Replacement

To manually add, change, or restore a password, replace the affected user's passwd key-value pair with a password key, in this format: "password":"<newPlaintext>". LogStream will hash all plaintext password(s), identified by the password key, during the next file reload, and will rename the plaintext password key.

Starting with the same users.json line above:

{"username":"user","first":"Elvis","last":"Bath","disabled":"false", "passwd":"Yrt0MOD1w8OzyMYB8WMcEleOtYESMwZw2qIZyTvueOE"}

...you'd modify the final key-value pair to something like:

{"username":"user","first":"Elvis","last":"Bath","disabled":"false", "password":"V3ry53CuR&pW9"}

Within at most one minute after you save the file, LogStream will rename the password key back to passwd, and will hash its value, re-creating something resembling the original example.

Set Worker Passwords

In a distributed deployment, once a Worker has been set to point to the Leader Node, LogStream will set each Worker Node's admin password with a randomized password that is different from the admin user's password on the Leader Node. This is by design, as a security precaution. But it might lead to situations where administrators cannot log into a Worker Node directly, and must rely on accessing them via the Leader.

To explicitly apply a known/new password to your Worker Node, you set and push a new password to the Worker Group. Here's how, in the Leader Node's UI:

  1. From the left nav, select Groups.
  2. Select the desired Worker Group.
  3. From the Group's top nav, select Settings (upper right).
  4. Select Local Users, then expand the desired user.
  5. Update the Password field and select Save.

Every 10 seconds, the Worker Nodes will request an update of configuration from the Leader, and any new password settings will be included.

Authentication Controls

You can customize authentication behavior at global ⚙️ Settings (lower left) > General Settings > API Server Settings > Advanced. The options here include:

  • Logout on Roles change: If role-based access control is enabled, determines whether users are automatically logged out of LogStream when their assigned Roles change. Defaults to Yes.

  • Auth-token TTL: Sets authentication tokens' valid lifetime, in seconds. Defaults to 3600 (60 minutes).

  • Login rate limit: Sets the number of login attempts allowed over a (selectable) unit of time. Defaults to 2/second.

  • HTTP header: Enables you to specify one or more custom HTTP headers to be sent with every response.

Token Renewal and Session Timeout

Here is how LogStream sets tokens' valid lifetime by applying the Auth-token TTL field's value:

  • When a user logs in, LogStream returns a token whose expiration time is set to {login time + Auth‑token TTL value}.

  • If the user is idle (no UI activity) for the configured token lifetime, they are logged out.

  • As long as the user is interacting with LogStream's UI in their browser, LogStream continually renews the token, resetting the idle-session time limit back by the Auth‑token TTL value.

The cribl.secret File

When Cribl LogStream first starts, it creates a $CRIBL_HOME/local/cribl/auth/cribl.secret file. This file contains a key that is used to generate auth tokens for users, encrypt their passwords, and encrypt encryption keys.

Default local credentials are: admin/admin

Back up and secure access to this file by applying strict permissions – e.g., 600.

External Authentication

Below are configuration details for the following external authentication providers:

All of these external auth methods are supported with either an Enterprise or a Standard license, but not with a Free or One license.

Note that LogStream Roles and role mapping are supported only with an Enterprise license. With a Standard license, all your external users will be imported to LogStream in the admin role.

Splunk Authentication

Splunk authentication is very helpful when deploying in the same environment as Splunk, and requires the user to have Splunk admin role permissions. To set up Splunk authentication:

Navigate to global ⚙️ Settings (lower left) > Access Management > Authentication > Type and select Splunk.

  • Host: Splunk hostname (typically a search head).

  • Port: Splunk management port (defaults to 8089).

  • SSL: Whether SSL is enabled on Splunk instance that provides authentication. Defaults to Yes.

  • Fallback on fatal error: Attempt local authentication if Splunk authentication is unsuccessful. Defaults to No. If toggled to Yes, local auth will be attempted only after a failed Splunk auth. Selecting Yes also exposes this additional option:

    • Fallback on bad login: Attempt local authentication if the supplied user/password fails to log in on Splunk. Defaults to No.

The Splunk searchhead does not need to be locally installed on the LogStream instance. See also Role Mapping below.

LDAP Authentication

LDAP authentication is supported, and can be set up as follows:

Navigate to global ⚙️ Settings (lower left) > Access Management > Authentication > Type, and select LDAP.

  • Secure: Enable to use a secure LDAP connections (ldaps://). Disable for an insecure (ldap://) connection.

  • LDAP servers: List of LDAP servers. Each entry should contain host:port (e.g., localhost:389).

  • Bind DN: Distinguished name of entity to authenticate with LDAP server. E.g., 'cn=admin,dc=example,dc=org'.

  • Password: Distinguished Name password used to authenticate with LDAP server.

  • User search base: Starting point to search LDAP for users, e.g., 'dc=example,dc=org'.

  • Username field: LDAP user search field, e.g., cn or (cn (or uid). For Microsoft Active Directory, use sAMAccountName here.

  • User search filter: LDAP search filter to apply when finding user, e.g., (&(group=admin)(!(department=123*))). Optional.

  • Group search base: Starting point to search LDAP for groups, e.g., dc=example,dc=org. Optional.

  • Group member field: LDAP group search field, e.g., member. Optional.

  • Group search filter: LDAP search filter to apply when finding group, e.g., (&(cn=cribl*)(objectclass=group)). Optional.

  • Group name field: Attribute used in objects' DNs that represent the Group name, e.g., cn. This attribute from group objects is not read directly, instead it must be present in your groups' DN values. Case must be preserved when specifying the attribute name in this field. Some attribute names may contain mixed case while others may be all uppercase when appearing in DNs, such as with Active Directory.

  • Connection timeout (ms): Defaults to 5000.

  • Reject unauthorized: Valid for secure LDAP connections. Set to Yes to reject unauthorized server certificates.

  • Fallback on fatal error: Attempt local authentication if LDAP authentication is down or misconfigured. Defaults to No. If toggled to Yes, local auth will be attempted only after a failed LDAP auth. Selecting Yes also exposes this additional option:

    • Fallback on bad login: Attempt local authentication if the supplied user/password fails to log in on the LDAP provider. Defaults to No.

See also Role Mapping below.

SSO/OpenID Connect Authentication

LogStream supports SSO/OpenID user authentication (login/password) and authorization (user's group membership, which you can map to Cribl Roles). Using OpenID will change the default Log in button on the login page to a button labeled Log in with <provider> which redirects to the specified provider. Set this up as follows:

Navigate to global ⚙️ Settings (lower left) > Access Management > Authentication > Type and select OpenID Connect.

  • Provider name: The name of the identity provider service. You can select Google or Okta, both supported natively. Manual entries are also allowed.

  • Audience: The Audience from provider configuration. This will be the base URL, e.g.: https://master.yourDomain.com:9000 for a distributed environment.

  • Client ID: The client_id from provider configuration.

  • Client secret: The client_secret from provider configuration.

  • Scope: Space-separated list of authentication scopes. The default list is: openid profile email. If you populate the User info URL field, you must add groups to this list.

  • Authentication URL: The full path to the provider's authentication endpoint. Be sure to configure the callback URL at the provider as <masterServerFQDN>:9000/api/v1/auth/authorization-code/callback, e.g.: https://master.yourDomain.com:9000/api/v1/auth/authorization-code/callback.

  • Token URL: The full path to the provider's access token URL.

  • User info URL: The full path to the provider's user info URL. Optional; if not provided, LogStream will attempt to gather user info from the ID token returned from the Token URL.

  • Logout URL: The full path to the provider's logout URL. Leave blank if the provider does not support logout or token revocation.

  • User identifier: JavaScript expression used to derive userId from the id_token returned by the OpenID provider.

  • Validate certs: Whether to validate certificates. Defaults to Yes. Toggle to No to allow insecure self‑signed certificates.

  • Filter type: Select either Email allowlist or User info filter. This selection displays one of the following fields:

    • Email allowlist: Wildcard list of emails/email patterns that are allowed access.
    • User info filter: JavaScript expression to filter against user profile attributes. E.g.: name.startsWith("someUser") && email.endsWith("domain.com")
  • Group name field: Field in the User info URL response (if configured); otherwise, id_token that contains the user groups. Defaults to groups.

  • Allow local auth: Toggle to Yes to also users to log in using LogStream's local authentication. This enables an extra button called Log in with local user on the LogStream login page. (This option ensures fallback access for local users if SSO/OpenID authentication fails.)

  • Email allowlist: Wildcard list of emails/email patterns that are allowed access.

Note the following details when filling in the form – for example, when using Okta:

  • <Issuer URI> is the account at the identity provider.

  • Audience is the URL of the host that will be connecting to the Issuer (e.g., https://master.yourDomain.com:9000 for a distributed environment). The issuer (Okta, in this example) will redirect back to this site upon authentication success or failure.

  • User info URL is required, because Okta doesn't encode groups in id_token. Azure AD and Google also rely on this field.

See also Role Mapping below.

As of version 3.0, LogStream's former "master" application components are renamed "leader." Above, while some legacy terminology remains within URLs, this document will reflect that.

Cribl Cloud Authentication (Future Option)

This option, displayed in LogStream 2.4.4's Type drop-down, is not yet functional.

To avoid possible lockout, do not configure or save Cribl Cloud authentication.

Role Mapping

This section is displayed only on distributed deployments with an Enterprise license. For details on mapping your external identity provider's configured groups to corresponding LogStream user access Roles, see External Groups and LogStream Roles. The controls here are:

  • Default role: Default LogStream Role to assign to all groups not explicitly mapped to a Role.

  • Mapping: On each mapping row, enter an external group name on the left, and select the corresponding LogStream Role on the right drop-down list. Click + Add Mapping to add more rows.