Bevezetés a Vaultba

1. Áttekintés

Ebben az oktatóanyagban felfedezzük a Hashicorp Vault boltját - népszerű eszköz a kényes információk biztonságos kezelésére, a modern alkalmazás-architektúrákban.

A fő témák, amelyekkel foglalkozunk, a következők:

  • Vault milyen problémát próbál megoldani
  • Vault építészete és fő koncepciói
  • Egyszerű tesztkörnyezet beállítása
  • Interakció a Vaulttal a parancssori eszközével

2. Az érzékeny információk problémája

Mielőtt belevágna a Vaultba, próbáljuk megérteni a problémát, amelyet megpróbál megoldani: az érzékeny információkezelést.

A legtöbb alkalmazásnak hozzáférni kell a bizalmas adatokhoz a megfelelő működéshez. Például egy e-kereskedelmi alkalmazásnak lehet egy felhasználóneve / jelszava, amelyet valahol konfiguráltak annak érdekében, hogy csatlakozzon az adatbázisához. Szüksége lehet API-kulcsokra is, hogy integrálódhasson más szolgáltatókkal, például fizetési átjárókkal, logisztikával és más üzleti partnerekkel.

Az adatbázis-hitelesítő adatok és az API-kulcsok néhány példája azoknak az érzékeny információknak, amelyeket biztonságos módon kell tárolnunk és elérhetővé tennünk az alkalmazásaink számára.

Egyszerű megoldás az, hogy ezeket a hitelesítő adatokat egy konfigurációs fájlban tárolja, és az indításkor elolvassa. Ennek a megközelítésnek a problémája azonban nyilvánvaló. Aki hozzáfér ehhez a fájlhoz, ugyanazokkal az adatbázis-jogosultságokkal rendelkezik, mint alkalmazásunk - általában teljes hozzáférést biztosít a tárolt adatokhoz.

Megpróbálhatjuk kissé megnehezíteni a dolgokat azáltal, hogy titkosítjuk ezeket a fájlokat. Ez a megközelítés azonban nem fog sokat hozzáadni az általános biztonság szempontjából. Főleg azért, mert alkalmazásunknak hozzáféréssel kell rendelkeznie a fő kulcshoz. A titkosítás ilyenkor csak „hamis” biztonságérzetet fog elérni.

A modern alkalmazások és a felhőkörnyezetek általában némi extra bonyolultságot adnak: az elosztott szolgáltatások, több adatbázis, üzenetküldő rendszerek és így tovább, kényes információk kissé mindenhol el vannak terjedve, ezáltal növelve a biztonsági megsértések kockázatát.

Tehát mit tehetünk? Nézzük Vault!

3. Mi az a Vault?

A Hashicorp Vault az érzékeny információk kezelésének problémájával foglalkozik - a titok Vault szóhasználatával. A „kezelés” ebben az összefüggésben azt jelenti, hogy a Vault egy érzékeny információ minden aspektusát ellenőrzi: előállítása, tárolása, használata és nem utolsó sorban visszavonása.

A Hashicorp a Vault két változatát kínálja. A cikkben használt nyílt forráskódú verzió szabadon használható, még kereskedelmi környezetben is. Fizetett változat is elérhető, amely tartalmazza a különböző SLA-k technikai támogatását és további szolgáltatásokat, például a HSM (Hardware Security Module) támogatást.

3.1. Építészet és főbb jellemzők

A Vault felépítése megtévesztően egyszerű. Fő elemei:

  • Tartós háttérrendszer - minden titok tárolása
  • API-kiszolgáló, amely kezeli az ügyfélkéréseket és titkokkal műveleteket hajt végre
  • Számos titkos motorok, egyet a támogatott titkos típusok mindegyikéhez

