Het is mogelijk om gevoelige informatie veilig op te slaan in HashiCorp Vault KV Secrets Engine - Versie 2. Geheimen kunnen worden opgeslagen voor:
Zabbix biedt alleen-lezen toegang tot de geheimen in Vault, waarbij ervan wordt uitgegaan dat de geheimen worden beheerd door iemand anders.
Het is mogelijk om gebruikersmacro-waarden veilig op te slaan in Vault.
Een "Vault secret" waarde van een gebruikersmacro bevat een referentiepad (bijvoorbeeld 'path:key', zoals "secret/zabbix:wachtwoord").
De volgende commando's kunnen worden gebruikt om de waarde in te stellen voor het in het voorbeeld genoemde pad:
# Schakel het "secret/" mount point in als het nog niet is ingeschakeld, let op dat "kv-v2" moet worden gebruikt
vault secrets enable -path=secret/ kv-v2
# Voeg een nieuw geheim met de sleutel wachtwoord toe onder het mount point "secret/" en pad "secret/zabbix"
vault kv put secret/zabbix wachtwoord=<wachtwoord>
# Test dat het geheim succesvol is toegevoegd
vault kv get secret/zabbix
# Test ten slotte met Curl, let op dat "data" handmatig moet worden toegevoegd na het mount point en "/v1" voor het mount point, zie ook de --capath parameter
curl --header "X-Vault-Token: <VaultToken>" https://127.0.0.1:8200/v1/secret/data/zabbix
De geheime waarde wordt door de Zabbix-server opgehaald bij elke vernieuwing van de configuratiegegevens en wordt opgeslagen in de configuratiecache. Het verificatietoken voor alleen-lezen toegang tot de referentiepaden moet worden verstrekt in de serverconfiguratie ('VaultToken'-parameter). Als de macro-waarde niet succesvol kan worden opgehaald, wordt het overeenkomstige item dat de waarde gebruikt, niet-ondersteund.
Het is ook mogelijk om een vernieuwing van geheime waarden vanuit Vault te activeren, met behulp van een commando voor de opdrachtregel parameter.
Een Zabbix-proxy communiceert nooit met Vault om geheime waarden op te halen, behalve database referenties. Geheime waarden op een Zabbix-proxy worden bij elke synchronisatie van configuratiegegevens opgehaald bij de Zabbix-server en opgeslagen in de configuratiecache, net als op de Zabbix-server.
Dat betekent dat een Zabbix-proxy geen gegevensverzameling kan starten na een herstart, totdat deze voor het eerst configuratiegegevens bij de Zabbix-server ontvangt. Versleuteling moet zijn ingeschakeld tussen de Zabbix-server en proxy; anders wordt er een waarschuwingsbericht van de server gelogd.
Het is mogelijk om database referenties die worden gebruikt door de Zabbix-server, proxies en frontend, veilig in Vault op te slaan:
Database referenties die uit Vault worden opgehaald, worden gecached door de frontend. Let op dat de tijdelijke bestandsmap van het bestandssysteem wordt gebruikt voor het cachen van database referenties in de frontend. U kunt de ZBX_DATA_CACHE_TTL constante gebruiken om te bepalen hoe vaak de data cache wordt vernieuwd/ongeldig wordt gemaakt.
De volgende commando's kunnen worden gebruikt om de waarden in te stellen voor het in het voorbeeld genoemde pad:
# Schakel het "secret/" mount point in als het nog niet is ingeschakeld, let op dat "kv-v2" moet worden gebruikt
vault secrets enable -path=secret/ kv-v2
# Voeg nieuwe geheimen toe met de sleutels gebruikersnaam en wachtwoord onder het mount point "secret/" en pad "secret/zabbix/database"
vault kv put secret/zabbix/database gebruikersnaam=zabbix wachtwoord=<wachtwoord>
# Test dat het geheim succesvol is toegevoegd
vault kv get secret/zabbix/database
# Test ten slotte met Curl, let op dat "data" handmatig moet worden toegevoegd na het mount point en "/v1" voor het mount point, zie ook de --capath parameter
curl --header "X-Vault-Token: <VaultToken>" https://127.0.0.1:8200/v1/secret/data/zabbix/database
Voor Zabbix-server/proxy zijn er nieuwe configuratieparameters toegevoegd voor Vault-authenticatie en het ophalen van database referenties:
Zabbix-server en Zabbix-proxy lezen de Vault-gerelateerde configuratieparameters uit zabbix_server.conf en zabbix_proxy.conf bij het opstarten.
Zabbix-server en Zabbix-proxy lezen bovendien een "VAULT_TOKEN" omgevingsvariabele eenmaal tijdens het opstarten en stellen deze zo in dat deze niet beschikbaar is via geforkte scripts; het is een fout als zowel VaultToken als VAULT_TOKEN een waarde bevatten.
De schuine streep en de dubbele punt zijn gereserveerde symbolen. Een schuine streep kan alleen worden gebruikt om het koppelingspunt van het pad te scheiden (bijvoorbeeld secret/zabbix waarbij het koppelingspunt "secret" is en "zabbix" het pad is) en in het geval van Vault-macro's kan een dubbele punt alleen worden gebruikt om het pad van de sleutel te scheiden. Het is mogelijk om "/" en ":" URL-gecodeerd te gebruiken als er behoefte is aan een koppelingspunt met een naam die wordt gescheiden door een schuine streep (bijvoorbeeld foo/bar/zabbix waarbij het koppelingspunt "foo/bar" is en het pad "zabbix" is als "foo%2Fbar/zabbix") en als de naam van het koppelingspunt of het pad een dubbele punt bevat.
Een certificaat dat is ondertekend door een certificaatautoriteit (CA) moet worden toegevoegd aan de standaard CA-opslag. Als alternatief kan een aangepaste locatie voor de CA-opslag worden gespecificeerd met behulp van de SSLCALocation configuratieparameter. Let op dat in dit geval de certificaatdirectory moet worden voorbereid met behulp van het openssl c_rehash hulpprogramma. Bijvoorbeeld, configureer SSLCALocation en kopieer "ca.pem" naar die directory, voer dan het volgende commando uit: