Když automatizační nástroj operuje v produkčním prostředí, otázka udělení oprávnění je kritická. Požadavek jako „opravit toto nasazení“ předem nespecifikuje, jaké akce nástroj podnikne nebo jaký přístup bude potřebovat. Pokud mu udělíme příliš široká oprávnění, sebemenší chyba může mít nechtěné dopady na nesouvisející zdroje. Naopak, vyžadovat schválení každého jednotlivého kroku vede k únavě uživatele a rutinnímu odklikávání bez hlubšího zamyšlení.
Moderní přístup spočívá v tom, že automatizační nástroj nejprve problém prozkoumá, poté navrhne konkrétní plán akcí, který jasně ukazuje, co zamýšlí dělat a jaký přístup k tomu bude potřebovat. Schválením takového plánu se udělují dodatečná oprávnění potřebná k jeho realizaci. Uživatel tak má možnost důkladně zkontrolovat navrhovanou opravu, než povolí jakékoli změny.
Navržený plán je klíčový, protože přesně určuje požadovaná oprávnění. V případě selhání produkčního nasazení může nástroj nejprve prozkoumat nedávná nasazení a protokoly sestavení. Pro tuto fázi plně postačuje přístup pouze pro čtení, který umožňuje automatizované šetření. Pokud to vede k návrhu na nové nasazení, nástroj si vyžádá dodatečný přístup v rámci plánu, který uživatel může přezkoumat a schválit jedním rozhodnutím. Přístup je definován pomocí takzvaných "rozsahů" (scopes), což jsou pojmenované schopnosti rozpoznané autorizačním systémem platformy. Jakýkoli plán, který vyžaduje přístup nad rámec základního přístupu pro čtení, čeká na schválení jako celek, včetně veškerých úloh pouze pro čtení, které obsahuje. Pro delší vyšetřování může nástroj vytvořit plán pouze pro čtení, aby uživatel mohl sledovat jeho úkoly a pokrok.
Plán propojuje uživatelský záměr s tím, co má automatizační nástroj povoleno provést. Zahrnuje: Záměr: Požadovaný výsledek od uživatele. Práce: Úkoly navržené nástrojem k dosažení záměru. Přístup: Rozsahy oprávnění, které tyto úkoly vyžadují. Vynucení: Pověření a kontroly API, které vynucují omezení přístupu. Každý uložený plán zaznamenává své úkoly a průběh, s připojenými požadovanými rozsahy k jednotlivým úkolům. Popisy úkolů vysvětlují, proč je přístup potřeba, a rozsahy jsou kombinovány napříč celým plánem. Základní přístup pouze pro čtení aktuálně zahrnuje každý registrovaný rozsah začínající prefixem "read:". Plány vyžadují schválení, pokud požadují přístup nad tento základní rámec nebo zahrnují podporované externí akce, jako je otevření žádosti o sloučení (pull request) na GitHubu. Operace pouze pro čtení mohou stále odhalit citlivé informace, takže automatické schválení neznamená, že práce je bez rizika.
Máte nápad na web nebo aplikaci?
Proberme ho spolu — nezávazně, bez tlaku a s konkrétním doporučením dalšího kroku.
Důležitým principem je, že automatizační nástroj může využívat pouze ta oprávnění, která má již samotný uživatel. Nástroj funguje jako servisní aplikace, které uživatel autorizuje jednat jeho jménem v rámci týmu. Tato autorizace je omezena stávajícími oprávněními uživatele, takže schválením plánu nelze získat přístup, který uživatel sám nemá. Autorizační služba poté vymění tuto autorizaci za krátkodobé tokeny s přesně definovanými rozsahy, které určují povolené schopnosti, jako je čtení nasazení nebo změna nastavení projektu. API platformy kontrolují token při každém požadavku, aby vynutily tato omezení. Uživatel může autorizovat nástroj pro tým s desítkami projektů. Plán nového nasazení vyžaduje přístup pro zápis do nasazení. Úprava proměnných prostředí, změna domén a správa členství v týmu vyžadují každé svá vlastní oprávnění. Přístup pro zápis do nasazení je širší než jedno konkrétní nové nasazení. Pojmenování „nasazení X“ v plánu samo o sobě neomezuje token pouze na toto nasazení. Běhové prostředí, software, který koordinuje spuštění nástroje, ověřuje, že je plán aktivní před výběrem jeho schválených pověření. API platformy kontrolují každý požadavek proti oprávněním těchto pověření.
Schválení plánu přesně určuje, jaká oprávnění může automatizační nástroj využít. Když uživatel schválí plán, který potřebuje dodatečný přístup k funkcím platformy, jsou znovu zkontrolovány požadované rozsahy a připraví se token obsahující základní oprávnění pro čtení plus schválená oprávnění. Běhové prostředí zkontroluje, že plán je aktivní, před výběrem schválených pověření. Tato pověření zůstávají podřízena svým rozsahům, týmu, oprávněním uživatele a době platnosti. Instrukce řídící chování nástroje mu napovídají, kdy má navrhnout plán a požádat o schválení. Pokud se pokusí provést operaci mimo oprávnění tokenu, API platformy požadavek zamítnou, i kdyby nástroj danou akci považoval za nezbytnou k dokončení úkolu. Jeden plán může zahrnovat změny v rámci platformy i žádost o sloučení na GitHubu. Uživatel přezkoumá obě akce v jednom plánu, přičemž každý poskytovatel používá samostatná oprávnění a pověření. Přístup k žádosti o sloučení na GitHubu je vázán na vlastníka a repozitář, takže schválení pro otevření žádosti v `acme/storefront` platí pro tento repozitář, i když uživatel má přístup i k `acme/payments`. Otevření žádosti tam by vyžadovalo samostatné schválení.
Pro zajištění konzistence a předejítí nesrovnalostem je klíčové, aby plány a tokeny využívaly stejné definice oprávnění. V minulosti jsme udržovali oddělený seznam oprávnění pro nástroj, který se mohl rozcházet s autorizační službou, jež vydává tokeny. Přešli jsme na stejné definice rozsahů, aby se tyto neshody mohly zachytit již během plánování. Během nastavení relace nástroj načte tyto definice z registru rozsahů platformy do interního katalogu. Načtení registru vyžaduje autorizaci pro tým, zatímco samotné definice rozsahů jsou sdíleny napříč týmy. Katalog pak poskytuje definice používané ve třech fázích: Validace plánu: Požadované rozsahy jsou normalizovány a neznámé nebo špatně formátované názvy jsou zamítnuty, ještě před uložením nebo prezentací plánu ke schválení. Schvalování: Požadované rozsahy určují, zda se plán vejde do základních oprávnění pro čtení, nebo potřebuje dodatečný přístup. Příprava tokenu: Platné rozsahy definují pověření pro schválenou práci. Například úkol pro aktualizaci pravidel firewallu může požadovat zastaralý rozsah. Systém zamítne navržený plán a vrátí platné rozsahy, aby nástroj mohl provést opravu před požadavkem na schválení. Tím se nesrovnalosti zachytí již během plánování a vyžaduje se explicitní korekce namísto návratu k širšímu přístupu. Načtení registru přidává latenci a závislost na službě, proto nástroj ukládá katalog do mezipaměti a používá tuto kopii k ověřování uložených plánů při jejich načítání. Tyto kontroly odrážejí definice z mezipaměti, dokud není katalog obnoven změnami z registru.
Pro obnovení práce je nezbytný aktivní a schválený plán. Může se stát, že nástroj obdrží schválení poté, co původní požadavek skončil, nebo ztratí spojení před provedením schváleného nasazení. Uložený plán obsahuje svůj stav, kdo a kdy ho schválil, spolu s jeho úkoly a požadovanými oprávněními. Tento záznam propojuje navrženou práci s přístupem, který uživatel autorizoval, a umožňuje ověřit schválení při obnovení práce. Před obnovením běhové prostředí znovu načte plán a zkontroluje, zda je aktivní, před výběrem pověření s jeho schválenými oprávněními. Zastavený plán tuto kontrolu neprojde, i kdyby měl token ještě platnost. Pokud vyšetřování odhalí, že stávající plán je třeba nahradit, nástroj může navrhnout jiný. Náhradní plán vyžadující zvýšená oprávnění potřebuje vlastní schválení, čímž uživatel získává možnost přezkoumat revidovanou práci a oprávnění dohromady.
Jak se automatizační nástroje rozšiřují do dalších oblastí platformy, musíme korigovat pravidla přístupu pro akce, které zahrnují více zdrojů nebo mají různé důsledky. Například připojení domény může vyžadovat oprávnění pro doménu i projekt, zatímco příprava pravidla firewallu a jeho publikování potřebují různé úrovně přístupu. Rozsahy oprávnění musí tyto odlišnosti přesně zachycovat, přičemž požadavek na přístup v každém plánu musí zůstat srozumitelný. Přesné přiřazení těchto rozsahů k navrhovanému řešení vyžaduje pečlivost v celém plánovacím procesu: Volba rozsahů: Nástroj volí rozsahy s neúplnými informacemi, takže může požadovat příliš málo přístupu (a ponechat úkol zablokovaný) nebo příliš mnoho (a udělit větší autoritu, než práce potřebuje). Návod na úrovni úkolů mu pomáhá s volbou, zatímco validace zachytává neplatné názvy rozsahů. I platný rozsah může udělit širší přístup, než je nezbytné. Popis práce: „Znovu nasadit poslední úspěšnou sestavení“ dává uživateli konkrétní akci k posouzení, zatímco samotné názvy rozsahů je nutí domýšlet důsledky. Plán musí vysvětlit zamýšlenou změnu a jasně naznačit, jaká omezení token skutečně vynucuje. Pochopení zamítnutí: Zamítnutá operace může indikovat chybějící rozsah, nesprávný zdroj nebo operaci, která by měla zůstat zablokovaná. Nástroj musí tyto případy rozlišit před požadavkem na dodatečná oprávnění.
I se správnými oprávněními vyžaduje nové nasazení posouzení, zda je vybraný commit bezpečný k implementaci. To závisí na aplikaci, povaze selhání a navrhované opravě. Uživatel potřebuje dostatek informací k posouzení volby a nástroj musí akci správně provést. Vyšetřování pouze pro čtení také vyžaduje kontroly nad získanými informacemi, včetně citlivé konfigurace projektu a provozních detailů. Základní přístup pouze pro čtení byl zvolen, aby nástroj mohl provádět vyšetřování před žádostí o schválení, a tato volba potřebuje neustálou revizi, jak se mění rozsahy a informace, které odhalují. Jiné systémy mohou potřebovat užší základní oprávnění. Samostatné kontroly musí řídit, jak se s získanými informacemi nakládá a kam mohou jít. Nástroj může učinit špatné rozhodnutí nebo narazit na škodlivé instrukce v obsahu, který čte, například v logách sestavení. Omezená pověření omezují operace, které může v obou případech provádět, ale i povolené operace mohou způsobit škodu. Plány proto fungují společně s izolací v sandboxu, síťovou politikou, nakládáním s tajnými informacemi, limity rychlosti, auditními záznamy a autorizací služeb. Práce na bezpečnostních hranicích v agentních architekturách objasňuje oddělení mezi agentem, jeho pověřeními a kódem, který provádí.
Tento přístup zajišťuje, že autorita zůstává pevně spojena s konkrétní prací, která ji vyžaduje. Běhové prostředí vybírá schválená pověření pro aktivní plán a jeho rozsahy přesně definují, jaké operace může automatizační nástroj provádět. Díky předchozímu vyšetřování má uživatel možnost posoudit navržené řešení a s ním spojený požadovaný přístup v jednom komplexním kroku.