Az összes titkos kezelés Vaultra történő átruházásával enyhíthetünk néhány biztonsági kérdést:

  • Alkalmazásainknak már nem kell tárolniuk őket - csak kérdezze meg a Vaultot, ha szükséges, és dobja el
  • Rövid életű titkokat használhatunk, korlátozva ezzel a „lehetőségek ablakát”, ahol a támadó ellopott titkot használhat

A Vault titkosító kulccsal titkosítja az összes adatot, mielőtt a boltba írja. Ezt a titkosítási kulcsot egy másik kulcs titkosítja - a fő kulcs, amelyet csak az indításkor használnak.

A Vault megvalósításának egyik legfontosabb pontja, hogy nem tárolja a fő kulcsot a szerveren. Ez azt jelenti, hogy indítás után még a Vault sem férhet hozzá mentett adataihoz. Ezen a ponton azt mondják, hogy egy Vault-példány „lezárt” állapotban van.

Később végigmegyünk a fő kulcs előállításához és a Vault példány lezárásához szükséges lépéseken.

A lezárás után a Vault készen áll az API-kérések elfogadására. Ezeknek a kéréseknek természetesen hitelesítésre van szükségük, amely megmutatja, hogyan hitelesíti a Vault az ügyfeleket, és eldönti, mit tehetnek vagy mit nem.

3.2. Hitelesítés

A Vault titkainak eléréséhez az ügyfélnek a támogatott módszerek egyikével hitelesítenie kell magát. A legegyszerűbb módszer Tokeneket használ, amelyek csak karakterláncok, amelyeket minden API-kéréshez elküldnek egy speciális HTTP fejléc használatával.

Az első telepítéskor a Vault automatikusan létrehoz egy „root tokent”. Ez a token egyenértékű a root superuserrel a Linux rendszerekben, ezért használatát minimálisra kell korlátozni. Legjobb gyakorlatként ezt a gyökér tokent kell használnunk, hogy más jogokat hozzunk létre kevesebb jogosultsággal, majd visszavonjuk. Ez azonban nem jelent problémát, mivel később egy lezáró kulcsok segítségével létrehozhatunk egy másik gyökér tokent.

A Vault egyéb hitelesítési mechanizmusokat is támogat, például az LDAP, JWT, TLS tanúsítványokat. Mindezek a mechanizmusok az alap token mechanizmus tetejére épülnek: ha a Vault hitelesíti az ügyfelünket, akkor egy tokent biztosít, amelyet ezután felhasználhatunk más API-k elérésére.

A tokeneknek van néhány tulajdonságuk. A fő tulajdonságok a következők:

  • Társított halmaz Házirendek (lásd a következő szakaszt)
  • Itt az ideje élni
  • Megújítható-e
  • Maximális használati szám

Hacsak másként nem mondjuk, a Vault által létrehozott tokenek a szülő és a gyermek kapcsolatát alkotják. A gyermek token legfeljebb azonos szintű jogosultságokkal rendelkezhet, mint a szülők.

Az ellenkezője nem igaz: létrehozhatunk - és általában is - létrehozunk egy gyermek tokent korlátozó irányelvekkel. A kapcsolat másik kulcsfontosságú pontja: Ha érvénytelenítünk egy tokent, akkor minden gyermek tokent és utódaikat is érvénytelenítünk.

3.3. Házirendek

A házirendek pontosan meghatározzák, hogy az ügyfél mely titkokhoz férhet hozzá, és mely műveleteket hajthatja végre velük. Nézzük meg, hogyan néz ki egy egyszerű irányelv:

elérési út "titkos / könyvelési" {képesség = ["olvasás"]}

Itt a HCL (Hashicorp konfigurációs nyelve) szintaxist használtuk házirendünk meghatározásához. A Vault támogatja a JSON-ot is erre a célra, de példáinkban ragaszkodunk a HCL-hez, mivel könnyebben olvasható.

