Security settings in Kibana
editSecurity settings in Kibana
editYou do not need to configure any additional settings to use the security features in Kibana. They are enabled by default.
General security settings
edit
|
By default, Kibana automatically detects whether to enable the
security features based on the license and whether Elasticsearch security features
are enabled. |
Authentication security settings
editYou configure authentication settings in the xpack.security.authc
namespace in kibana.yml
.
For example:
xpack.security.authc: providers: basic.basic1: order: 0 ... saml.saml1: order: 1 ... saml.saml2: order: 2 ... pki.realm3: order: 3 ... ...
Specifies the type of authentication provider (for example, |
|
Specifies the order of the provider in the authentication chain and on the Login Selector UI. This setting is mandatory. |
|
Specifies the settings for the SAML authentication provider with a |
|
Specifies the settings for the SAML authentication provider with a |
The valid settings in the xpack.security.authc.providers
namespace vary depending on the authentication provider type. For more information, refer to Authentication.
Valid settings for all authentication providers
edit
|
Determines if the authentication provider should be enabled. By default, Kibana enables the provider as soon as you configure any of its properties. |
|
Order of the provider in the authentication chain and on the Login Selector UI. |
|
Custom description of the provider entry displayed on the Login Selector UI. |
|
Custom hint for the provider entry displayed on the Login Selector UI. |
|
Custom icon for the provider entry displayed on the Login Selector UI. |
|
Flag that indicates if the provider should have an entry on the Login Selector UI. Setting this to |
You are unable to set this setting to |
|
|
Access agreement text in Markdown format. For more information, refer to Access agreement. |
|
Ensures that user sessions will expire after a period of inactivity. Setting this to |
Use a string of |
|
|
Ensures that user sessions will expire after the defined time period. This behavior is also known as an "absolute timeout". If
this is set to |
Use a string of |
SAML authentication provider settings
editIn addition to the settings that are valid for all providers, you can specify the following settings:
OpenID Connect authentication provider settings
editIn addition to the settings that are valid for all providers, you can specify the following settings:
OpenID Connect realm in Elasticsearch that the provider should use. |
Anonymous authentication provider settings
editIn addition to the settings that are valid for all providers, you can specify the following settings:
You can configure only one anonymous provider per Kibana instance.
|
Credentials that Kibana should use internally to authenticate anonymous requests to Elasticsearch. Possible values are: username and password, API key, or the constant |
For example: # Username and password credentials xpack.security.authc.providers.anonymous.anonymous1: credentials: username: "anonymous_service_account" password: "anonymous_service_account_password" # API key (concatenated and base64-encoded) xpack.security.authc.providers.anonymous.anonymous1: credentials: apiKey: "VnVhQ2ZHY0JDZGJrUW0tZTVhT3g6dWkybHAyYXhUTm1zeWFrdzl0dk5udw==" # API key (as returned from Elasticsearch API) xpack.security.authc.providers.anonymous.anonymous1: credentials: apiKey.id: "VuaCfGcBCdbkQm-e5aOx" apiKey.key: "ui2lp2axTNmsyakw9tvNnw" # Elasticsearch anonymous access xpack.security.authc.providers.anonymous.anonymous1: credentials: "elasticsearch_anonymous_user" |
HTTP authentication settings
editThere is a very limited set of cases when you’d want to change these settings. For more information, refer to HTTP authentication.
|
Determines if HTTP authentication should be enabled. By default, this setting is set to |
|
Determines if HTTP authentication schemes used by the enabled authentication providers should be automatically supported during HTTP authentication. By default, this setting is set to |
|
List of HTTP authentication schemes that Kibana HTTP authentication should support. By default, this setting is set to |
Login user interface settings
editYou can configure the following settings in the kibana.yml
file.
Adds a message to the login UI. Useful for displaying information about maintenance windows, links to corporate sign up pages, and so on. |
|
Adds a message accessible at the login UI with additional help information for the login process. |
|
Determines if the login selector UI should be enabled. By default, this setting is set to |
Session and cookie security settings
editYou can configure the following settings in the kibana.yml
file.
|
Sets the name of the cookie used for the session. The default value is |
An arbitrary string of 32 characters or more that is used to encrypt session information. Do not expose this key to users of Kibana. By default, a value is automatically generated in memory. If you use that default behavior, all sessions are invalidated when Kibana restarts. In addition, high-availability deployments of Kibana will behave unexpectedly if this setting isn’t the same for all instances of Kibana. |
|
Sets the |
|
Sets the |
|
Ensures that user sessions will expire after a period of inactivity. This and |
|
Use a string of |
|
Ensures that user sessions will expire after the defined time period. This behavior is also known as an "absolute timeout". If
this is not set or set to |
|
Use a string of |
|
Sets the interval at which Kibana tries to remove expired and invalid sessions from the session index. By default, this value is 1 hour. The minimum value is 10 seconds. |
|
Use a string of |
Encrypted saved objects settings
editThese settings control the encryption of saved objects with sensitive data. For more details, refer to Secure saved objects.
In high-availability deployments, make sure you use the same encryption and decryption keys for all instances of Kibana. Although the keys can be specified in clear text in kibana.yml
, it’s recommended to store them securely in the Kibana Keystore.
An arbitrary string of at least 32 characters that is used to encrypt sensitive properties of saved objects before they’re stored in Elasticsearch. If not set, Kibana will generate a random key on startup, but certain features won’t be available until you set the encryption key explicitly. |
|
An optional list of previously used encryption keys. Like |
Audit logging settings
editYou can enable audit logging to support compliance, accountability, and security. When enabled, Kibana will capture:
- Who performed an action
- What action was performed
- When the action occurred
For more details and a reference of audit events, refer to Audit logs.
Set to |
|
For example: xpack.security.audit.enabled: true xpack.security.audit.appender: type: rolling-file fileName: ./audit.log policy: type: time-interval interval: 24h strategy: type: numeric max: 10 layout: type: json Elasticsearch Service does not support custom log file policies. To enable audit logging on Elasticsearch Service only specify: xpack.security.audit.enabled: true xpack.security.audit.appender.type: rolling-file [7.15.0] Deprecated in 7.15.0. In 8.0 and later, the legacy audit logger will be removed, and this setting will enable the ECS audit logger with a default appender. To enable the legacy audit logger only specify: xpack.security.audit.enabled: true |
|
Optional. Specifies where audit logs should be written to and how they should be formatted. |
|
Required. Specifies where audit logs should be written to. Allowed values are Refer to file appender and rolling file appender for appender specific settings. |
|
|
Required. Specifies how audit logs should be formatted. Allowed values are Refer to pattern layout for layout specific settings. |
We recommend using |
File appender
editThe file
appender writes to a file and can be configured using the following settings:
|
Required. Full file path the log file should be written to. |
Rolling file appender
editThe rolling-file
appender writes to a file and rotates it using a rolling strategy, when a particular policy is triggered:
|
Required. Full file path the log file should be written to. |
|
Specifies when a rollover should occur. Allowed values are Refer to size limit policy and time interval policy for policy specific settings. |
|
Specifies how the rollover should occur. Only allowed value is currently Refer to numeric strategy for strategy specific settings. |
Size limit triggering policy
editThe size-limit
triggering policy will rotate the file when it reaches a certain size:
|
Maximum size the log file should reach before a rollover should be performed. Default: |
Time interval triggering policy
editThe time-interval
triggering policy will rotate the file every given interval of time:
|
How often a rollover should occur. Default: |
|
Whether the interval should be adjusted to cause the next rollover to occur on the interval boundary. Default: |
Numeric rolling strategy
editThe numeric
rolling strategy will suffix the log file with a given pattern when rolling over, and will retain a fixed number of rolled files:
|
Suffix to append to the file name when rolling over. Must include |
|
Maximum number of files to keep. Once this number is reached, oldest files will be deleted. Default: |
Pattern layout
editThe pattern
layout outputs a string, formatted using a pattern with special placeholders, which will be replaced with data from the actual log message:
|
Optional. Specifies how the log line should be formatted. Default: |
|
Optional. Set to |
Ignore filters
editList of filters that determine which events should be excluded from the audit log. An event will get filtered out if at least one of the provided filters matches. |
|
For example: |
|
List of values matched against the |
|
List of values matched against the |
|
List of values matched against the |
|
List of values matched against the |