docs(zabbix): Add docs for a Zabbix server example config in Vault (#1)
This commit is contained in:
parent
c559e62d3f
commit
7f394be1d9
56
README.md
56
README.md
@ -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:
|
||||

|
||||
|
||||
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.
|
||||
|
Loading…
x
Reference in New Issue
Block a user