A Vault házirendjei „alapértelmezés szerint megtagadva”. Ehhez a mintapolitikához csatolt token hozzáférést biztosít a (z) alatt tárolt titkokhoz titkos / könyvelés és semmi más. A létrehozáskor token csatolható több házirendhez. Ez nagyon hasznos, mert lehetővé teszi számunkra, hogy kisebb házirendeket hozzunk létre és teszteljünk, majd szükség szerint alkalmazzuk őket.

A politikák másik fontos szempontja, hogy kihasználják a lusta értékelést. Ez azt jelenti, hogy frissíteni tudjuk az adott házirendet, és minden tokent azonnal érint.

Az eddig leírt házirendeket Access Control List Policy-nak vagy ACL-házirendnek is nevezik. A Vault két további házirend-típust is támogat: EGP és RGP házirendeket. Ezek csak a fizetős verziókban érhetők el, és kiterjesztik az alapvető házirend-szintaxist a Sentinel támogatásával.

Ha rendelkezésre áll, ez lehetővé teszi számunkra, hogy az irányelveinkben figyelembe vegyünk további tulajdonságokat, például a napszakot, több hitelesítési tényezőt, az ügyfélhálózat eredetét és így tovább. Például meghatározhatunk egy házirendet, amely csak munkaidőben enged hozzáférést egy adott titokhoz.

A házirend szintaxisáról további részleteket a Vault dokumentációjában találhat.

4. Titkos típusok

A Vault különféle titkos típusokat támogat, amelyek különböző felhasználási esetekkel foglalkoznak:

  • Kulcs érték: egyszerű statikus kulcs-érték párok
  • Dinamikusan generált hitelesítő adatok: a Vault generálja az ügyfél kérésére
  • Kriptográfiai kulcsok: Titkosítási funkciók kliens adatokkal történő végrehajtására szolgál

Minden titkos típust a következő attribútumok határoznak meg:

  • A hegypont, amely meghatározza a REST API előtagját
  • A megfelelő API-n keresztül kitett műveletek halmaza
  • Konfigurációs paraméterek halmaza

Egy adott titkos példány a pálya, hasonlóan a fájlrendszer könyvtárfájához. Ennek az útnak az első összetevője megfelel a hegy csucs ahol minden ilyen típusú titok megtalálható.

Például a karakterlánc titkos / én-alkalmazásom annak az útnak felel meg, amely alatt kulcs-érték párokat találhatunk az én alkalmazásom.

4.1. Kulcsértékű titkok

A kulcsérték titkai, amint a neve is mutatja, egyszerű párok az adott útvonal alatt elérhető. Például tárolhatjuk a párost foo = bár az ösvény alatt / secret / my-application.

Később ugyanazt az utat használjuk ugyanazon pár vagy párok előhívásához - több pár is tárolható ugyanazon az útvonalon.

A Vault háromféle kulcsérték titkot támogat:

  • Nem változatos kulcspárok, ahol a frissítések a meglévő értékeket helyettesítik
  • Verziós kulcspárok, amelyek a konfigurálható számú régi verziót képesek megtartani
  • Cubbyhole, a nem verziózott kulcspárok speciális típusa, amelyek értékeit egy adott tartományba sorolják hozzáférési token (bővebben azokról később).

A kulcsérték titkai statikus jellegűek, ezért nincs hozzájuk társított lejárati koncepció. Az ilyen típusú titok fő felhasználási esete a hitelesítő adatok tárolása a külső rendszerek, például az API-kulcsok eléréséhez.

Ilyen esetekben a hitelesítő adatok frissítése félig manuális folyamat, amely általában megköveteli, hogy valaki új hitelesítő adatokat szerezzen be, és a Vault parancssorával vagy felhasználói felületével írja be az új értékeket.

4.2. Dinamikusan generált titkok

Dinamikus titkokat menet közben hoz létre a Vault, ha egy alkalmazás kéri. A Vault többféle dinamikus titkot támogat, beleértve az alábbiakat:

  • Adatbázis hitelesítő adatok
  • SSH kulcspárok
  • X.509 tanúsítványok
  • AWS hitelesítő adatok
  • Google Cloud szolgáltatásfiókok
  • Active Directory-fiókok

