docs(zabbix): Add docs for a Zabbix server example config in Vault (#1)

This commit is contained in:
hygienic-books 2022-09-23 22:37:47 +02:00
parent c559e62d3f
commit 7f394be1d9

View File

@ -106,6 +106,62 @@ Get the Vault command-line client via [vaultproject.io/downloads](https://www.va
Assign the policy to a group as needed.
* As a similar narrowly scoped use case consider a Zabbix monitoring instance that may need access to credentials, session IDs, tokens or other forms of authentication to monitor machines and services.
Here's one suggestion to set up the basics for Zabbix.
In Vault with a user that has sufficient permissions:
* Create an entity `zabbix` without a policy.
* Add an alias of type `userpass` to the entity.
* Within the `userpass` auth method create a user (an account if you will) with the same name as the alias you just created so in this case `zabbix`, set a password for the account
Now tie it all together by creating a group named `rbacgroup_zabbix`. Add the `zabbix` entity to it and make it use the policy `role-zabbix`. At this point the policy does not yet exist which is fine, you can set a policy name and Vault will offer to `Add new policy`. Don't worry, this will not actually add a new policy - empty, broken or otherwise. Vault will simply link your group to the policy `role-zabbix` which does not exist. You'll get to that in a minute.
Like so:
![Vault 1.11.3 Create Group menu](https://i.imgur.com/3Ni53BE.png)
Next up check out [policies/role-zabbix/role-zabbix.hcl](policies/role-zabbix/role-zabbix.hcl). Do some light replacement before importing it into Vault. The policy file contains a few occurrences of the string `GROUPID`, replace them with the group ID of `rbacgroup_zabbix`.
* Via Vault's UI you can get the group ID at `Access > Groups > rbacgroup_zabbix`.
* Via the `vault` command-line client you can do it like so where the `id` value is what you're after:
```
# Get 'rbacgroup_zabbix' group metadata
vault kv get /identity/group/name/rbacgroup_zabbix
# Expected output similar to:
== Metadata ==
========== Data ==========
Key Value
--- -----
alias map[]
creation_time 2022-09-22T21:47:57.720309362Z
id 88560da7-e180-3d2e-9053-dc0ee4ba7fbe
...
```
With your ID in hand and [policies/role-zabbix/role-zabbix.hcl](policies/role-zabbix/role-zabbix.hcl) updated import it as a new policy. You're going to want to save it with the same policy name you assigned earlier to `rbacgroup_zabbix` which was `role-zabbix`. This role will grant read-only access to secrets underneath a folder `for_rbacgroup_zabbix` which in our example lives inside a `kv` version 2 secrets engine mounted at its default location `kv`.
So whenever your Zabbix instance needs access to something store secrets underneath `kv/for_rbacgroup_zabbix`. The policy will make sure only the group with correct ID will have access to secrets.
Log in to Vault with `userpass` and the `zabbix` account from above, get the account's token and lastly double-check that `zabbix` with its token can read a secret:
```
curl --silent --location --header 'X-Vault-Token: <token>' \
"${VAULT_ADDR}"'v1/kv/data/for_rbacgroup_zabbix/some/secret' \
| jq '.data.data'
```
Configure Zabbix with its own Vault token and enjoy no longer having to store any secrets in Zabbix itself.
Side note, if your token regularly expires you may want to store the token itself in Vault and let Zabbix monitor token expiry via the Zabbix equivalent of:
```
# Look up a token's own attributes
curl --silent --location --header 'X-Vault-Token: <token>' \
"${VAULT_ADDR}"'v1/auth/token/lookup-self' \
| jq '.data.ttl'
# .data.ttl will show remaining validity in secs:
2754536
```
## Clean-up
If during any of the above steps you've used the Vault command-line client to authenticate against Vault with your `root` token make sure that client's `~/.vault-token` file is deleted. It contains the verbatim `root` token.