[comment]: # translation:outdated

[comment]: # ({new-72ab9926})
# 13 Storage of secrets

[comment]: # ({/new-72ab9926})

[comment]: # ({new-753be55f})
#### Overview

It is possible to store some sensitive information secretly in HashiCorp
Vault KV Secrets Engine - Version 2. Secrets can be saved for:

-   user macro values
-   database access credentials

Zabbix provides read-only access to the secrets in Vault, assuming that
secrets are managed by someone else.

[comment]: # ({/new-753be55f})

[comment]: # ({new-6c5ad307})
#### User macro values

It is possible to store user macro values secretly in Vault.

A "[Vault secret](/manual/config/macros/user_macros#configuration)"
value of a user macro contains a reference path (as 'path:key', for
example "secret/zabbix:password").

The following commands may be used to set the value for the path
mentioned in example:

    # Enable "secret/" mount point if not already enabled, note that "kv-v2" must be used
    $ vault secrets enable -path=secret/ kv-v2

    # Put new secret with key password under mount point "secret/" and path "secret/zabbix"
    $ vault kv put secret/zabbix password=<password>

    # Test that secret is successfully added
    $ vault kv get secret/zabbix

    # Finally test with Curl, note that "data" need to be manually added after mount point and "/v1" before the mount point, also see --capath parameter
    $ curl --header "X-Vault-Token: <VaultToken>" https://127.0.0.1:8200/v1/secret/data/zabbix

The secret value is retrieved by Zabbix server on every refresh of
configuration data and is stored in configuration cache. The
authentication token for a read-only access to the reference paths must
be provided in server configuration ('VaultToken' parameter). If the
macro value cannot be retrieved successfully the corresponding item
using the value will turn unsupported.

It is also possible to trigger refresh of secret values from Vault,
using a 'secrets\_reload' command line
[option](/manual/concepts/server#runtime_control).

Zabbix proxy never communicates with Vault to get any secrets other than
database credentials. Secret values on Zabbix proxy are retrieved from
Zabbix server on each configuration sync and stored in configuration
cache the same way as on Zabbix server.

That means a Zabbix proxy cannot start data collection after a restart
until it receives the configuration data update from Zabbix server for
the first time. Encryption must be enabled between Zabbix server and
proxy; otherwise a server warning message is logged.

[comment]: # ({/new-6c5ad307})

[comment]: # ({new-0397a06f})
#### Database credentials

It is supported to store database credentials used by Zabbix server,
proxies and frontend secretly in Vault:

-   Vault-related parameters for retrieving database credentials can be
    optionally entered in the frontend [installation
    wizard](/manual/installation/frontend).

Database credentials retrieved from Vault will be cached by the
frontend. Note that the filesystem temporary file directory is used for
database credential caching in frontend. You may use the
ZBX\_DATA\_CACHE\_TTL [constant](/manual/web_interface/definitions) to
control how often the data cache is refreshed/invalidated.

-   For server/proxy the VaultDBPath configuration parameter may be used
    to specify the path from where credentials for database will be
    retrieved by keys 'password' and 'username' (for example:
    secret/zabbix/database).

The following commands may be used to set the values for the path
mentioned in example:

    # Enable "secret/" mount point if not already enabled, note that "kv-v2" must be used
    $ vault secrets enable -path=secret/ kv-v2

    # Put new secrets with keys username and password under mount point "secret/" and path "secret/zabbix/database"
    $ vault kv put secret/zabbix/database username=zabbix password=<password>

    # Test that secret is successfully added
    $ vault kv get secret/zabbix/database

    # Finally test with Curl, note that "data" need to be manually added after mount point and "/v1" before the mount point, also see --capath parameter
    $ curl --header "X-Vault-Token: <VaultToken>" https://127.0.0.1:8200/v1/secret/data/zabbix/database

[comment]: # ({/new-0397a06f})

[comment]: # ({new-afa61aff})
#### Configuration parameters

For Zabbix server/proxy new configuration parameters have been added for
Vault authentication and retrieving database credentials:

-   VaultToken - Vault authentication token (see Zabbix
    [server](/manual/appendix/config/zabbix_server)/[proxy](/manual/appendix/config/zabbix_proxy)
    configuration file for details)
-   VaultURL - Vault server HTTP\[S\] URL
-   VaultDBPath - Vault path from where credentials for database will be
    retrieved by keys 'password' and 'username' (for example:
    secret/zabbix/database)

Zabbix server and Zabbix proxy read the Vault-related configuration
parameters from zabbix\_server.conf and zabbix\_proxy.conf upon startup.

Zabbix server and Zabbix proxy will additionally read "VAULT\_TOKEN"
environment variable once during startup and unset it so that it would
not be available through forked scripts; it is an error if both
VaultToken and VAULT\_TOKEN contain value.

::: noteclassic
Forward slash and colon are reserved symbols. Forward slash
can only be used to separate mount point from path (e.g. secret/zabbix
where mount point is "secret" and "zabbix" is path) and, in case of
Vault macros, colon can only be used to separate path from key. It is
possible to URL-encode "/" and ":" if there is need to create mount
point with name that is separated by forward slash (e.g. foo/bar/zabbix
where mount point is "foo/bar" and path is "zabbix" as
"foo%2Fbar/zabbix") and if mount point name or path needs to contain
colon.
:::

[comment]: # ({/new-afa61aff})

[comment]: # ({new-71d9c0a5})
#### Configuring TLS

Certificate signed by a certificate authority (CA) should be added to
the default CA store. Alternatively a custom CA store location can be
specified using the SSLCALocation configuration parameter; note that in
this case the certificate directory must be prepared using the openssl
c\_rehash utility, for example configure SSLCALocation and copy "ca.pem"
inside that directory, then run the following command:

    $ c_rehash .

[comment]: # ({/new-71d9c0a5})