Mindezek ugyanazt a használati mintát követik. Először konfiguráljuk a titkos motort a kapcsolódó szolgáltatáshoz való csatlakozáshoz szükséges adatokkal. Ezután definiálunk egyet vagy többet szerepek, amelyek leírják a tényleges titkos alkotást.

Vegyük példának az adatbázis titkos motorját. Először konfigurálnunk kell a Vaultot az összes felhasználói adatbázis-kapcsolattal, beleértve az előzőleg létező, rendszergazdai jogosultságokkal rendelkező felhasználók hitelesítő adatait új felhasználók létrehozásához.

Ezután létrehozunk egy vagy több szerepet (Vault szerepkörök, nem adatbázis szerepkörök), amelyek tartalmazzák az új felhasználó létrehozásához használt tényleges SQL utasításokat. Ezek általában nem csak a felhasználói létrehozási utasítást tartalmazzák, hanem az összes szükségeset is támogatás a sémaobjektumok (táblák, nézetek és így tovább) eléréséhez szükséges utasítások.

Amikor az ügyfél hozzáfér a megfelelő API-hoz, a Vault a megadott utasítások segítségével új ideiglenes felhasználót hoz létre az adatbázisban, és visszaadja hitelesítő adatait. Ezután az ügyfél felhasználhatja ezeket a hitelesítő adatokat az adatbázis eléréséhez a kért szerep "time-to-live" attribútuma által meghatározott időszakban.

Amint a hitelesítő adatok elérik a lejárati idejét, a Vault automatikusan visszavon minden, a felhasználóhoz társított jogosultságot. Az ügyfél kérheti a Vaultot is a hitelesítő adatok megújításához. A megújítási folyamat csak akkor történik meg, ha az adott adatbázis-illesztőprogram támogatja és a társított házirend lehetővé teszi.

4.3. Titkosítási kulcsok

A titkos típusú motorok olyan kriptográfiai funkciókat kezelnek, mint a titkosítás, a visszafejtés, az aláírás és így tovább. Mindezek a műveletek a Vault által létrehozott és tárolt kriptográfiai kulcsokat használják. Hacsak erre kifejezetten nem szólítják meg, a Vault soha nem teszi ki az adott kriptográfiai kulcsot.

A társított API lehetővé teszi az ügyfelek számára, hogy Vault egyszerű szöveges adatokat küldjenek, és azok titkosított változatát kapják meg. Ennek az ellenkezője is lehetséges: Küldhetünk titkosított adatokat, és visszakaphatjuk az eredeti szöveget.

Jelenleg csak egy ilyen típusú motor létezik: a Tranzit motor. Ez a motor támogatja a népszerű kulcstípusokat, például az RSA és az ECDSA, valamint támogatja Konvergens titkosítás. Ennek a módnak a használatakor az adott sima szöveg értéke mindig ugyanazt a cyphertext eredményt eredményezi, ez a tulajdonság nagyon hasznos bizonyos alkalmazásokban.

Például használhatjuk ezt a módot a hitelkártya-számok titkosításához egy tranzakciós napló táblázatban. Konvergens titkosítással minden alkalommal, amikor új tranzakciót szúrunk be, a titkosított hitelkártya értéke megegyezik, lehetővé téve a rendszeres SQL lekérdezések használatát jelentések készítéséhez, kereséshez és így tovább.

5. Széf beállítása

Ebben a szakaszban létrehozunk egy helyi tesztkörnyezetet, így teszteljük a Vault képességeit.

A Vault telepítése egyszerű: töltse le az operációs rendszerünknek megfelelő csomagot, és vonja ki a futtatható fájlt (boltozat vagy vault.exe Windows rendszeren) a PATH-on található könyvtárba. Ez a futtatható fájl tartalmazza a szervert, és egyben a standard kliens is. Van egy hivatalos Docker kép is, de itt nem foglalkozunk vele.

