- Přehledy IS
- APS (25)
- BPM - procesní řízení (23)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (31)
- CRM (52)
- DMS/ECM - správa dokumentů (19)
- EAM (17)
- Ekonomické systémy (68)
- ERP (75)
- HRM (28)
- ITSM (6)
- MES (33)
- Řízení výroby (36)
- WMS (28)
- Dodavatelé IT služeb a řešení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (41)
- Dodavatelé CRM (38)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (66)
- Informační bezpečnost (43)
- IT řešení pro logistiku (48)
- IT řešení pro stavebnictví (26)
- Řešení pro veřejný a státní sektor (27)


















![]() | Přihlaste se k odběru zpravodaje SystemNEWS na LinkedIn, který každý týden přináší výběr článků z oblasti podnikové informatiky | |
![]() | ||
Bezpečnost Kubernetes
2. díl
Kontejnerizovaná infrastruktura je stále častěji využívaná pro provoz aplikací včetně těch kritických z pohledu businessu společnosti. Proto je důležité znát a minimalizovat rizika spojená s těmito systémy. V minulém díle jsme se podívali na hrozby, které jsou typické pro svět Kubernetes a kontejnerizovaných aplikací. Zaměřili jsme se na čtyři nejtypičtější – container escape, configuration drift, škodlivý kód v image a únik secrets. V tomto druhém díle se podíváme na způsoby, jak tyto hrozby úspěšně mitigovat a minimalizovat rizika spojená s kompromitací kontejnerizovaných aplikací nebo únikem dat.


