Proměnné úložiště parametrů AWS a prostředí

V tomto článku se budu zabývat otázkou, zda a kdy by měl být AWS Parameter Store použit k nahrazení proměnných prostředí v AWS infrastruktuře. Nebudu se dívat na to, co každý z nich je, nebo jak je nastavit jakýmkoli hloubkovým způsobem, ale spíše na jejich srovnání.

Příklad proměnných prostředí

Snadné nastavení

Je velmi snadné získat nastavení pomocí proměnných prostředí. Uzel má například modul dotenv, který lze nainstalovat pomocí npm pomocí jediného příkazu:

npm nainstalovat dotenv

Musíme se ujistit, že dotenv má někde v našem skriptu vstupní bod, obvykle prostřednictvím příkazu požadavku -

vyžadují („dotenv“). config ()

Od této chvíle vše, co musíme udělat, je přidat naše proměnné prostředí do souboru .env umístěného v kořenové složce projektu.

Více informací o dotenv modulu najdete zde:

Je třeba si uvědomit, že Parameter Store nesdílí původně stejné aspekty ve snadném nastavení - pokud jste nikdy předtím s parametrovým úložištěm nikdy nepracovali, proces nastavení se může zdát docela pracný s několika věcmi, které je třeba zvážit:

  • Potřebujete přístup k účtu AWS
  • Potřebujete vědět, jak se orientovat v řídicím panelu AWS - konkrétně v sekci SSM.
  • Citlivé / zabezpečené parametry by měly být šifrovány pomocí KMS - což samo o sobě vyžaduje další nastavení (https://aws.amazon.com/kms/)
  • V závislosti na vašich potřebách budete možná potřebovat znalosti konfigurace dalších služeb AWS, jako je IAM a SSM, aby sklad parametrů fungoval správně.
  • Všechny parametry jsou hostovány v cloudu vyžadujícím programový přístup IAM, což znamená, že je vyžadováno nepřetržité připojení (je třeba si uvědomit, že lze vytvořit lokální nastavení na míru s lokálními proměnnými, které lze použít místo proměnných Parameter Store v závislosti na situaci - I ve skutečnosti by tento přístup podporoval).

Snadná aktualizace během vývoje, nasazení a testování

Proměnné prostředí lze snadno aktualizovat pomocí výše uvedeného souboru .env a dotenv modulu. Varianty tohoto souboru lze také vytvořit a využít tak, aby vyhovovaly každému příslušnému prostředí. Import našich proměnných prostředí ve scénáři testování funguje téměř stejným způsobem (import env se liší od příslušného souboru dotenv).

K nasazení na pracovní nebo produkční server stačí použít alternativní verzi souboru .env. To lze snadno provést ignorováním existujícího souboru .env ve vašem systému pro správu verzí místně (obvykle git) a vytvořením nové kopie v každé instanci fáze / serveru.

Proměnné prostředí se také pěkně integrují do systémů Continuous Integration Systems (CI). Například kruh CI má vyhrazenou sekci pro správu proměnných prostředí, kde je lze přidat na úrovni sestavení projektu a aktualizovat na jednom místě, když je připraveno k nasazení -

Z pohledu Parameter Store je to jazyk / framework agnostický, což znamená, že veškeré nastavení bude třeba provést ručně pomocí AWS SDK s programovým přístupem ke službě Parameter Store, nebo podobně prostřednictvím poskytovatele třetí strany (jako je modul npm) . Zatímco AWS a její služby jsou měřítkem bezpečnostních standardů v oblasti cloud computingu, vlastní moduly, které byste mohli chtít vyvinout nebo využít, mohou mít bezpečnostní chyby kvůli špatnosti nebo dohledu - s ohledem na to, že existují pro tento účel přijatelné moduly, které jsou udržovány a podporovány důvěryhodnými subjekty, jako jsou samotné AWS.

Z pohledu nasazení / testování přichází Parameter Store také s jedinečnou sadou výzev, protože ačkoli existují doporučené přístupy, jak a kdy se rozhodnete pro interakci s Parameter Store, je zcela na vás.

Proměnné prostředí jsou k dispozici zdarma

Ačkoli Parametr Store AWS nezahrnuje dodatečné poplatky (https://aws.amazon.com/systems-manager/pricing), struktura cen Amazonu pro související služby, jako je KMS (https://aws.amazon.com/kms/pricing) ) začnou na základě používání vznikat další náklady. Na druhé straně je použití proměnných prostředí zdarma.

Proč tedy nahradit proměnné prostředí? : případ pro ukládání parametrů

Až do tohoto okamžiku se zdá, že řešení proměnné prostředí vanilky lemuje sklad parametrů v závodě o dominanci ve scéně / zabezpečené proměnné aréně. Přestože se zdá, že Parameter Store vytváří více výzev, než se v tomto bodě řeší, existuje několik věcí, které však Parameter Store nesporně vedou lépe než proměnné prostředí:

Proměnné úložiště parametrů lze sdílet mezi více projekty

Nejlepší nastavení, které jsem našel pro sdílení proměnných prostředí napříč projekty, je použití automatizovaného procesu nasazení, který načte proměnné prostředí ze souboru obsaženého ve sdílené entitě, například kbelík S3, který se podle potřeby připojuje k konfiguraci projektu (obvykle se provádí prostřednictvím skript, který je spuštěn ze služby CI). Z předchozích zkušeností je to nejsémantičtější možnost (dejte nám vědět, pokud máte zkušenosti s lepšími možnostmi). Toto je bohužel zdlouhavé cvičení zpočátku a nakonec to není něco, co byste chtěli dlouhodobě udržovat ručně, což je hlavně proto, že jakékoli chyby nebo přehlédnutí na cestě při jeho nastavování nebo údržbě by mohly vést k problémům.

Všechno, co můžeme předat službě AWS k automatizaci, bychom měli a zde svítí Parameter Store. Sdílení klíčů KMS a proměnných úložiště parametrů napříč projekty je vyprodáno.

Chci ustoupit a podívat se na AWS z holistického pohledu. Amazon odvedl skvělou práci při správě všech aspektů cloud computingu a má celou řadu vývojových týmů věnovaných konkrétním službám, které se s vámi nikdy nebudeme moci replikovat. To v konečném důsledku znamená, že jakmile si zakoupíte „zážitek“ Amazonu, měli byste využít všechny služby navržené pro spolupráci pod hlavičkou cloudové infrastruktury AWS. Ačkoli to má své problémy (jako jste vy a já nyní zcela uzavřeni v AWS jako poskytovatel služeb), je v konečném důsledku snazší zbavit se všeho, co můžete, protože je to jedna menší věc, kterou si musíte dělat starosti - i když stojí trochu navíc.

Parametr Store může používat řízení přístupu

Díky specifické kontrole přístupu uživatelů je služba IAM jedním z největších atributů AWS, zejména pokud jde o řešení potenciálně citlivých informací, jako jsou klíče API nebo hesla. Koncept kontroly přístupu k proměnným prostředí v rámci vanilského smyslu (např. Pomocí dotenv přístupu) prostě není možností (pokud nejste ochotni vyvinout své vlastní řešení na míru - nebo se přesunout mimo oblast „osvědčených postupů“).

Hodnoty úložiště parametrů lze snadno aktualizovat

Aby bylo možné aktualizovat jakékoli hodnoty ve vašem Parametr Store, stačí vám odpovídající přístup k vašemu dashboardu AWS (nebo CLI), což znamená, že i netechničtí členové týmu mohou aktualizovat hodnoty s trochou zkušeností s dashboardem AWS.

Na straně proměnné prostředí argumentu aktualizace proměnných prostředí se stává problematické, protože obvykle pouze kvalifikovaní členové týmu, kteří mají přístup k oprávnění aktualizace serveru, budou mít přístup a aktualizovat je. Navíc se tím otevírá váš projekt na úroveň zranitelnosti, protože přihlášení do serveru a nepřetržitá aktualizace základních souborů projektu (i při automatickém nastavení) může vést k problémům.

KMS může šifrovat hodnoty parametrů snadno

I když se počáteční nastavení šifrovacích hodnot v úložišti parametrů může zdát trochu skličující, jakmile si na to zvyknete, je to docela jednoduché a dává smysl - i z netechnického hlediska. To je také skvělá vrstva zabezpečení, která je přidána, mimo krabici.

Je možné použít šifrování pro proměnné prostředí, které možná nebudete chtít ukládat v prostém textu, ale to může být obtížné nastavit a udržovat ručně.

Proměnné úložiště parametrů lze uspořádat

Výrobní a pracovní parametry jsou při používání úložiště parametrů spravovány na jednom místě, což zahrnuje třídění a filtrování parametrů a dokonce i přidání popisů k objasnění jejich účelu.

Z hlediska proměnné prostředí prostě nedostanete zastaralou organizaci proměnných. Spravovat několik proměnných prostředí může být dostatečně snadné, ale to je problematické, pokud je příliš mnoho proměnných pro ruční správu. Může být možné uspořádat proměnné prostředí do různých souborů a složek, ale ve skutečnosti pro to neexistuje reálné řešení, které by podle všeho zbytečně komplikovalo věci.

V konečném důsledku by rozhodnutí o tom, které z obou řešení použít, mělo být určeno složitostí a rozsahem projektu s přihlédnutím k výše uvedeným faktorům.

Závěr

Při rozhodování, zda použít proměnné Parameter Store nebo proměnné prostředí ke správě parametrů fáze / zabezpečení, je třeba vzít v úvahu další faktory, ale doufejme, že v tomto článku jsme se zabývali důležitými.

Pokud máte nějaké další faktory, o kterých si myslíte, že stojí za zvážení, rád bych slyšel vaše myšlenky.