Széf támogatás a fejlődés mód, amely jó néhány gyors teszteléshez és a parancssori eszközhöz való szoktatáshoz, de túl egyszerű a valós használati esetekben: az újraindításkor minden adat elvész, és az API-hozzáférés egyszerű HTTP-t használ.

Ehelyett fájlalapú állandó tárhelyet és HTTPS-t állítunk be, hogy felfedezhessük a valós konfigurációs részleteket, amelyek problémákat okozhatnak.

5.1. A Vault Server indítása

A Vault egy konfigurációs fájlt használ HCL vagy JSON formátumban. A következő fájl meghatározza a kiszolgálónknak egy fájltárhely és saját aláírású tanúsítvány használatával történő indításához szükséges összes konfigurációt:

storage "fájl" {path = "./vault-data"} figyelő "tcp" {address = "127.0.0.1:8200" tls_cert_file = "./src/test/vault-config/localhost.cert" tls_key_file = ". /src/test/vault-config/localhost.key "}

Most futtassuk a Vaultot. Nyissa meg a parancsértelmezőt, lépjen a konfigurációs fájlt tartalmazó könyvtárba, és futtassa a következő parancsot:

$ vault szerver -config ./vault-test.hcl

A Vault elindul, és megjelenít néhány inicializáló üzenetet. Tartalmazzák annak verzióját, néhány konfigurációs részletet és azt a címet, ahol az API elérhető. Ennyi - a Vault szerverünk működik.

5.2. Széf inicializálása

A Vault szerverünk most fut, de mivel ez az első futtatása, inicializálnunk kell.

Nyissunk meg egy új héjat, és hajtsuk végre a következő parancsokat ennek eléréséhez:

$ export VAULT_ADDR = // localhost: 8200 $ export VAULT_CACERT =. / src / test / vault-config / localhost.cert $ vault operátor init

Itt definiáltunk néhány környezeti változót, ezért nem kell minden alkalommal paraméterként átadnunk a Vaultnak:

  • VAULT_ADDR: alap URI, ahol API-kiszolgálónk fogja kiszolgálni a kéréseket
  • VAULT_CACERT: A szerver tanúsítványának nyilvános kulcsához vezető út

Esetünkben a VAULT_CACERT így a HTTPS segítségével elérhetjük a Vault API-ját. Erre szükségünk van, mert önaláírt tanúsítványokat használunk. Erre nem lenne szükség a gyártási környezetekben, ahol általában hozzáférünk a CA által aláírt tanúsítványokhoz.

A fenti parancs kiadása után egy ilyen üzenetet kell látnunk:

1. pecsétkulcs: 2. pecsétkulcs: 3. pecsétkulcs: 4. pecsétkulcs: 5. sz. Lezárási kulcs: Kezdeti gyökér token: ... további üzenetek kihagyva

Az öt első sor a fő kulcs megosztása, amelyet később felhasználunk a Vault tárolójának lezárásához. Felhívjuk figyelmét, hogy a Vault csak az inicializáláskor jeleníti meg a megosztott kulcsot - és soha többé.Vegye tudomásul és tárolja biztonságosan, különben a szerver újraindításakor elveszítjük hozzáférését a titkainkhoz!

Kérjük, vegye figyelembe a root token, mivel később szükségünk lesz rá. A lezáratlan kulcsokkal ellentétben A root tokenek később könnyen létrehozhatók, ezért biztonságos, ha az összes konfigurációs feladat befejeződött. Mivel később olyan parancsokat fogunk kiadni, amelyek hitelesítési tokent igényelnek, most mentsük el a root tokent egy környezeti változóba:

$ export VAULT_TOKEN = (Unix / Linux)

Lássuk a szerver állapotát most, miután inicializáltuk, a következő paranccsal:

