AUTOMATIZUJTE
INFRASTRUKTURU.
NE RUTINU.
Pampeliška 3.0 je IaC platforma postavená na open-source komponentách pro automatizaci správy ICT technologií. Nasazujte, konfigurujte a monitorujte síťové prvky, servery, certifikáty a další technologie jako programovatelné objekty — bez licenčních poplatků a bez vendor lock-inu.
NAMESPACE NAME READY STATUS
semaphore semaphore-7d9f8b-xk2p4 1/1 Running
postgres-system pampeliska-db-1 1/1 Running
postgres-system postgrest-5c6d4f-mn8q1 1/1 Running
pki step-certificates-0 1/1 Running
Každá ruční konfigurace je technický dluh
Maximální platnost veřejných TLS certifikátů od března 2029. Od 15. 3. 2026 platí 200 dní, od března 2027 100 dní. Ruční obnova přestává být udržitelná.
CA/Browser Forum, Ballot SC-081v3
Subjektů podle odhadu NÚKIB spadne pod nový zákon o kybernetické bezpečnosti (č. 264/2025 Sb.). Pro všechny je zavedení bezpečnostních opatření povinné.
Zdroj: NÚKIB, průvodce novým zákonem o kybernetické bezpečnosti; BusinessInfo.cz: Nový zákon o kybernetické bezpečnosti dopadne na šest tisíc subjektů
Nekonzistentní konfigurace, „zombie“ objekty a konfigurační ostrovy jako přímý důsledek manuální správy
Infrastructure as Code. Prakticky.
Každá SW nebo HW technologie je programovatelný objekt.
Zjednodušení a zrychlení
Ansible playbooky a Python skripty spouštěné přes webové rozhraní Semaphore UI. Žádné přihlašování na servery, žádné manuální kroky.
Konzistence konfigurací
Playbooky, role a manifesty v Gitu s historií a revizemi. Flux CD průběžně srovnává Kubernetes vrstvu platformy se stavem deklarovaným v Gitu a odchylky sám vrací.
Centralizace dat
Konfigurační a stavová data spravovaných technologií v PostgreSQL s automatickým REST API. Napojení na CMDB, CI/CD nebo vlastní nástroje přes standardní HTTP.
Škálovatelnost
Kubernetes-nativní architektura (K3s) na 3 VM. Referenční provisioning je zakládá sám na hostiteli LXD/MicroCloud — referenčním prostředím je Canonical MicroCloud (LXD, Ceph, OVN); jinou virtualizaci (VMware, cloud) přizpůsobíme v onboardingu. Nová technologie = nový Ansible modul nebo playbook.
Bezpečnost od výchozího stavu
Automatická rotace TLS certifikátů z vlastní CA pro workloady s cert-manager Certificate (wildcard certifikát pro webová rozhraní dodáváte vy), šifrované secrets v Gitu (Sealed Secrets), WireGuard mezi uzly, NetworkPolicy (default-deny pro příchozí provoz) pro aplikační a datové namespaces, Pod Security Admission, hostový firewall a CIS hardening uzlů, šifrování secrets v etcd, auditní log Kubernetes API a průběžné skenování zranitelností (Trivy). Přístupové údaje ke spravovaným zařízením drží centrální trezor tajemství OpenBao — dostupný jen ze správcovských sítí, s blokací účtu po opakovaném chybném přihlášení a s auditem každého přístupu. Flux nasadí jen revize s podepsaným posledním commitem (GPG). Napojení na firemní identitu (LDAP/SSO) je katalogová integrace.
Tři servery. Výpadek jednoho uzlu ustojí.
Řídicí vrstva K3s i data běží na všech třech uzlech. Jak se při výpadku chovají jednotlivé komponenty, ukazuje tabulka vysoké dostupnosti pod diagramem.
| KOMPONENTA | VRSTVA | ROLE |
|---|---|---|
| K3s v1.36 | Orchestrace | HA cluster, 3 server uzly, embedded etcd |
| Semaphore UI | Automatizace | Webové UI pro Ansible, Python, Bash |
| PostgreSQL 16 + CloudNativePG | Konfigurace DB | Relační DB + grafový model (nodes/edges), operátor s automatickým failoverem a zálohami, pooler PgBouncer (2 instance) |
| PostgREST | API vrstva | Automatické REST API z DB schématu |
| Gitea | Source Control | Interní Git server (zdroj pro Flux), playbooky, manifesty |
| Flux CD | GitOps | Průběžné srovnávání Kubernetes vrstvy s Gitem |
| step-ca | PKI / CLM | Online Issuing CA, ACME server |
| cert-manager | CLM | Automatický request/renew certifikátů |
| Longhorn | Úložiště | Replikované blokové úložiště (CSI) |
| Traefik v3 | Edge routing | Ingress, TLS terminace, load balancing |
| kube-vip + MetalLB | Síť | Virtuální IP pro Kubernetes API, pevné IP pro ingress a CA |
| Prometheus | Observability | Sběr a ukládání metrik (TSDB) |
| Grafana + ECharts | Vizualizace | Dashboardy, alerting, grafové zobrazení |
| Loki + Grafana Alloy | Log management | Sběr a agregace logů včetně auditu Kubernetes API; výchozí retence 30 dní, delší s objektovým úložištěm |
| Sealed Secrets | Bezpečnost | Šifrované Secrets v Git repozitáři |
| OpenBao | Tajemství | Trezor přístupových údajů pro automatizaci, audit, HA (Raft) |
| Trivy Operator | Bezpečnost | CVE skenování images, SBOM každého image |
| ntfy + Alertmanager | Alerting | Self-hosted notifikace bez cloudové služby |
Vysoká dostupnost po komponentách
| KOMPONENTA | REŽIM | PŘI VÝPADKU UZLU |
|---|---|---|
| K3s – řídicí vrstva (etcd) | 3 uzly, kvórum | Pokračuje bez přerušení |
| Longhorn – data | 2 repliky na různých uzlech (PostgreSQL a OpenBao: 1 lokální replika, data replikuje databáze, resp. Raft) | Data dostupná ze zbylé repliky |
| PostgreSQL 16 (CloudNativePG) | Primár + synchronní replika + další replika | Automatické přepnutí na repliku bez ztráty potvrzených transakcí |
| Traefik, PostgREST | 2 repliky na různých uzlech | Pokračuje bez přerušení |
| OpenBao | 3 repliky (Raft) | Volba lídra, krátké přepnutí |
| Semaphore UI (Community), Grafana, Prometheus, Alertmanager, Loki, step-ca, cert-manager, ntfy | 1 instance | Přeplánování na jiný uzel, výpadek v řádu minut |
| Gitea (zdroj pro Flux) | 1 instance, lokální úložiště uzlu | Nedostupná do návratu uzlu; běžící workloady pokračují, nové změny se nenasazují |
Semaphore UI: globální runnery má i edice Community; projektové runnery (Pro), aktivní-aktivní HA (Enterprise). Pampeliška placené edice nevyžaduje. Výpadek celého clusteru řeší obnova ze záloh — viz cílové provozní parametry.
Ověřeno v provozu
Referenční nasazení běží na Canonical MicroCloud — 3 fyzické servery s LXD (virtuální stroje), Ceph (úložiště VM) a OVN (síť).
| OBLAST | OVĚŘENO |
|---|---|
| Prostředí | 3 VM clusteru rozložené na všechny 3 servery, úložiště záloh (Garage, S3) v samostatné VM; virtuální IP pro Kubernetes API, ingress a CA fungují i v síti OVN |
| Verze | K3s v1.36.5, Ubuntu 24.04.5 LTS, PostgreSQL 16 (CloudNativePG, 3 instance), OpenBao (3 repliky, Raft, automatické odpečetění) |
| GitOps a úložiště | Flux: 9/9 vrstev a 15/15 Helm releasů v pořádku, nasazuje jen revize s podepsaným posledním commitem (GPG); Longhorn: 16 svazků zdravých |
| Zálohy | Průběžná archivace WAL a denní plná záloha PostgreSQL do S3 (obnova k libovolnému okamžiku), denní zálohy svazků Longhorn, snapshoty etcd každých 6 h lokálně i do S3, denní snapshot VM se zálohami na hostiteli. V referenčním prostředí sdílí úložiště záloh hardware a Ceph s clusterem — pro produkci (DORA čl. 12 odst. 3: obnova na systémech fyzicky i logicky oddělených od zdrojových; zálohy doporučujeme držet mimo hardware clusteru) S3 na samostatném hostiteli nebo mimo lokalitu. |
| Tajemství | Semaphore UI se do OpenBao přihlásí krátkodobým tokenem ServiceAccountu a dostane jen čtecí politiku; přístup jen ze správcovských sítí |
| Vstup a alerty | Webová rozhraní přes Traefik s wildcard certifikátem; alerty se doručují do ntfy, anonymní zápis je odmítnut |
| Doba instalace | Od prázdného MicroCloudu po všechny služby v pořádku zhruba hodina |
MINIMÁLNÍ NASAZENÍ
Počet VM: 3 (K3s HA)vCPU / VM: 4
RAM / VM: 8 GB
Disk / VM: 40 GB systém + 60 GB data (SSD)
OS: Ubuntu 24.04 LTS
Síť: 3 pevné IP (API VIP, ingress, CA)
Hostitel: LXD/MicroCloud pro VM clusteru
Zálohy: S3 na samostatném hostiteli
Celkem RAM: 24 GB
Naměřeno: ~13 GB RAM z 24 GB (~55 %)
Doporučeno: 12 GB RAM/VM (rezerva pro výpadek uzlu)
Certifikáty, které se obnovují samy
Platí pro workloady s cert-manager Certificate a pro externí servery obsluhované
playbookem. Wildcard certifikát pro webová rozhraní platformy dodáváte vy a jeho výměna je ruční krok.
Detekce expirace
S předstihem (výchozí ⅓ platnosti)
Automatický CSR
cert-manager generuje žádost
Vydání step-ca
step-issuer v clusteru; externí servery přes step CLI (JWK provisioner), ACME k dispozici
Nasazení
Kubernetes Secret aktualizován
Hot-reload
Aplikace načte nový certifikát
Přehled stavu
Grafana: dashboard Certificate Expiry
| VRSTVA | KOMPONENTA | POPIS |
|---|---|---|
| Root CA (Tier 1) | Offline Root CA | V produkci offline kořenová CA (HSM/USB) nebo podřízení vaší firemní PKI — nastavíme v onboardingu; referenční nasazení generuje demo kořen |
| Issuing CA (Tier 2) | step-ca | Online CA; ACME server; běží jako K8s Pod; klíč volitelně v HSM (PKCS#11) |
| Cert Manager | cert-manager | K8s operátor pro automatický request/renew |
| Trust Distribution | trust-manager | Distribuce CA bundle do všech workloadů |
Vidíte celou infrastrukturu. Jako graf.
Ukázkové dashboardy (Grafana + ECharts) nad demo daty; napojení na grafový model nodes/edges a vaše zdroje je součástí onboardingu.
ICT Topology Graph
Force-directed síťový graf spravovaných zařízení a jejich propojení (ukázková data).
Stack: Grafana + Apache ECharts plugin
Firewall Rule Flow
Sankey diagram toků dat mezi bezpečnostními zónami (ukázková data).
Stack: Grafana + ECharts Sankey
Certificate Chain Tree
Hierarchický strom PKI řetězce (Root CA → Issuing CA → leaf certs); koncové certifikáty se načítají živě z evidence certifikátů v PostgreSQL.
Stack: Grafana + ECharts Tree
Dependency Impact Map
Vizualizace závislostí služeb a dopadu výpadku jednoho prvku (ukázková data). Dopadovou analýzu nad grafem nodes/edges nabízí REST API funkcí get_impact_radius.
Stack: Grafana + ECharts + PostgreSQL
Soulad s regulacemi. Od prvního dne.
Pampeliška 3.0 je navržena v přímé vazbě na platný regulatorní rámec. Každá architektonická volba má konkrétní mapování na standard nebo předpis. Platforma pokrývá technická opatření; procesy jako řízení rizik nebo hlášení incidentů zůstávají odpovědností organizace.
| POŽADAVEK | STANDARD / REGULACE | IMPLEMENTACE |
|---|---|---|
| Síťová segmentace | ISO 27001 A.8.22Zákon č. 264/2025 Sb., vyhlášky č. 409/2025 a 410/2025 Sb. |
K8s NetworkPolicy (default-deny pro příchozí provoz), WireGuard, hostový firewall uzlů |
| Auditní záznamy | ISO 27001 A.8.15DORA – RTS (EU) 2024/1774, čl. 12Vyhláška č. 409/2025 Sb., § 22 odst. 5 písm. c) — uchovávání záznamů událostí alespoň 18 měsíců (režim vyšších povinností) |
Loki + Grafana Alloy, auditní log Kubernetes API; retence ≥ 18 měsíců podle vyhlášky č. 409/2025 Sb. s objektovým úložištěmNapojení na SIEM zákazníka — katalogová integrace (export Loki → SIEM) |
| Šifrování při přenosu | DORA čl. 9ISO 27001 A.8.24 |
TLS 1.2+ (preferováno 1.3), certifikáty ze step-ca s automatickou rotacíWireGuard mezi uzly |
| Správa tajemství a přístupových údajů | ISO 27001 A.5.17ISO 27001 A.8.24 |
OpenBao: šifrované úložiště, audit přístupů, nejmenší oprávněníKrátkodobé tokeny přes Kubernetes ServiceAccount |
| Správa aktiv | COBIT 2019 BAI09NIST CSF 2.0 ID.AM |
Trivy SBOMFlux CD inventarizace |
| Řízená konfigurace | COBIT 2019 BAI10 | Historie změn v Gitu, GitOps (Flux CD) jen z revizí s podepsaným posledním commitem (GPG)Auditní log změn grafového modelu v PostgreSQL |
| Viditelnost závislostí | COBIT 2019 BAI10DORA čl. 8 |
Grafový model (nodes/edges)ECharts vizualizace |
| Zálohy a obnova | DORA čl. 12ISO 27001 A.8.13 |
Zálohy mimo cluster (etcd, PostgreSQL, Longhorn)Kopie mimo dosah clusteru (denní snapshoty úložiště záloh na hostiteli), doporučený čtvrtletní test obnovy |
| Kontinuita provozu | ISO 22301COBIT 2019 DSS04 |
K3s HA, Longhorn replikaceCílové RPO ≤ 1 h pro PostgreSQL (svazky ≤ 24 h, etcd ≤ 6 h), RTO ≤ 2 h |
| Exit strategie | DORA čl. 28 odst. 8DORA čl. 30 odst. 3 písm. f) |
Otevřené formáty (CSV/JSON, Git)Předávací protokol, přechodné období ve smlouvě |
| Ochrana osobních údajů | GDPR čl. 25 a 32 | Osobní údaje mimo Git, minimalizace v logechŘízení přístupu, odůvodněná retence |
ENTERPRISE ARCHITECTURE MAPPING
TOGAF 10 Phase D – Technology Architecture (Technology Building Blocks)COBIT 2019 BAI10 Managed Configuration, BAI09 Managed Assets, DSS04
ITIL 4 Service Configuration Management, Change Enablement
Cílové provozní parametry
Návrhové cíle referenční architektury. Skutečná dostupnost závisí i na infrastruktuře, kterou provozujete vy — smluvně proto garantujeme reakční doby podpory, ne procento dostupnosti. Viz Služby.
| PARAMETR | CÍL | PŘEDPOKLAD / ZPŮSOB |
|---|---|---|
| Dostupnost | ≥ 99,5 % | Doporučené nasazení (3 uzly, pevné IP adresy, zálohy mimo cluster); měřeno na HTTP healthcheck |
| Výpadek uzlu | Bez zásahu obsluhy | Kvórum etcd, přeplánování podů; u jednoinstančních služeb výpadek v řádu minut, Gitea (zdroj pro Flux) do návratu uzlu |
| RPO | ≤ 1 hodina pro PostgreSQL; ≤ 24 h svazky Longhorn a OpenBao; ≤ 6 h etcd | Průběžná archivace WAL PostgreSQL; denní zálohy svazků a snapshoty etcd každých 6 h mimo cluster |
| RTO | ≤ 2 hodiny | Nový cluster, Flux bootstrap z Gitu a obnova dat ze záloh |
| Okno údržby | Neděle 02:00–06:00 | Doporučené, čas Europe/Prague; rolling update |
Replikace není záloha
Replikace a snapshoty uvnitř clusteru smazání nebo poškození dat okamžitě zkopírují. Referenční strategie proto ukládá zálohy mimo cluster a obnovu pravidelně testuje.
| CO SE ZÁLOHUJE | JAK | KAM |
|---|---|---|
| Stav clusteru (etcd) | Plánované snapshoty K3s (každých 6 h) | Lokálně na uzlech + S3 mimo cluster |
| PostgreSQL | Průběžná archivace WAL + denní plná záloha | S3, obnova k libovolnému okamžiku |
| Svazky Longhorn | Denní zálohy | S3 |
| Tajemství (OpenBao) | Denní zálohy svazků Raft; ruční snapshot před upgradem | Svazky do S3 mimo cluster; ruční snapshot na řídicí stroj |
| Klíče Sealed Secrets, step-ca a OpenBao | Klíč Sealed Secrets a klíč pro odpečetění OpenBao vznikají mimo cluster (Keychain řídicího stroje), klíče step-ca exportuje backup-pki-keys.sh | Kopie do trezoru mimo cluster je ruční krok |
| Playbooky a manifesty | Git | Gitea + zrcadlo; obnova přes Flux bootstrap |
Bez offline zálohy klíče Sealed Secrets nejdou šifrované secrets v Gitu po ztrátě clusteru rozšifrovat a bez klíče pro odpečetění OpenBao nejdou obnovit jeho data. Proti ransomwaru a omylem smazaným zálohám dělá hostitel úložiště záloh denní snapshoty (14 dní), na které se z clusteru nedostanete. Test obnovy doporučujeme provádět pravidelně, například čtvrtletně — postup je v dokumentaci.
Software zdarma. Služby, když je potřebujete.
Software platformy je pod licencí Apache 2.0 a bez licenčních poplatků. Placené jsou pouze služby: nasazení, podpora a nové integrace.
Onboarding
Jednorázové nasazení a zavedení do provozu. Základní nasazení od 145 000 Kč bez DPH: cluster, GitOps, observability, PKI, zálohy, předání a zaškolení; integrace se oceňují zvlášť. Typicky v řádu týdnů.
Podpora
Měsíční podpora ve dvou úrovních — Základ a Standard. Nepřetržitou dostupnost (reakční doby Standardu platí i mimo pracovní dobu) nebo pohotovost s reakcí na havárii do 1 h lze přiobjednat jen ke Standardu. Smluvně garantujeme reakční doby pro kategorie incidentů A (havárie), B (chyba) a C (nedostatek), bezpečnostní aktualizace jsou v obou úrovních. Práce nad rámec paušálu účtujeme podle skutečně odvedené práce.
Integrace
Katalogové integrace za předem známou pevnou cenu: LDAP/AD, SSO (OIDC/SAML), firemní CI/CD, export logů do SIEM, offsite S3 a firemní monitoring. Napojení dalších technologií — síťových prvků, firewallů, virtualizace nebo PAM — je integrace na zakázku: placená úvodní analýza (1 den, započte se do ceny), pak cena podle rozsahu.
Open-source stack. Nulové licenční náklady.
Svoboda výběru
Infrastrukturu provozujete vy. Bez závislosti na dodavateli.
Bez licenčních poplatků
Platíte jen za provoz a za služby, které si objednáte. Žádné licence na uzel, žádné předplatné softwaru.
Čistá exit strategie
Data z PostgreSQL do CSV/JSON, kód a manifesty v Gitu, předávací protokol. Exit strategie v souladu s DORA čl. 28 odst. 8.
| KOMPONENTA | LICENCE | SPRÁVCE |
|---|---|---|
| K3s | Apache 2.0 | SUSE/Rancher, CNCF Sandbox |
| PostgreSQL | PostgreSQL License | PostgreSQL Global Dev. Group |
| PostgREST | MIT | PostgREST |
| CloudNativePG | Apache 2.0 | CNCF Sandbox |
| PgBouncer (pooler CNPG) | ISC | PgBouncer |
| Semaphore UI (Community) | MIT | Semaphore UI; globální runnery má i edice Community; projektové runnery (Pro), aktivní-aktivní HA (Enterprise) |
| Gitea | MIT | Gitea Ltd + komunita |
| Flux CD | Apache 2.0 | CNCF Graduated |
| step-ca | Apache 2.0 | Smallstep |
| cert-manager | Apache 2.0 | CNCF Graduated |
| trust-manager | Apache 2.0 | Projekt cert-manager |
| step-issuer | Apache 2.0 | Smallstep |
| Longhorn | Apache 2.0 | CNCF Incubating |
| Traefik Proxy | MIT | Traefik Labs |
| MetalLB | Apache 2.0 | CNCF Sandbox |
| kube-vip | Apache 2.0 | Komunita kube-vip |
| WireGuard | GPL 2.0 | Součást jádra Linuxu |
| Prometheus + Alertmanager | Apache 2.0 | CNCF Graduated |
| Grafana | AGPL 3.0 | Grafana Labs |
| Loki | AGPL 3.0 | Grafana Labs |
| Grafana Alloy | Apache 2.0 | Grafana Labs |
| Apache ECharts | Apache 2.0 | Apache Software Foundation |
| Sealed Secrets | Apache 2.0 | Bitnami Labs |
| OpenBao | MPL 2.0 | Linux Foundation (OpenSSF) |
| Trivy Operator | Apache 2.0 | Aqua Security |
| ntfy | Apache 2.0 / GPL 2.0 (duální) | Philipp C. Heckel + komunita |
| Gitea Actions runner (act_runner) | MIT | Gitea Ltd + komunita |
| Docker Engine (DinD pro CI runner) | Apache 2.0 | Moby / Docker |
| Garage (S3 cíl záloh, mimo cluster) | AGPL 3.0 | Deuxfleurs |
| Ansible Core | GPL 3.0 | Red Hat |
Software platformy je pod licencí Apache 2.0; přístup k repozitáři poskytujeme na vyžádání. Platforma používá komunitní edice komponent. Některé komponenty mají i placené edice od výrobců — například Semaphore UI (globální runnery má i edice Community; projektové runnery (Pro), aktivní-aktivní HA (Enterprise)) nebo Grafana Enterprise. Pampeliška je nevyžaduje.
Pampeliška vs. alternativy
Srovnání s nástroji, které organizace pro automatizaci infrastruktury nejčastěji zvažují.
| FUNKCE | Pampeliška 3.0 | Red Hat AAP | AWX | Rundeck Ent. | Salt |
|---|---|---|---|---|---|
| Licenční náklady | 0 Kč | od cca 12,6 tis. € / 100 uzlů / rok (ceník resellera, bez DPH) | 0 Kč | Komerční | 0 Kč (OSS), komerční edice zvlášť |
| Open-source stack | ✓ Apache/MIT/GPL/AGPL | Komerční subskripce | ✓ Apache 2.0 | Open-core | ✓ Apache 2.0 |
| GitOps (deklarativní stav) | ✓ Flux CD (Kubernetes vrstva) | Synchronizace projektů z Gitu | Synchronizace projektů z Gitu | Imperativní | GitFS (stavy z Gitu) |
| Kubernetes-nativní | ✓ K3s HA | ✓ Operator (OpenShift/K8s) | ✓ AWX Operator | VM-based | Agent / master |
| Integrovaný PKI/CLM | ✓ step-ca + cert-manager | Externí | Externí | Externí | Externí |
| Grafový model závislostí | ✓ PostgreSQL (nodes/edges) | — | — | — | — |
| Komerční podpora | ✓ Základ / Standard, volitelně 24/7 | ✓ Red Hat | Bez podpory výrobce | ✓ PagerDuty | Komerční edice |
| Vývoj | Aktivní | Aktivní | Poslední vydání 24.6.1 (červenec 2024) | Aktivní | Aktivní |
| Vendor lock-in | Žádný | Red Hat | Nízký | PagerDuty | Nízký (open source); komerční edice Broadcom |
| On-premise / air-gapped | ✓ S interními zrcadly | ✓ | ✓ | ✓ | ✓ |
Stav k říjnu 2026 podle veřejných ceníků a dokumentace výrobců. Cena Red Hat AAP je orientační údaj z ceníku resellera (balík 100 spravovaných uzlů na rok, edice Standard, bez DPH); Red Hat ceník nezveřejňuje a nezávislé odhady bývají vyšší. Poslední vydání AWX je 24.6.1 z července 2024 (GitHub releases ansible/awx). Komerční varianty nabízejí rozsáhlejší podporu výrobce a certifikace; Pampeliška staví na otevřených standardech a ekosystému CNCF.
Kam Pampeliška směřuje
Plánované funkce. Pořadí upravujeme podle potřeb zákazníků, termíny nejsou závazné.
GitOps i pro zařízení
Změny síťových prvků a firewallů jako pull request: náhled změn přímo v PR, schválení druhou osobou, nasazení po merge a průběžná detekce driftu.
Dopad změny v pull requestu
Grafový model ukáže, které služby změna ovlivní, ještě před schválením. Podklad pro Change Enablement i evidenci řízení změn podle NIS2 a DORA.
Auditní balíček na klik
Export historie změn, logů úloh, inventáře certifikátů a nálezů skenování zranitelností, uspořádaný podle kontrol ISO 27001, NIS2 a DORA.
Rozšířená správa certifikátů
SCEP pro síťová zařízení, vyhledávání certifikátů v síti, napojení veřejných CA přes ACME a inventura kryptografie jako podklad pro přechod na postkvantové algoritmy.
Podepsané releasy a offline balíček
Podpis každého releasu, SBOM ke každé verzi a offline balíček pro izolovaná prostředí včetně zrcadla databáze zranitelností.
AI asistent nad grafem
Dotazy typu „co přestane fungovat, když…“ nad grafem závislostí. Změny navrhuje výhradně jako pull request ke schválení a běží na lokálním LLM.
Dynamické přístupové údaje
Krátkodobé přihlašovací údaje, které OpenBao vygeneruje na vyžádání (např. k databázím) a po použití sám zneplatní. K tomu TLS uvnitř clusteru i pro OpenBao, automatické snapshoty Raft do S3 a synchronizace tajemství do Kubernetes (External Secrets Operator).
CI runner mimo cluster
Izolace privilegovaného Docker-in-Docker: CI runner (Gitea Actions) dnes běží v clusteru jako privilegovaný pod, nově poběží v samostatné VM mimo cluster.
Často kladené otázky
Odpovědi na nejčastější dotazy enterprise architektů a IT managerů.
Kdo Pampelišku nasadí a kdo ji bude provozovat?
Jak funguje migrace z Ansible Tower / AWX?
Proč nepoužít rovnou Semaphore UI nebo AWX?
Můžeme jako zdroj inventáře použít NetBox nebo Nautobot?
netbox.netbox.nb_inventory; pro Nautobot obdobně. NetBox tak zůstane
zdrojem pravdy o síti a Pampeliška ho doplní o automatizaci, správu certifikátů a observability.
Co když potřebujeme komerční SLA a 24/7 podporu?
Jaký je vztah k regulacím NIS2 a DORA?
auditní záznamy (Loki, retence
≥ 18 měsíců s objektovým úložištěm — požadavek vyhlášky č. 409/2025 Sb., § 22 odst. 5
písm. c) pro subjekty režimu vyšších povinností, auditní log Kubernetes API, napojení na SIEM jako katalogová integrace),
správa aktiv a konfigurací (Git, auditní log grafového modelu v PostgreSQL), šifrování
(TLS 1.2+, certifikáty z vlastní CA), zálohy a kontinuita (cílové RPO ≤ 1 h pro PostgreSQL,
≤ 24 h pro svazky, RTO ≤ 2 h). Detail mapování viz sekce Compliance.
Procesní stránka (řízení ICT rizik, hlášení incidentů) zůstává odpovědností organizace.
Kde jsou uložená hesla ke spravovaným zařízením?
Funguje to v air-gapped prostředí (vládní/obranný sektor)?
Jaké HW prostředky reálně potřebujeme?
Co se stane, když chceme po roce odejít?
git clone. Žádný proprietární
formát. Předávací protokol a přechodné období lze sjednat ve smlouvě o podpoře, v souladu
s požadavky DORA na exit strategii (čl. 28 odst. 8).
Jak se Pampeliška liší od běžné Kubernetes platformy?
Jak nahlásit bezpečnostní zranitelnost?
Instalace za den. Do provozu za týdny.
Platforma běží na 3 VM a instaluje se jedním skriptem po přípravě inventáře — čistá instalace na referenčním prostředí Canonical MicroCloud trvá zhruba hodinu. Zavedení do provozu — napojení vašich technologií, správu certifikátů, zálohy a předání týmu — trvá týdny a uděláme ho s vámi v rámci onboardingu.
$ cd pampeliska && ./scripts/prepare-secrets.sh
✓ Tajemství připravena (Ansible Vault, Sealed Secrets, OpenBao)
$ git add kubernetes/infra-config/sealed-secrets
$ git commit -S -m "chore: přepečetěná tajemství"
$ ./deploy.sh --skip-secrets
✓ VM na LXD/MicroCloud, S3 cíl záloh (Garage)
✓ K3s HA cluster (3 uzly, embedded etcd, VIP)
✓ Gitea + Flux CD napojeny (ověřuje podpis HEAD)
✓ Longhorn, PostgreSQL (CloudNativePG), PostgREST
✓ Semaphore UI, OpenBao, step-ca, cert-manager
✓ Prometheus, Grafana, Loki, Alloy, ntfy
Pampeliška 3.0 is ready. Happy automating.