Menší platformový tým nemusí hned stavět interní vývojářský portál. Katalog služeb, šablony, dokumentace, Backstage a grafy spotřeby se mohou hodit později. První problém bývá přízemnější: kdo založí projektový prostor v Kubernetes, kdo nastaví práva, kdo omezí spotřebu, kdo povolí síť a kdo po čase uklidí zapomenutý sandbox.

InfoQ v červnu 2026 popsalo případ nizozemské daňové správy, která standardizovala zakládání prostředí v Kubernetes. Její otevřený projekt opr-paas je operátor pro „Project as a Service“: v Kubernetes spravuje oddělené prostory pro více týmů. Tým si nevytváří všechny objekty ručně. Popíše požadovaný projekt a operátor podle toho založí namespacy, RBAC, kvóty a volitelné části jako Argo CD, Tekton, Grafanu nebo Keycloak.

Zajímavý je hlavně zvolený tvar, ne konkrétní implementace. CNCF Platforms White Paper popisuje platformu jako sadu rozhraní: API, příkazový nástroj, šablony, portál nebo jejich kombinaci. Cenná je opakovatelná cesta k úkonům, které by týmy jinak pokaždé skládaly ručně.

Jedno YAML místo ručního zakládání

Kubernetes pracuje s deklarovaným stavem: tým popíše požadavek a řadič průběžně dorovnává realitu. Stejným způsobem lze popsat celý projektový prostor. Místo jednotlivých RoleBinding, ResourceQuota a síťových pravidel vznikne jedna projektová deklarace.

Zjednodušená deklarace by vypadala třeba takto:

apiVersion: platform.example.cz/v1alpha1
kind: ProjectEnvironment
metadata:
  name: checkout
spec:
  owner:
    team: payments
  namespaces:
    - name: dev
      quota:
        requests.cpu: "4"
        requests.memory: 8Gi
        pods: "40"
    - name: test
      quota:
        requests.cpu: "2"
        requests.memory: 4Gi
        pods: "20"
  access:
    groups:
      - name: payments-devs
        role: edit
      - name: payments-readers
        role: view
  network:
    defaultDeny: true
    allowDns: true
  ttl: 30d

Příklad ukazuje model, ne produkční manifest: projekt má vlastníka, prostředí, skupiny, limity, síťová pravidla a dobu platnosti. Platformový tým do deklarace zapíše pravidla, která by jinak končila ve wiki návodech nebo ticketech. Vývojový tým dostane méně voleb než při ruční práci a také méně pastí.

Namespace je jen začátek

Největší omyl u podobného modelu je představa, že namespace znamená izolaci. Dokumentace Kubernetes k multi-tenancy bere namespace jako základní organizační jednotku, ne jako samostatné bezpečnostní řešení. Bez dalších pravidel namespace hlavně říká, kam objekty patří.

První vrstva jsou práva. Lidé, CI, GitOps řadič a automatizace nemají sdílet jeden silný účet. Projektová deklarace má říct, která skupina smí nasazovat, kdo jen číst stav a jaké účty používají stroje. Oprávnění mají končit co nejblíž projektu, ne u pohodlného cluster-admin.

Druhá vrstva jsou zdroje. ResourceQuota omezuje souhrnnou spotřebu v namespace, LimitRange nastavuje výchozí nebo krajní hodnoty pro kontejnery. Bez nich se z dočasného testu snadno stane hlučný soused, který spotřebuje CPU, paměť nebo storage ostatním.

Třetí vrstva je síť. NetworkPolicy umí omezit provoz mezi pody, namespacy a IP rozsahy, ale jen když ji použitý síťový plugin vynucuje. Bez výchozího zákazu komunikace a výslovně povolených cest se projektové prostory v clusteru potkávají víc, než by si týmy často přály.

Čtvrtá vrstva je chování samotných běžících úloh. Pod Security Admission umí na úrovni namespace vynucovat, auditovat nebo varovat podle zvoleného profilu Pod Security Standards. Nový sandbox má začínat přísněji; výjimka patří do projektové deklarace, ne do ručního dodatku po prvním neúspěšném nasazení.

Kde malá platforma končí

Výhoda tohoto přístupu je v malém rozsahu. Platformový tým nemusí hned řešit celý katalog služeb, vlastnictví všech aplikací ani každou variantu nasazení. Stačí bezpečně a opakovatelně založit prostor, který se v organizaci vytváří pořád dokola.

Model musí mít i jasný konec. Pokud tým potřebuje vlastní CRD, admission webhook, zdroje platné pro celý cluster nebo spouští kód, kterému zbytek clusteru nemá věřit, obyčejný namespace nestačí. Pak je na místě virtuální cluster, samostatný cluster nebo jiný běhový model. Takové řešení stojí víc. Izolace se tím přesune ze sady pravidel nad sdíleným prostorem do samostatnějšího prostředí.

Opatrnost si zaslouží i samotný operátor. Má práva zakládat objekty za jiné týmy, a proto musí přísně validovat vstupy: hlavně odkazy mezi namespacy, názvy skupin, síťové výjimky a vše, co sahá na úroveň clusteru. Dobrá platforma chaos nezrychlí; zmenší počet míst, kde může vzniknout.

Agent potřebuje vlastní profil

Stejný model se hodí i pro agentní vývoj. Agent, který spouští testy, instaluje balíčky, vytváří náhledové prostředí nebo ladí migraci, nemá dědit práva člověka ani neomezený přístup ven ze sítě jen proto, že pracuje jeho jménem.

Rozumnější je samostatný profil: krátká platnost, vlastní účet, vlastní kvóta, omezený síťový přístup a audit akcí. Agent může v takovém prostoru rozbít testovací nasazení. Nesmí měnit cizí prostředí ani volat interní systémy, které k úkolu nepotřebuje. Pro nedůvěryhodný kód namespace pořád nemusí stačit. Tam je potřeba silnější izolace běhu.

Agenti jen zrychlují starý problém. Když člověk založil tři experimenty za měsíc, šlo leccos uhlídat ručně. Když podobné prostředí vzniká automaticky pro každou větev nebo úkol, slabé výchozí hodnoty se rychle násobí.

Nejdřív měřte prostředí

Portál může přijít později. Začátek se dá měřit jednodušeji: jak dlouho trvá vytvořit prostředí do stavu Ready, kolik ručních zásahů zmizelo, kolik sandboxů má vlastníka a expiraci, kolik projektů vzniká rovnou s kvótami, právy a síťovým omezením.

S Backstagem se takový přístup potkává v cíli, ne ve způsobu provedení. Začíná projektovou deklarací nad Kubernetes. Tým díky ní nemusí znát každý detail clusteru a platformový tým nemusí pokaždé znovu rozhodovat o stejných pravidlech. Portál se pak stane jedním rozhraním nad něčím, co už drží pohromadě.