$ Vault status Kulcsérték --- ----- Seal Type shamir Sealed true Összes megosztás 5 Threshold 3 Unseal Progress 0/3 Unseal Nonce n / a Version 0.10.4 HA Enabled false

Láthatjuk, hogy Vault még mindig lepecsételt. Követhetjük a lezáratlan haladást is: a „0/3” azt jelenti, hogy a Vaultnak három részvényre van szüksége, de eddig nem kapott egyet. Haladjunk előre, és biztosítsuk részvényeinkkel.

5.3. Vault Unseal

Most kibontjuk a Vaultot, hogy elkezdhessük használni titkos szolgáltatásait. A lezárási folyamat befejezéséhez meg kell adnunk az öt kulcsrész bármelyikét:

$ vault operátor uneal $ vault operátor uneal $ vault operátor uneal 

Az egyes parancstárak kiadása után kinyomtatja a lezáratlan folyamatot, beleértve azt is, hogy hány megosztásra van szüksége. Az utolsó kulcsmegosztás elküldése után egy ilyen üzenetet fogunk látni:

Kulcsérték --- ----- Tömítés típusa shamir Sealed false ... egyéb tulajdonságok kihagyva

A „Sealed” tulajdonság ebben az esetben „hamis”, ami azt jelenti, hogy a Vault készen áll a parancsok elfogadására.

6. A Vault tesztelése

Ebben a szakaszban a Vault beállításait két támogatott titkos típusával teszteljük: Kulcs / Érték és Adatbázis. Megmutatjuk azt is, hogy miként hozhatunk létre új tokent a hozzájuk kapcsolódó házirendekkel.

6.1. Kulcs / érték titkok használata

Először tároljuk a titkos kulcs-érték párokat, és olvassuk vissza őket. Ha feltételezzük, hogy a Vault inicializálásához használt parancssor továbbra is nyitva van, akkor a következő paranccsal tároljuk ezeket a párokat a titkos / fakebank pálya:

$ vault kv put secret / fakebank api_key = abc1234 api_secret = 1a2b3c4d

Ezeket a párokat bármikor helyreállíthatjuk a következő paranccsal:

$ vault kv get secret / fakebank ======= Data ======= Kulcsérték --- ----- api_key abc1234 api_secret 1a2b3c4d 

Ez az egyszerű teszt megmutatja, hogy a Vault a megfelelő módon működik. Most tesztelhetünk néhány további funkciót.

6.2. Új tokenek létrehozása

Eddig a root tokent használtuk kéréseink hitelesítéséhez. Mivel egy gyökér token az út túl nagy teljesítményű, bevált gyakorlatnak tekinthető a kevesebb kiváltságú és rövidebb élettartamú tokenek használata.

Hozzunk létre egy új tokent, amelyet ugyanúgy használhatunk, mint a root tokent, de csak egy perc múlva lejár:

$ vault token create -ttl 1m kulcsérték --- ----- token token_accessor token_duration 1m token_renewable true token_policies ["root"] identity_policies [] házirendek ["root"]

Teszteljük ezt a tokent, és használjuk a korábban létrehozott kulcs / érték párok elolvasására:

$ export VAULT_TOKEN = $ Vault kv get secret / fakebank ======= Data ======= Kulcsérték --- ----- api_key abc1234 api_secret 1a2b3c4d

Ha várunk egy percet, és megpróbáljuk kiadni ezt a parancsot, hibaüzenetet kapunk:

$ vault kv get secret / fakebank Hiba történt az API kérés végrehajtása során. URL: GET // localhost: 8200 / v1 / sys / internal / ui / mounts / secret / fakebank Kód: 403. Hibák: * engedély megtagadva

Az üzenet azt jelzi, hogy a tokenünk már nem érvényes, erre számítottunk.

6.3. Tesztelési irányelvek

Az előző szakaszban létrehozott mintakód rövid volt, de nagyon hatékony. Használjuk most a házirendeket korlátozottabb tokenek létrehozásához.