Tři úrovně bezpečnosti
V celém systému deploymentu image a jeho zprovoznění můžeme najít tři různé oblasti, ve kterých je nutné bezpečnost řešit. Během vývoje image je nutné kontrolovat image z pohledu používaných knihoven, analyzovat a vyřešit případné zranitelnosti, respektive monitorovat, že se v něm nenachází žádná citlivá data (z pohledu případného úniku secrets). Tuto část bezpečnosti kontejnerizovaných systémů nazýváme běžně Image Security nebo se můžeme setkat také s pojmem Image Assessment.
Druhou oblastí, kde je nutné také bezpečnost zajistit, je samotná infrastruktura, na které kontejnerizační technologie běží. Kubernetes mohou běžet formou as a service, kdy za bezpečnost infrastruktury zodpovídá provozovatel SaaS prostředí. Pokud ale provozujeme Kubernetes ve vlastní (on-premise nebo cloudové) infrastruktuře, je nutné zajistit její bezpečnou konfiguraci, patch management a související identifikaci zranitelností, ochranu proti škodlivému kódu a další oblasti, které standardně zajišťujeme i pro běžnou IT infrastrukturu. Zde se bavíme o tzv. oblasti Node Security, tedy zajištění bezpečnosti jednotlivých Kubernetes (worker i master) nodů.
Třetí oblast obyčejně nazýváme Runtime Security nebo také Workload Security. Obě označení se používají pro oblast již běžících kontejnerů a podů, jejich bezpečné konfigurace, ochraně proti jejich kompromitaci a real-time monitoringu. Tak jako v běžné IT infrastruktuře zajištujeme tuto část EDR technologií, musíme podobně zajistit monitoring a real-time ochranu běžících podů.
Obr 1: Tři oblasti bezpečnosti kontejnerizačních platforem
Node Security
Bezpečnost samotné infrastruktury Kubernetes se ve většině případů bude podobat bezpečnosti běžných aplikačních nebo jiných serverů. V závislosti na využívané platformě se však bude lišit, co vše musíme zabezpečit. Při použití tzv. Vanilla Kubernetes platformy (tedy čisté verze Kubernetes, která je udržována komunitou, bez žádné enterprise nástavby) je nutné zajistit bezpečnost operačního systému nodů (případně samozřejmě fyzickou nebo virtualizační úroveň), všech instalovaných aplikací a stejně tak zabezpečit samotné Kubernetes. Naopak při provozování některé z variant tzv. distribucí Kubernetes (například Red Hat OpenShift, VMware Tanzu, AWS EKS a další) řeší část bezpečnosti výrobce nebo provozovatel platformy za nás.
Provozování jakékoliv varianty Kubernetes na vaší infrastruktuře (on-premise nebo cloud) předpokládá, že se staráme o bezpečnost infrastruktury i operačního systému. Některé platformy mají operační systém již nakonfigurovaný dle bezpečnostních standardů bez nutnosti dalších úprav a stejně tak není možné ovlivnit instalované aplikace a doinstalovávat vlastní balíčky nebo knihovny do OS.
V případě variant tzv. Managed Kubernetes je platforma provozována jako SaaS, tedy za instalaci, provoz a maintenance Kubernetes se stará provozovatel cloudu. Tyto služby poskytují všichni standardní poskytovatelé cloudových služeb – Azure, AWS, GCP, Oracle Cloud, Alibaba a další. V tomto případě nemusíme (a často ani nemáme možnost) výrazně ovlivnit bezpečnost jednotlivých nodů.
To, co je nutné zajistit v případě provozu Vanilla Kubernetes, je především:
- zajištění bezpečnosti virtualizace, případně fyzických serverů,
- bezpečná konfigurace operačního systému a Kubernetes (například podle CIS benchmarku),
- identifikace zranitelností a patchování OS, Kubernetes a všech instalovaných aplikací,
- logování aktivit v OS i v Kubernetes a napojení na log management nebo SIEM,
- zajištění bezpečného přístupu a správa privilegovaných účtů jak v OS, tak v Kubernetes,
- síťová segmentace a správa firewallových prostupů,
- ochrana proti malwaru a monitoring aktivit (například pomocí EDR).
Dle provozované varianty se některé z těchto aktivit mohou automaticky přenést na poskytovatele. Například v případě provozování Kubernetes jako služby v AWS (Amazon Elastic Kubernetes Service) se o všechny tyto oblasti stará poskytovatel a na nás je pouze napojení na stávající infrastrukturu a konfigurace některých nastavení (například detailní logování).
Image Security
Bezpečnost aplikací provozovaných v Kubernetes závisí mimo jiné na bezpečnosti původního image, ze kterého jsou následně pody deployovány. Ten by měl být před jeho používáním podroben detailní analýze. Její součástí jsou typicky následující aktivity:
- analýza instalovaných aplikací a balíčků,
- tzv. software composition analysis (SCA – analýza softwarových komponent), která analyzuje používané 3rd party knihovny z licenčního i bezpečnostního pohledu,
- identifikace zranitelností v používaných aplikacích, balíčcích a knihovnách,
- identifikace senzitivních dat (například přístupové údaje nebo API klíče hardkódované v image),
- analýza image na přítomnost malware.
Tyto aktivity je vhodné provádět co nejdříve v souladu s principem tzv. shift-left přístupu. Jedná se o přístup, kdy se procesy související s testováním, ověřováním a bezpečností posouvají vlevo na pomyslné časové ose vývoje softwaru, tedy směrem k vývoji a vývojářům. Čím dříve dostane vývojář informace o případných problémech v image, tím dříve je může opravit a tím menší komplikace při vývoji to může představovat.
Ideální tedy je provádět analýzu image ještě během vývoje a testování zařadit do vývojových pipeline tak, aby při změnách kódu měl vývojář ihned k dispozici informace o případných problémech. Většinu nástrojů pro image assessment je možné integrovat do CI/CD pipeline.
Nástroje také umožňují nastavit politiky, které říkají, v jakém případě neprojde image kontrolou. Takový image je následně označen jako non-compliant a nelze z něj v prostředí Kubernetes vytvářet běžící pody (pokud takovou funkcí nástroj disponuje).
Důležité je také testování takových image, které nepocházejí z našeho vlastního vývoje, ale jsou z veřejných zdrojů nebo od externích dodavatelů. Pro tento účel lze vytvořit „lab“ prostředí, ve kterém budou image analyzovány, případně některé nástroje poskytují sandbox pro spuštění image a kontrolu jeho aktivit.
Workload Security
Poslední oblastí, kterou nesmíme opomenout při komplexním zabezpečování kontejnerizačních platforem, je workload security, případně jinak označovaná jako runtime security. Nejedná se o nic jiného než o standardní monitoring aktivit v reálném čase, logování vybraných událostí, ochranu proti malwaru s behaviorální analýzou – zkrátka vše, co v dnešní době poskytuje na běžné IT infrastruktuře například EDR v kombinaci s logováním do SIEM nebo jiného nástroje.
Podobně jako může dojít ke spuštění malwaru na běžných aplikačních serverech nebo k jejich kompromitaci, může se to stát i v prostředí Kubernetes. O možných rizicích spuštění útočníkova kódu v běžícím podu a následné eskalaci útoku do jiných podů, do worker nodu samotného či dále do sítě jsme se bavili v předchozím díle. Je důležité mít možnost takové aktivity identifikovat a dle nastavených politik také blokovat.
Některé nástroje pro runtime ochranu Kubernetes workloadů umožňují definovat vlastní politiky a následně blokovat podezřelé nebo škodlivé aktivity, whitelistovat nebo blacklistovat konkrétní image, případně úplně zakázat spouštění podů z imagů, které úspěšně neprošly image assessment analýzou.
Kubernetes, rizika, zabezpečení
Kontejnerizace aplikací zásadně mění způsob, jakým organizace nasazují a provozují software. Umožňuje rychlé spuštění aplikací, flexibilní škálování a efektivní využití zdrojů. Přestože přináší mnoho výhod, často se zapomíná na rizika spojená s jejich zabezpečením. Mezi nejzávažnější hrozby patří container escape, kdy útočník dokáže uniknout z izolovaného prostředí kontejneru na hostitelský systém, configuration drift, kdy změny v běžících kontejnerech narušují princip jejich neměnnosti, nebo šíření škodlivého kódu přes nezabezpečené image ve veřejných registrech, jako je Docker Hub. Neméně významným problémem je únik citlivých dat (secrets), například přístupových klíčů nebo hesel, při nesprávné správě image. Tyto zranitelnosti mohou útočníkovi umožnit nejen kompromitovat aplikace, ale i provádět laterální pohyb napříč celou infrastrukturou.
Pro minimalizaci těchto rizik je klíčové zaměřit se na tři oblasti bezpečnosti. Image Security zahrnuje analýzu používaných image na zranitelnosti, malware a přítomnost citlivých dat již během vývoje (shift-left přístup). Node Security se zaměřuje na ochranu infrastruktury, včetně správné konfigurace, patch managementu a logování. Runtime Security pak zajišťuje monitoring a ochranu běžících podů, například pomocí nástrojů podobných EDR. Efektivní bezpečnostní strategie by měla kombinovat tyto přístupy, využívat automatizované nástroje pro analýzu a dodržovat ověřené bezpečnostní standardy, jako jsou CIS benchmarky. Organizace tím zajistí robustní obranu vůči specifickým hrozbám kontejnerizovaného světa.
![]() |
David Pecl Autor článku je Security Consultant ve společnosti Security Avengers |


![]() ![]() | ||||||
Po | Út | St | Čt | Pá | So | Ne |
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 1 | 2 | 3 | 4 |
5 | 6 | 7 | 8 | 9 | 10 | 11 |
Formulář pro přidání akce
10.4. | Konference ALVAO Inspiration Day 2025 |
10.4. | APSolutní jízda: zrychlete výrobu, snižte náklady! |