BYOC úrovně oprávnění — jaký přístup nastavit, pro každého providera

BYOC úrovně oprávnění

Když připojíte vlastní cloud účet (BYOC — Bring Your Own Cloud) k Sencai, sami volíte, kolik přístupu poskytnete. Tahle stránka dává zaměstnancům Sencai i zákazníkům jednotnou referenci, co přesně vytvořit u každého providera, na čtyřech úrovních — od jen-čtení až po plně autonomní provoz.

Použijte tuhle stránku před vytvořením credentials v Gravity → Settings → Cloud Credentials — nejdřív zvolte úroveň, pak postupujte podle kroků per provider níže.

---

Čtyři úrovně

Každá sekce providera níže se mapuje na stejné čtyři koncepční úrovně. Ne každý provider umí všechny čtyři vyjádřit nativně na úrovni IAM — kde to neplatí, je to explicitně řečeno, ne předstíráno jako by jemnější volba existovala.

Úroveň	Co umožňuje	Typické použití
1 — Jen čtení	Inventory scan / import / discovery. Sencai vidí vaše resources, ale nikdy nic nemění.	První připojení, audity, cost visibility, compliance reporting
2 — Operátor	Čtení + nedestruktivní lifecycle akce (start/stop/reboot/resize). Žádné vytváření, mazání, žádné IAM/network změny.	Day-2 monitoring a patch management bez provisioning rizika
3 — Plný provisioning	Vytváření, úprava, mazání resources v rámci přiděleného scope (konkrétní resource group/projekt/účet, ne nutně celý cloud účet).	Sencai plně spravuje definovaný výsek vaší infrastruktury
4 — Autonomní	Stejná cloud-strany oprávnění jako úroveň 3, plus explicitní opt-in na Sencai straně (Gateway PEP autonomy_level: L3), který umožní AI agentovi jednat bez schválení člověkem per-akci.	Zralá nasazení, poté co úroveň 3 spolehlivě běžela

Úroveň 4 nikdy není jen cloudové IAM nastavení — vždy vyžaduje odpovídající rozhodnutí na Sencai straně (Gateway PEP, viz jak se to mapuje na Sencai’s Gateway PEP níže). Udělení úrovně-3-podobných cloud oprávnění samo o sobě autonomní chování NEzapíná.

Doporučený postup

Začněte na úrovni 1 u každého nového účtu. Přejděte na úroveň 2 nebo 3, jakmile vám bude komfortní to, co Sencai objeví. Úroveň 4 zvažte až poté, co úroveň 3 běžela proti reálné infrastruktuře bez překvapení.

---

AWS

AWS IAM politiky lze plně vyjádřit na úrovni JSON, takže všechny čtyři úrovně se mapují čistě.

Úroveň	IAM přístup
1 — Jen čtení	Připojit AWS-managed politiku ReadOnlyAccess, nebo užší vlastní politiku scoped na ec2:Describe*, rds:Describe*, s3:GetBucket*/s3:ListBucket, iam:List*/iam:Get*, route53:List*/Get* — podle toho, které služby chcete inventarizovat.
2 — Operátor	Oprávnění úrovně 1 plus ec2:StartInstances, ec2:StopInstances, ec2:RebootInstances. Explicitně zakázat (nebo prostě vynechat) ec2:RunInstances, ec2:TerminateInstances, iam:*, ec2:CreateSecurityGroup/DeleteSecurityGroup.
3 — Plný provisioning	Vlastní politika scoped podle tagu nebo regionu (Condition: { StringEquals: { "aws:RequestTag/ManagedBy": "sencai" } } je běžný vzor) pokrývající ec2:*, rds:*, elasticloadbalancing:* pro služby, které má Sencai spravovat — ne široká AWS-managed politika AdministratorAccess, která uděluje přístup daleko za rámec toho, co Sencai potřebuje.
4 — Autonomní	Stejné jako úroveň 3, plus zapnutí autonomy_level: L2/L3 na odpovídajícím Sencai agent-policy záznamu pro tuhle organizaci (akce Sencai admina, ne AWS-strany změna).