Például definiáljunk egy házirendet, amely csak olvasási hozzáférést engedélyez a titkos / fakebank korábban használt utunk:

$ cat> minta-politika.hcl <

Most létrehozunk egy tokent ezzel a házirenddel a következő paranccsal:

$ export VAULT_TOKEN = $ Vault token create -policy = fakebank-ro Key Value --- ----- token token_accessor token_duration 768h token_renewable true token_policies ["default" "fakebank-ro"] identity_policies [] házirendek ["alapértelmezett" " fakebank-ro "]

Ahogy korábban tettük, olvassuk el titkos értékeinket a token használatával:

$ export VAULT_TOKEN = $ Vault kv get secret / fakebank ======= Data ======= Kulcsérték --- ----- api_key abc1234 api_secret 1a2b3c4d

Eddig jó. Az adatokat a várakozásoknak megfelelően olvashatjuk. Nézzük meg, mi történik, amikor megpróbáljuk frissíteni ezt a titkot:

$ vault kv put secret / fakebank api_key = foo api_secret = bar Hiba az adatok írása során a secret / fakebank: Hiba történt az API kérés megadásakor. URL: PUT //127.0.0.1:8200/v1/secret/fakebank Kód: 403. Hibák: * engedély elutasítva

Mivel házirendünk nem engedélyezi kifejezetten az írást, a Vault 403 - Hozzáférés megtagadva állapotkódot ad vissza.

6.4. Dinamikus adatbázis-hitelesítő adatok használata

A cikk utolsó példaként használjuk a Vault adatbázis titkos motorját a dinamikus hitelesítő adatok létrehozásához. Itt feltételezzük, hogy van egy MySQL szerver, amely helyben elérhető, és hogy „root” jogosultságokkal érhetjük el. Használunk egy nagyon egyszerű sémát is, amely egyetlen táblából áll - számla .

A séma létrehozásához használt SQL szkript és a privilegizált felhasználó itt érhető el.

Most konfiguráljuk a Vaultot ennek az adatbázisnak a használatára. Az adatbázis titkos motor alapértelmezés szerint nincs engedélyezve, ezért ezt meg kell javítanunk, mielőtt folytathatnánk:

A $ Vault titkok lehetővé teszik az adatbázis sikerét! Engedélyezte az adatbázis titkosító motorját a következő helyen: database /

Most létrehozunk egy adatbázis-konfigurációs erőforrást:

$ vault írási adatbázis / config / mysql-fakebank \ plugin_name = mysql-legacy-database-plugin \ connection_url = "{{felhasználónév}}: {{password}} @ tcp (127.0.0.1:3306) / fakebank" \ allowed_roles = "*" \ felhasználónév = "fakebank-admin" \ password = "Sup & rSecre7!"

Az útvonal előtagja adatbázis / konfiguráció itt kell tárolni az összes adatbázis-konfigurációt. Kiválasztjuk a nevet mysql-fakebank így könnyen kitalálhatjuk, hogy melyik adatbázisra utal ez a konfiguráció. Ami a konfigurációs kulcsokat illeti:

  • plugin_name: Meghatározza, hogy melyik adatbázis-plugint fogja használni. Az elérhető bővítményneveket a Vault dokumentumai írják le
  • connection_url: Ezt a sablont használja a plugin, amikor csatlakozik az adatbázishoz. Figyelje meg a {{felhasználónév}} és a {{jelszó}} sablon helyőrzőit. Amikor csatlakozik az adatbázishoz, a Vault helyettesíti ezeket a helyőrzőket tényleges értékekkel
  • megengedett_szerepek: Adja meg, hogy mely Vault-szerepkörök (a továbbiakban tárgyaljuk) használhatják ezt a konfigurációt. Esetünkben a „*” -t használjuk, így minden szerep számára elérhető
  • felhasználónév jelszó: Ezt a fiókot használja a Vault adatbázis-műveletek végrehajtására, például új felhasználó létrehozására és jogosultságainak visszavonására

