Jedním z nejvíce frustrujících problémů při vývoji aplikací je dnes parita prostředí. Zatímco poslední roky ukázaly, že nástroje pro virtualizaci a kontejnerizaci, jako jsou Vagrant a Docker (a vlastní nástroj State Tool společnosti ActiveState), mohou zajistit, aby operační systémy a závislosti, které pohánějí infrastrukturu aplikace, byly v různých prostředích konzistentní, externí závislosti je v neprodukčním prostředí téměř nemožné replikovat.
Ve světě, kde se závislosti třetích stran nenávratně propletly s hlavní obchodní logikou téměř každého softwarového projektu, je stále obtížnější udržet vývojové, stagingové a produkční prostředí vzájemně konzistentní. Některé produkty s vlastními vzhledovými řešeními – například Minio na Amazon S3 – sice ulehčují správu více nasazení jedné služby, ale jen málo usnadňují správu konfigurace v různých prostředích.
Když produkční, stagingové, vývojové, Bobův lokální stroj a prostředí QE vyžadují různé nasazení dané služby, předávání konfiguračních souborů tam a zpět nebo spoléhání na složité podmínky pro určení, se kterým nasazením má dané prostředí komunikovat, se stává stále nepraktičtějším. Potřeba flexibility také zdůrazňuje obtížnost těchto řešení v rozsáhlém prostředí. Co když například Bobův místní stroj potřebuje dočasně komunikovat se službou, která je vyhrazena pro prostředí Staging?“
Proměnné prostředí v jazyce Python
Konfigurace napříč prostředími je nepříjemná, ale naštěstí se výše uvedené problémy staly v posledních letech natolik běžnými, že jsou téměř vyřešeny. Díky podpoře komunity open source a evangelizaci osvědčených postupů, jako je aplikace 12 faktorů, došlo v posledních letech k posunu od správy konfigurace aplikací založené na souborech ke správě konfigurace založené na proměnných prostředí.
Proměnné prostředí, které jsou k dispozici ve všech hlavních operačních systémech, jsou – přesně jak naznačuje jejich název – proměnné, které jsou implementovány na úrovni prostředí a definují způsob, jakým se mají chovat aplikace běžící pod ním. Zjednodušeně řečeno se jedná o proměnné nezávislé na aplikaci, které jsou spravovány mimo kontext daného procesu. Hlavní výhodou používání proměnných prostředí je, že to vývojářům umožňuje definovat, jak má aplikace běžet, aniž by změnili řádek kódu.
Pokud například Bobův místní stroj potřebuje komunikovat se službou CDN, která je vyhrazena pro prostředí Staging, může změnit proměnnou prostředí CDN_URL tak, aby odrážela to, co je definováno v prostředí Staging, aniž by se musel dotknout jakéhokoli spravovaného kódu. Ještě důležitější je, že to Bobovi umožňuje definovat makety nebo interní služby pro použití s jednotkovými a integračními testy, a to vše bez nutnosti napsat jediný řádek kódu navíc.
Definování proměnných prostředí
Ačkoli je akt definování proměnných prostředí obecně závislý na operačním systému, naprostá většina programovacích jazyků tyto rozdíly abstrahovala pomocí vývojových balíčků, jako je projekt dotenv v jazyce Python. Například místo toho, aby bylo nutné definovat proměnnou prostředí API_USER na úrovni operačního systému, může lokálně gitignorovaný soubor .env udržovat proměnné prostředí napříč vývojovými prostředími. To umožňuje vývojářům využívat lokálně spravovaný konfigurační soubor pro nastavení proměnných prostředí a zároveň umožňuje konfiguraci prostřednictvím „pravých“ proměnných prostředí v jiných než vývojových prostředích.
Pro příklad uvádíme jednoduchý soubor .env, který může vývojář použít ve svém lokálním prostředí:
APP_ENVIRONMENT=localAPP_NAME=localhostQUEUE_DRIVER=syncAPI_USER=bob
Na druhé straně může produkční prostředí definovat své proměnné prostředí v rámci souboru Docker, přičemž obě tyto metody jsou platné pro udržování proměnných prostředí.
Získávání proměnných prostředí
Nezávisle na tom, jak jsou proměnné prostředí definovány, lze je v jazyce Python vždy získat pomocí metody os.getenv():
import os# Get environment variablesUSER = os.getenv('API_USER')
Vezměte na vědomí, že v případě, že je proměnná prostředí nedefinovaná, bude její hodnota výchozí None.
Začínáme s tajemstvími
Proměnné prostředí jsou sice vynikajícím řešením pro správu rozdílných konfigurací v různých prostředích, ale nejsou stříbrnou kulkou. V dnešním prostředí vývoje musí být bezpečnost nejvyšší prioritou a citlivá data musí být uchovávána bezpečným způsobem.
Proměnné prostředí samy o sobě bohužel nejsou bezpečné. Zatímco pro ukládání konfiguračních dat odvádějí skvělou práci, způsob, jakým definujeme citlivější údaje, jako jsou hesla, klíče API a šifrovací klíče, by měl vyžadovat větší péči. Zde přicházejí ke slovu tajemství. Tajemství by měla být zašifrována v klidovém stavu a měla by se načítat pouze při jednom spuštění podle potřeby, aby se snížila pravděpodobnost narušení dat. Tímto způsobem si můžete být jisti, že i v případě kompromitace poskytovatele hostingu jsou vaše citlivá tajemství pevně uzamčena.
Vytváření &Správa tajemství pomocí nástroje Stav
Jak tedy vytvářet a spravovat tajemství? I když existuje řada různých způsobů, jak tento problém řešit, nástroj State Tool od společnosti ActiveState je vynikajícím řešením pro jazyk Python. Podobně jako virtualenv nebo pipenv je State Tool rozhraním pro správu virtuálního prostředí, které zabrání křížové kontaminaci instalací a konfigurací jazyka Python mezi projekty. Od ostatních nástrojů pro správu virtuálních prostředí se liší integrací s platformou ActiveState, která umožňuje centrální rozhraní pro správu konfigurací prostředí a, ano, i tajemství.
Předtím, než budeme moci využít možností nástroje State Tool pro správu tajemství, musíme nejprve pomocí nástroje State Tool nastavit virtuální prostředí v adresáři našeho projektu. Za tímto účelem nejprve identifikujte projekt ActiveState, se kterým budete pracovat (pro tento tutoriál můžete použít můj projekt zachflower/envs-vs-secrets-demo, pokud máte bezplatný účet ActiveState Platform, nebo si můžete vytvořit vlastní). Poté proveďte příkaz state activate pro daný projekt:
$ state activate zachflower/envs-vs-secrets-demo Where would you like to checkout zachflower/envs-vs-secrets-demo? /home/zach/Projects/miscellaneous/activestate-variables/zachflower/envs-vs-secrets-demoActivating state: zachflower/envs-vs-secrets-demoThe State Tool is currently in beta, we are actively changing and adding features based on developer feedback.Downloading required artifactsDownloading 1 / 1 Installing 0 / 1 0 %You are now in an 'activated state', this will give you a virtual environment to work in that doesn't affect the rest of your system.Your 'activated state' allows you to define scripts, events and constants via the activestate.yaml file at the root of your project directory.To expand your language and/or package selection, or to define client-side encrypted secrets, please visit https://platform.activestate.com/zachflower/envs-vs-secrets-demo.To try out scripts with client-side encrypted secrets we've created a simple script for you in your activestate.yaml, try it out by running 'helloWorld'
Jak vidíte, příkaz activate nastaví virtuální prostředí tak, jak je definováno ve vašem projektu ActiveState. V případě, že projekt ještě nebyl nakonfigurován, bude nasazen jednoduchý projekt s výchozími parametry, abyste měli příklad, jak by vše mělo jít dohromady. Tato konfigurace je uložena v souboru v kořenovém adresáři vašeho projektu s názvem activestate.yaml.
Konfigurační soubor pro tajemství & Více
Soubor activestate.yaml definuje vývojové běhové prostředí, pod kterým bude vaše aplikace spuštěna. Ten výchozí například definuje jednoduchý skript, který využívá tajemství, a také několik posluchačů událostí, kteří provádějí akce, kdykoli nastane definovaná událost:
project: https://platform.activestate.com/zachflower/envs-vs-secrets-demoscripts:# This script uses a secret. Note that you can define your own secrets at# https://platform.activestate.com/zachflower/envs-vs-secrets-demo/scripts - name: helloWorld value: echo ${secrets.user.world}events: # This is the ACTIVATE event, it will run whenever a new virtual environment is created (eg. by running `state activate`) # On Linux and macOS this will be ran as part of your shell's rc file, so you can use it to set up aliases, functions, environment variables, etc. - name: ACTIVATE constraints: os: macos,linux value: | echo "You are now in an 'activated state', this will give you a virtual environment to work in that doesn't affect the rest of your system." echo "" echo "Your 'activated state' allows you to define scripts, events and constants via the activestate.yaml file at the root of your project directory." echo "" echo "To expand your language and/or package selection, or to define client-side encrypted secrets, please visit https://platform.activestate.com/zachflower/envs-vs-secrets-demo." echo "" echo "To try out scripts with client-side encrypted secrets we've created a simple script for you in your activestate.yaml, try it out by running 'helloWorld'"
Ačkoli zde není nic zvlášť převratného, potenciální síla tohoto souboru by měla být okamžitě zřejmá. Například následující skript poskytuje základní příklad využití tajemství v konfiguračním souboru:
scripts:# This script uses a secret. Note that you can define your own secrets at# https://platform.activestate.com/zachflower/envs-vs-secrets-demo/scripts - name: helloWorld value: echo ${secrets.user.world}
Při spuštění příkazu helloWorld (z aktivovaného stavu) se ozve hodnota tajemství user.world a v případě, že toto tajemství ještě není definováno, vyzve k zadání hodnoty:
$ helloWorldThe action you are taking uses a secret that has not been given a value yet.Name: worldDescription: - (This secret has no description, you can set one via the web dashboard)Scope: user (Only you can access the value) Please enter a value for secret "world": ******
Použití tajemství
Přestože je příklad poměrně zjednodušený, skutečná hodnota tajemství vychází z aktivačních událostí. Místo načítání hodnoty tajemství v rámci skriptu lze pomocí načtených tajemství definovat proměnné prostředí, aniž by tato tajemství byla kdy vystavena mimo toto zabezpečené prostředí:
project: https://platform.activestate.com/zachflower/envs-vs-secrets-demo?commitID=5fd1c161-c5a4-480c-8aba-29d8ab361b42events: - name: ACTIVATE constraints: os: macos,linux value: | export WORLD=${secrets.user.world}
Jestliže je definováno tajemství user.world, pak bude definována proměnná prostředí WORLD, kterou lze načíst jako jakoukoli jinou proměnnou prostředí:
$ echo $WORLDworld!
Jestliže však není definována, pak bude uživatel vyzván k její definici při aktivaci virtuálního prostředí ActiveState:
The action you are taking uses a secret that has not been given a value yet.Name: helloDescription: - (This secret has no description, you can set one via the web dashboard)Scope: user (Only you can access the value) Please enter a value for secret "world": ******
Pěkné, že?
Dál
Správa konfigurace při vývoji aplikací je z větší části vyřešená, ale správa tajemství prostě ještě ne. Počet projektů, které zkontrolovaly citlivá data v úložišti pro správu verzí, je ohromující a dělají to i velmi respektované společnosti, ale díky správné bezpečnostní hygieně a produktům, jako je State Tool společnosti ActiveState, je udržení citlivých konfiguračních dat v bezpečí den ode dne snazší.
- Vyzkoušejte si to sami vytvořením bezplatného účtu na platformě ActiveState a stažením nástroje State Tool, který zjednodušuje správu tajemství.
- Můžete se také podívat na náš webinář na téma Jak spravovat sdílená tajemství pomocí nástroje State Tool
Související blogy:
Tajemství správy sdílených tajemství
Vývojáři mohou sdílet tajemství rychle a snadno, aniž by obětovali bezpečnost
.