13 Opslag van geheimen

Overzicht

Het is mogelijk om gevoelige informatie veilig op te slaan in HashiCorp Vault KV Secrets Engine - Versie 2. Geheimen kunnen worden opgeslagen voor:

  • gebruikersmacro-waarden
  • toegangscertificaten voor databases

Zabbix biedt alleen-lezen toegang tot de geheimen in Vault, waarbij ervan wordt uitgegaan dat de geheimen worden beheerd door iemand anders.

Gebruikersmacro-waarden

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.

Database referenties

Het is mogelijk om database referenties die worden gebruikt door de Zabbix-server, proxies en frontend, veilig in Vault op te slaan:

  • Vault-gerelateerde parameters voor het ophalen van database referenties kunnen optioneel worden ingevoerd in de frontend installatie wizard.

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.

  • Voor de server/proxy kan de VaultDBPath configuratie parameter worden gebruikt om het pad op te geven waar de referenties voor de database zullen worden opgehaald met de sleutels 'wachtwoord' en 'gebruikersnaam' (bijvoorbeeld: secret/zabbix/database).

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

Configuratieparameters

Voor Zabbix-server/proxy zijn er nieuwe configuratieparameters toegevoegd voor Vault-authenticatie en het ophalen van database referenties:

  • VaultToken - Vault authenticatie token (zie Zabbix server/proxy configuratiebestand voor details)
  • VaultURL - Vault server HTTP[S] URL
  • VaultDBPath - Vault pad van waaruit referenties voor de database zullen worden opgehaald met de sleutels 'wachtwoord' en 'gebruikersnaam' (bijvoorbeeld: secret/zabbix/database)

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.

Configuratie van TLS

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:

c_rehash .