Vault adatbázis-szerepkör beállítása

Az utolsó konfigurációs feladat egy Vault adatbázis-szerepkör-erőforrás létrehozása, amely tartalmazza a felhasználó létrehozásához szükséges SQL-parancsokat. A biztonsági követelményeinknek megfelelően annyi szerepet hozhatunk létre, amennyire csak szükséges.

Itt létrehozunk egy szerepkört, amely csak olvasható hozzáférést biztosít a fakebank séma:

$ vault írási adatbázis / szerepek / fakebank-accounts-ro \ db_name = mysql-fakebank \ creation_statements = "FELHASZNÁLÓ FELHASZNÁLÓJÁT" {{name}} "@ '%" IDENTIFIED BY "{{password}}"; GRANT SELECT ON fakebank. * Elnevezni}}'@'%';" 

Az adatbázis-motor meghatározza az elérési út előtagot adatbázis / szerepek mint a szerepek tárolásának helye. fakebank-számlák-ro az a szerepnév, amelyet később használunk a dinamikus hitelesítő adatok létrehozásakor. A következő kulcsokat is szállítjuk:

  • db_name: Meglévő adatbázis-konfiguráció neve. Megfelel az útvonal utolsó részének, amelyet a konfigurációs erőforrás létrehozásakor használtunk
  • létrehozás_állapotok: Az SQL utasítássablonok listája, amelyeket a Vault új felhasználó létrehozásához használ

Dinamikus hitelesítő adatok létrehozása

Miután elkészült egy adatbázis szerep és annak megfelelő konfiguráció, új dinamikus hitelesítő adatokat állítunk elő a következő paranccsal:

$ Vault adatbázis olvasása / creds / fakebank-accounts-ro Kulcsérték --- ----- lízing_id adatbázis / creds / fakebank-számlák-ro / 0c0a8bef-761a-2ef2-2fed-4ee4a4a076e4 leasing_duration 1h lízing_megújítható igaz jelszó felhasználónév 

A adatbázis / kreditek előtagot használnak a rendelkezésre álló szerepkörök hitelesítő adatainak előállításához. Mivel mi használtuk a fakebank-számlák-ro szerepkörben a visszaküldött felhasználónév / jelszó a következőre lesz korlátozva: válassza tevékenységek.

Ezt ellenőrizhetjük úgy, hogy csatlakozunk az adatbázishoz a mellékelt hitelesítő adatok használatával, majd végrehajtunk néhány SQL parancsot:

$ mysql -h 127.0.0.1 -u -p fakebank Írja be a jelszót: MySQL [fakebank]> select * from account; ... rövidség miatt kihagyva 2 sor a készletből (0,00 mp) MySQL [fakebank]> törlés a számláról; 1142 (42000) HIBA: A DELETE parancs megtagadva a 'v-fake-9xoSKPkj1' @ 'localhost' felhasználó számára a 'tábla' fiókhoz 

Láthatjuk, hogy az első válassza sikeresen befejeződött, de a töröl nyilatkozat. Végül, ha várunk egy órát, és megpróbálunk csatlakozni ugyanazokkal a hitelesítő adatokkal, akkor már nem tudunk csatlakozni az adatbázishoz. A Vault automatikusan visszavonta az összes jogosultságot ettől a felhasználótól

7. Következtetés

Ebben a cikkben megvizsgáltuk a Hashicorp Vault alapjait, beleértve a probléma megoldásának hátterét, architektúráját és alapvető használatát.

Útközben létrehoztunk egy egyszerű, de funkcionális tesztkörnyezetet, amelyet a későbbi cikkekben fogunk használni.

A következő cikk a Vault nagyon specifikus felhasználási eseteivel foglalkozik: Használata a Spring Boot alkalmazás kontextusában. Maradjon velünk!


$config[zx-auto] not found$config[zx-overlay] not found