Jak připojit: vytvořit IAM uživatele (access key) nebo, lépe, IAM roli, kterou si Sencai’s platformní účet může cross-account assumnout (sts:AssumeRole) — role varianta se vyhne předání dlouhotrvajícího statického secretu Sencai. V obou případech zadat credentials v Gravity → Settings → Cloud Credentials → Add → AWS.

Upozornění

Dnešní výchozí onboarding flow žádá o široký AdministratorAccess kvůli jednoduchosti. Publikovaný, ready-to-attach least-privilege policy dokument pro každou úroveň je plánovaný, ale zatím není k dispozici — do té doby použijte seznam služeb výše jako výchozí bod a odeberte každou službu, ke které Sencai nepotřebuje přístup.

---

Azure

Azure Role-Based Access Control (RBAC) také vyjadřuje všechny čtyři úrovně, přes Service Principal (App Registration).

Úroveň	Azure RBAC role
1 — Jen čtení	Vestavěná role Reader, přiřazená na úrovni subscription nebo resource group.
2 — Operátor	Vlastní role udělující Microsoft.Compute/virtualMachines/start/action, .../restart/action, .../deallocate/action plus read akce Reader role — žádné write/delete na jakémkoliv resource typu.
3 — Plný provisioning	Vestavěná role Contributor, scoped na subscription nebo (raději) konkrétní resource group, kterou Sencai spravuje.
4 — Autonomní	Stejné jako úroveň 3, plus zapnutí autonomy_level: L2/L3 na odpovídajícím Sencai agent-policy záznamu (akce Sencai admina, ne Azure-strany změna).

Jak připojit:

1. Entra ID → App registrations → New registration.

2. Certificates & secrets → New client secret — zkopírovat hodnotu ihned, Azure ji znovu nezobrazí.

3. Subscription (nebo resource group) → Access control (IAM) → Add role assignment — přiřadit roli z tabulky výše nově vytvořené aplikaci.

4. Sesbírat čtyři hodnoty a zadat je v Gravity → Settings → Cloud Credentials → Add → Azure:

   Pole	Kde ho najít
   Subscription ID	Azure Portal → Subscriptions
   Tenant ID	App registration → Overview → Directory (tenant) ID
   Client ID	App registration → Overview → Application (client) ID
   Client Secret	Hodnota z kroku 2

Tenhle flow je stejný jako u zákaznického onboardingu — viz lkp-entraid.md (interní, nepublikováno zde) pro konkrétní příklad proti reálnému zákaznickému tenantu.

---

Google Cloud (GCP)

GCP IAM role se mapují na stejné čtyři úrovně přes Service Account.

Úroveň	GCP IAM role
1 — Jen čtení	Vestavěná roles/viewer, nebo užší předdefinované role jako roles/compute.viewer, pokud chcete inventarizovat jen compute.
2 — Operátor	Vlastní role s compute.instances.start, compute.instances.stop, compute.instances.reset plus read oprávnění ekvivalentní viewer roli — žádné compute.instances.create/delete, žádná IAM oprávnění.
3 — Plný provisioning	Vestavěná roles/compute.admin (nebo roles/editor, pokud má Sencai spravovat víc než jen Compute Engine), scoped na konkrétní projekt, nikdy organization-wide.
4 — Autonomní	Stejné jako úroveň 3, plus zapnutí autonomy_level: L2/L3 na odpovídajícím Sencai agent-policy záznamu (akce Sencai admina, ne GCP-strany změna).

Jak připojit: vytvořit Service Account (IAM & Admin → Service Accounts), udělit mu jednu z rolí výše, pak vytvořit a stáhnout JSON klíč. Nahrát JSON klíč v Gravity → Settings → Cloud Credentials → Add → GCP.

---

Hetzner Cloud

Hetzner API tokeny mají jen dvě nativní úrovně oprávnění — na providerské úrovni neexistuje IAM systém, ze kterého by šel postavit 4-úrovňový žebřík:

Typ Hetzner tokenu	Odpovídá
Read	Úroveň 1 (jen čtení) — tohle je celý nativní strop
Read & Write	Úrovně 2, 3 a 4 nejsou na úrovni Hetzner API rozlišitelné — Read & Write token umí start/stop, vytvořit i smazat stejně

Protože Hetzner sám neumí vynutit “operátor, ne plný provisioning”, skutečné rozlišení úrovní 2/3/4 na Hetzneru žije výhradně v Sencai’s vlastním Gateway PEP — agent-policy záznamu allowed_action_types/blocked_action_types polí (a autonomy_level) — to je to, co skutečně brání Read & Write Hetzner tokenu být použit pro destruktivní akce, ke kterým Sencai nebyl autorizován, ne nic, co kontroluje sám Hetzner.

Jak připojit: Hetzner Cloud Console → Security → API Tokens → Generate API Token → zvolit Read nebo Read & Write → zadat token v Gravity → Settings → Cloud Credentials → Add → Hetzner.

Poznámka

Hetzner’s vlastní live-inventory scan (discoverResources()) dnes pokrývá jen server (VM) resources — floating IPs, volumes, networks a load balancers zatím nejsou skenovány, stejný “začni s compute” vzor, jaký měl na začátku i každý jiný provider.

---

Scaleway, OVHcloud, UpCloud

Provisioning adaptery pro tyto tři providery existují, ale live-inventory scan (discovery) zatím není implementován pro žádného z nich (pořád stub vracející nic, stejný historický výchozí stav, jaký měl Hetzner před vlastní implementací discovery). Pokud potřebujete importovat existující infrastrukturu od jednoho z těchto providerů dnes, jediná cesta je přes import Terraform state souboru (viz Import existující infrastruktury), ne živý scan účtu.

Doporučení pro úrovně oprávnění u těchto tří přibude, jakmile přistanou jejich vlastní discovery implementace — do té doby berte jakoukoliv credential vytvořenou pro ně jako úroveň 3 (plný provisioning) defaultně, protože pro ně zatím neexistuje jen-scan use case, pro který by dávalo smysl udělit úroveň 1.

---

DigitalOcean, Vultr, Linode

Zatím nepodporováno. DigitalOcean má v Sencai’s seznamu providerů placeholder, ale zatím žádný fungující adapter za ním (“not implemented”, pokud se ho pokusíte použít). Vultr a Linode zatím nejsou v platformě reprezentované vůbec. Nevytvářejte BYOC credentials pro tyhle providery — na Sencai straně dnes nic, co by je použilo.

---

Jak se to mapuje na Sencai’s Gateway PEP

Každá organizace dostane při vytvoření defaultní permisivní politiku (autonomy_level: L2) — cloud-strany oprávnění (úrovně výše) a Sencai-strany politika jsou dvě nezávislé brány, obě musí akci povolit, aby se skutečně stala:

• L0 (jen pozorování) — žádná mutující akce není povolena bez ohledu na cloud IAM oprávnění.
• L1 (jen návrh) — povoleny jsou jen akce iniciované reálným, autentizovaným člověkem; cokoliv označené jako system/agent-iniciované je zablokováno.
• L2 (proveď se schválením) — akce matchující politiky allowed_action_types proběhnou (tohle je default pro nové organizace).
• L3 (auto-proveď) — stejná sada akcí jako L2, ale bez human-approval brány před ní — tohle je to, na co se skutečně odkazuje úroveň 4 výše.

Změna autonomy_level vaší organizace je akce Sencai admina (Gravity → Settings → Agent Policies, nebo se zeptejte svého Sencai kontaktu) — nikdy se neuděluje automaticky jen proto, že jste dali širší cloud-strany oprávnění. Viz Gateway architektura pro plný technický detail enforcement modelu.