Модуль 0.1: Огляд іспиту CKS

Складність: [ШВИДКИЙ] — Базова орієнтація

Час на проходження: 20–25 хвилин

Передумови: сертифікація CKA (потрібно скласти CKA будь-коли до спроби CKS)

Що ви зможете зробити

Після завершення цього модуля ви зможете:

Порівняти обсяг іспитів CKA і CKS, ваги доменів та операційні очікування.
Оцінити готовність до CKS, зіставивши офіційні передумови, формат іспиту, дозволені ресурси та ваги доменів зі своїми поточними навичками.
Спроєктувати план підготовки до CKS, який віддає пріоритет доменам безпеки з високою вагою, не нехтуючи при цьому посиленням Linux.
Діагностувати прогалини у стані безпеки практичного кластера Kubernetes 1.35+ за допомогою команд інспекції у стилі CKS.
Впровадити повторюваний підхід до іспиту для сортування швидких перемог, завдань із інтенсивним використанням інструментів та складних сценаріїв безпеки.

Чому цей модуль важливий

Сценарій вправи: ви щойно склали CKA, і ваші звички з адміністрування кластера достатньо міцні, щоб полагодити зламаний деплоймент, замінити сертифікат і відновити несправну площину управління. Тепер продуктова команда запитує, чи витримав би той самий кластер скомпрометований образ контейнера, робоче навантаження, що працює з надмірним доступом до хоста, або простір імен без жодної мережевої межі. Іспит CKS існує саме в тому розриві між «платформа працює» та «платформа протистоїть зловживанням».

Certified Kubernetes Security Specialist — це не другий прохід через CKA з іншими підписами. Він припускає, що ви вже знаєте, як поєднуються кластери kubeadm, Pod’и, Service’и, RBAC і усунення несправностей, а потім питає, чи можете ви зменшити поверхню атаки на етапах збирання, розгортання та виконання. Ця різниця важлива, бо робоче навантаження може бути цілком доступним, але водночас працювати від root, приймати трафік із кожного простору імен, монтувати секрети надто широко або постачатися з образу, який ніколи не мав потрапити в кластер.

Цей модуль дає вам мапу, перш ніж ви почнете сходження. Ви порівняєте очікування CKA і CKS, прочитаєте формат іспиту як інженерне обмеження, перекладете ваги доменів у пріоритети підготовки та потренуєтеся з першою інспекцією стану безпеки. Сприймайте модуль як калібрування: якщо тема здається знайомою з CKA, запитайте себе, що зробив би зловмисник із тим самим механізмом.

Приклади в цьому напрямку написані для поведінки Kubernetes 1.35+, де семантика API Kubernetes стабільна, але кандидати на іспит завжди мають перевіряти сторінки CKS Linux Foundation перед записом, бо опублікована версія середовища іспиту може змінюватися незалежно від цього навчального плану. Безпечніша звичка — розділяти дві ідеї: глибоко вивчати сучасну практику безпеки Kubernetes і перевіряти точну версію іспиту та дозволені ресурси якнайближче до дати вашого запису.

CKS проти CKA: від операцій до суджень про безпеку

CKA вчить вас тримати Kubernetes придатним до використання під тиском. Ви вчитеся створювати ресурси, лагодити компоненти кластера, налаштовувати мережу та налагоджувати робочі навантаження, які не стартують. CKS зберігає ці навички в роботі, але змінює запитання, яке ви ставите після кожної успішної команди. Нове запитання — не просто чи об’єкт існує і чи Под досягає Running; воно про те, чи звужує об’єкт привілеї, чи обмежує радіус ураження і чи створює достатньо доказів для подальшого розслідування.

┌─────────────────────────────────────────────────────────────┐
│              CKA → CKS PROGRESSION                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  CKA (Kubernetes Administrator)                            │
│  ├── Build and maintain clusters                           │
│  ├── Deploy and manage workloads                           │
│  ├── Troubleshoot failures                                 │
│  └── "Make it work"                                        │
│                                                             │
│            ↓ Foundation for ↓                              │
│                                                             │
│  CKS (Kubernetes Security Specialist)                      │
│  ├── Harden clusters against attack                        │
│  ├── Secure supply chain                                   │
│  ├── Detect and respond to threats                         │
│  └── "Make it secure"                                      │
│                                                             │
│  Key difference:                                           │
│  CKA asks "Does it run?"                                   │
│  CKS asks "Can it be compromised?"                         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Саме ця прогресія робить передумову CKA змістовною, а не церемоніальною. Робота з безпекою — це здебільшого звуження вибору в системах, які ви вже розумієте. Якщо ви не можете сказати, чи токен ServiceAccount використовується Под’ом, чи селектор NetworkPolicy насправді збігається з трафіком, чи налаштування kubelet надійшло з конфігураційного файлу або з systemd drop-in, то рівень безпеки перетворюється на здогадки замість аналізу.

Найважча зміна мислення — у тому, що CKS часто розглядає успішний вивід як неповний доказ. Зелений деплоймент каже вам, що планувальник прийняв Под і kubelet запустив контейнери; він не каже вам, чи образ був просканований, чи може Под вирватися в простори імен хоста, чи має робоче навантаження зайві можливості (capabilities) і чи буде підозріла поведінка залогована. Ви не можете захистити те, чого не розумієте, але щойно ви це зрозуміли, ви маєте навчитися не довіряти «воно працює» як остаточній відповіді.

CKS також вводить інструменти та концепції операційної системи, які адміністратори Kubernetes часто відкладають. AppArmor і seccomp визначають, що процес може робити після свого запуску. Інструменти виявлення під час виконання (runtime) досліджують поведінку, яку сам Kubernetes не описує в маніфесті. Перевірки ланцюга постачання питають, чи варто довіряти образу, SBOM, підпису або результату статичного аналізу, перш ніж робоче навантаження взагалі дійде до сервера API.

Зупиніться і спрогнозуйте: коли Под виходить з ладу лише після того, як ви ввімкнули суворіші засоби контролю безпеки, які докази відрізнили б помилку застосунку від проблеми з допуском (admission), політикою, профілем або примусовим виконанням під час виконання? Сильна відповідь у стилі CKA починається з подій і логів, тоді як сильна відповідь у стилі CKS також питає, який рівень безпеки міг відхилити робоче навантаження до або після запуску контейнера.

Ця різниця змінює те, як ви готуєтеся. Вам усе ще потрібна швидкість із kubectl, YAML та усуненням несправностей, але ваш ментальний контрольний список розширюється зі стану ресурсу до шляху атаки. Для кожного об’єкта кластера питайте, який привілей він надає, який мережевий шлях відкриває, якої поверхні хоста торкається, який обліковий запис розкриває та який сигнал залишає по собі в разі зловживання.

Корисне порівняння — не «CKA легкий, а CKS складний». Корисне порівняння в тому, що CKA здебільшого перевіряє операційний контроль, тоді як CKS перевіряє оборонне судження під тим самим тиском часу. Кандидат, який уміє будувати кластери, але не вміє міркувати про найменші привілеї, обмеження ядра, довіру до ланцюга постачання чи докази під час виконання, відчує, що іспит затягує його на незнайому територію.

Формат іспиту, правила та дозволені ресурси

Іспит CKS базується на практичних завданнях, проводиться онлайн і розв’язується в командному рядку. Цей формат винагороджує практичну вправність більше, ніж заучування, бо завдання вимагають від вас змінювати реальні файли, перевіряти реальний стан кластера та вирішувати, які докази мають значення. Очікуйте такого самого фізичного тиску, як на CKA: віддалений робочий стіл, браузер усередині середовища іспиту, термінал, таймер і мало простору для дослідницьких блукань.

Аспект	Деталі
Тривалість	2 години (120 хвилин)
Формат	На основі практичних завдань (завдання в CLI)
Питання	~17 завдань (за поточним симулятором LF/Killer.sh; перевірте Important Instructions від LF перед записом)
Прохідний бал	67%
Передумова	Сертифікація CKA (складена до спроби CKS)
Середовище	Командний рядок Linux, кластери Kubernetes, поточна опублікована LF версія
Чинність	2 роки

Ця таблиця — більше, ніж дрібниці, бо кожен рядок передбачає певну поведінку. Двогодинне вікно приблизно на сімнадцять практичних завдань означає, що ви маєте розподіляти час, фіксувати пропущену роботу та уникати того, щоб одна важка задача стала причиною втрати кількох легших. Кількість завдань може змінюватися, коли Linux Foundation оновлює симулятор, тож сприймайте сторінку Important Instructions як джерело істини якнайближче до дати вашого іспиту. Прохідний бал 67% означає, що частковий прогрес має значення; якщо ви можете виправити RBAC-частину питання, але не частину з політикою аудиту, вам усе одно варто зробити те виправлення, яке ви можете довести.

Рядок про передумову також має формувати ваш тест готовності. Linux Foundation зазначає, що кандидати на CKS мають скласти CKA перед спробою CKS, і сертифікація CKS призначена для досвідчених практиків Kubernetes. Це формулювання не означає, що ви маєте бути повноцінним інженером з безпеки, але воно означає, що іспит припускає швидкість команд рівня CKA, оцінюючи завдання, специфічні для безпеки.

Дозволені ресурси — поширене джерело змарнованого часу на іспиті. Перелік дозволених ресурсів CKS не ідентичний переліку CKA, і він змінюється разом зі зміною інструментарію іспиту. Станом на поточну сторінку ресурсів Linux Foundation, кандидати на CKS можуть користуватися браузером усередині ВМ для документації Kubernetes, блогу Kubernetes, документації Falco, документації Bom CLI, документації etcd, документації з конфігурації ingress-nginx, документації Cilium, документації Istio та посилань Quick Reference для конкретних завдань, наданих іспитом.

Під час іспиту ви можете отримати доступ до:

Документації Kubernetes: https://kubernetes.io/docs/
Блогу Kubernetes: https://kubernetes.io/blog/
Документації Falco: https://falco.org/docs/
Довідника Bom CLI: https://kubernetes-sigs.github.io/bom/cli-reference/
Документації etcd: https://etcd.io/docs/
Документації NGINX Ingress Controller: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/
Документації Cilium: https://docs.cilium.io/en/stable/
Документації Istio: https://istio.io/latest/docs/
Посилань Quick Reference для конкретних завдань, наданих середовищем іспиту

Операційний урок простий: тренуйтеся з дозволеними документами, а не лише з пошуковими системами та особистими нотатками. Якщо ви вивчаєте синтаксис правил Falco, шукаючи у відкритому вебі, то можете бути швидкими на своїй звичній робочій станції і повільними в браузері іспиту. Якщо ви під час тренування додаєте в закладки відповідні навігаційні шляхи всередині дозволеної документації, то іспит відчувається менше як перевірка пам’яті і більше як пошук документації під тиском.

У політиці дозволених ресурсів також є урок безпеки. Іспит перевіряє самостійну роботу всередині контрольованого середовища, тож сторонні пристрої, несанкціоновані нотатки та зовнішні дослідження не є частиною робочого процесу. Вам варто будувати свою підготовку навколо відтворюваних команд та офіційних шляхів документації замість приватних шпаргалок, які не можуть піти з вами.

Перш ніж запускати свою першу практичну лабораторну роботу, вирішіть, які факти ви запам’ятаєте, а які шукатимете. Запам’ятайте короткі форми команд, поширені назви полів і те, де в документації розташовані основні теми. Шукайте довгі приклади політик, специфічний для інструмента синтаксис та прапорці для крайніх випадків, бо скопіювати правильний приклад постачальника й обережно його адаптувати зазвичай безпечніше, ніж відтворювати його з пам’яті.

Складіть мапу документації під час підготовки, але тримайте її радше концептуальною, ніж приватною шпаргалкою. Для кожного дозволеного сайту запишіть тему, яку ви очікуєте там знайти, і потренуйтеся діставатися до цієї теми з власної навігації сайту. Наприклад, документація Kubernetes — це природний дім для Pod Security Standards, NetworkPolicies, RBAC, концепцій політики аудиту та полів безпеки робочих навантажень, тоді як документація Falco — природний дім для умов правил, макросів, списків і полів подій. Це тренування будує саме той навігаційний м’яз, який дозволяє іспит.

Мапа також захищає вас від застарілих навчальних матеріалів. Якщо допис у блозі каже, що один інструмент або поділ доменів є актуальним, але сторінка іспиту Linux Foundation і сторінка дозволених ресурсів кажуть інше, довіряйте офіційним сторінкам у плануванні іспиту. Якщо лабораторна робота використовує інструмент, якого немає в загальному переліку дозволених, сприймайте це як практику базового робочого процесу безпеки, якщо саме завдання іспиту не надає посилання Quick Reference. Така дисципліна тримає ваш план підготовки прив’язаним до першоджерел, а не до чуток.

Ваги доменів та економіка підготовки

Публічні домени CKS — це мапа балів для вашого плану підготовки. Вони кажуть вам, де іспит зосереджує увагу і де вашим наявним звичкам із CKA потрібна специфічна для безпеки глибина. Поточний перелік доменів Linux Foundation надає трьом великим доменам з акцентом на безпеку по 20% кожному, тоді як Cluster Setup, Cluster Hardening та System Hardening ділять решту балів.

┌─────────────────────────────────────────────────────────────┐
│              CKS DOMAIN WEIGHTS                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Cluster Setup                    ██████░░░░░░░░░░░░ 15%   │
│  Network policies, CIS benchmarks, ingress security         │
│                                                             │
│  Cluster Hardening                ██████░░░░░░░░░░░░ 15%   │
│  RBAC, ServiceAccounts, API security, upgrades              │
│                                                             │
│  System Hardening                 ████░░░░░░░░░░░░░░ 10%   │
│  AppArmor, seccomp, host OS, kernel hardening               │
│                                                             │
│  Microservice Vulnerabilities     ████████░░░░░░░░░░ 20%   │
│  Security contexts, Pod Security, secrets, sandboxing       │
│                                                             │
│  Supply Chain Security            ████████░░░░░░░░░░ 20%   │
│  Image scanning, signing, SBOM, static analysis             │
│                                                             │
│  Monitoring & Runtime Security    ████████░░░░░░░░░░ 20%   │
│  Falco, audit logs, immutable containers, incident response │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Домени на 20% заслуговують на непропорційну практику, бо вони поєднують нові концепції з тиском іспиту. Microservice Vulnerabilities питає, чи можете ви посилити конфігурацію Под’а й робочого навантаження, керувати секретами, застосовувати Pod Security Standards і міркувати про ізоляцію. Supply Chain Security рухається раніше в життєвому циклі, де ви оцінюєте розмір образу, SBOM, політику артефактів і результати статичного аналізу, перш ніж робоче навантаження потрапить у кластер.

Monitoring, Logging, and Runtime Security завершує життєвий цикл, питаючи, що відбувається після розгортання. Це домен, де поєднуються логи аудиту, виявлення під час виконання, незмінні контейнери та розслідування інцидентів. Це також місце, де кандидати часто виявляють, що звичайний вивід статусу Kubernetes не показує достатньо; вам потрібні докази про поведінку, патерни системних викликів, активність API та робочий процес реагування.

Менші домени все одно важливі, бо вони підтримують більші. Cluster Setup включає мережеві політики, ingress TLS, огляд бенчмарку CIS, захист метаданих вузла, захист кінцевих точок та перевірку бінарних файлів платформи. Cluster Hardening включає RBAC, ServiceAccounts, доступ до API та оновлення. System Hardening включає зменшення поверхні хоста, ідентичність із найменшими привілеями, мінімізацію зовнішнього доступу та посилення ядра за допомогою AppArmor і seccomp.

Економіка балів створює пастку: кандидати надмірно тренують те, що здається знайомим. Якщо CKA зробив вас комфортними з RBAC і ремонтом кластера, ви можете витратити забагато часу на шліфування цих навичок, нехтуючи генерацією SBOM, структурою правил Falco, статичним аналізом робочих навантажень чи профілями ядра. Знайомі домени корисні, але прохід CKS зазвичай залежить від перетворення незнайомих механізмів безпеки на повторювані рутини.

Зупиніться і спрогнозуйте: якби у вас залишилося десять навчальних сесій, чи витратили б ви три з них на налаштування кластера kubeadm, бо воно здається конкретним, чи зарезервували б більше часу для завдань ланцюга постачання та виконання, які мають вищу вагу і менше перетину з CKA? Правильна відповідь залежить від ваших прогалин, але рішення має базуватися на вазі домену та новизні завдання, а не на комфорті.

Тому практичний план підготовки має починатися з діагностичної інвентаризації. Позначте кожен домен як «можу розв’язати в межах часу», «можу розв’язати з документацією» або «ще не можу розв’язати». Потім виділіть найбільше часу доменам із високою вагою в останній категорії, тримайте короткі щоденні повтори для швидкості команд і використовуйте інтервальне повторення для функцій безпеки Linux, бо AppArmor і seccomp легко впізнати в тексті й важче налагодити в живому кластері.

Ваги доменів не повинні змушувати вас ігнорувати роботу з низьким відсотком. Один домен на 10% може містити завдання, яке блокує іншу роботу, якщо ви не можете інтерпретувати поведінку безпеки на рівні хоста. Суть у тому, щоб узгодити зусилля з ризиком: переглядайте кожен домен, але вкладайте найглибшу практику туди, де перетинаються вага бала, новизна та ціна провалу.

Мапа інструментів та мислення безпеки

Інструментарій CKS охоплює різні фази життєвого циклу програмного забезпечення й кластера. Деякі інструменти перевіряють артефакти перед розгортанням, деякі перевіряють конфігурацію кластера, а деякі виявляють поведінку, поки робочі навантаження працюють. Сприймайте перелік інструментів як мапу того, звідки беруться докази, а не як список покупок для заучування.

Інструмент	Призначення	Використання на іспиті
Trivy	Сканування вразливостей образів	Практика пошуку CVE та шляхів виправлення, коли потрібне сканування образу
Falco	Виявлення загроз під час виконання	Писати, змінювати правила та міркувати про них для підозрілої поведінки робочого навантаження
kube-bench	Перевірка за бенчмарком CIS	Аудит безпеки кластера за контролями бенчмарку
kubesec	Статичний аналіз маніфестів	Оцінювати безпеку YAML та виявляти ризиковані поля робочих навантажень
AppArmor	Контроль доступу застосунків	Створювати, завантажувати та застосовувати профілі, що обмежують поведінку процесу
seccomp	Фільтрація системних викликів	Обмежувати системні виклики контейнера через профілі Под’а або середовища виконання
Bom	Генерація специфікації складу ПЗ (SBOM)	Перевіряти вміст образу та метадані ланцюга постачання, коли з’являється робота із SBOM
Cilium / Istio	Безпека мережі та сервісної мережі (service mesh)	Міркувати про шифрування, ідентичність і політику, коли завдання посилається на ці системи

Точний набір інструментів, доступних у завданні, може відрізнятися залежно від середовища іспиту та інструкцій Quick Reference, тож уникайте будувати план підготовки лише на одному бінарному файлі. Глибший патерн є переносним: визначте питання безпеки, виберіть джерело доказів, запустіть найвужчу команду, що на нього відповідає, а потім змінюйте конфігурацію лише після того, як дізнаєтеся, якого контролю бракує. Цей патерн працює, чи називає завдання Trivy, Bom, Kubesec, KubeLinter, Falco, Cilium, Istio, чи звичайний об’єкт API Kubernetes.

Аналіз образів і маніфестів живе перед виконанням. Він допомагає вам вирішити, чи варто допускати робоче навантаження до кластера, чи базовий образ непотрібно великий, чи розкриті чутливі поля та чи має артефакт достатньо метаданих, щоб йому довіряти. Ці перевірки легше автоматизувати поза іспитом, але версія для іспиту зазвичай просить вас інтерпретувати вивід і зробити конкретне виправлення.

Інструменти виконання відповідають на інший клас питань. Маніфест може казати, що контейнер має працювати з кореневою файловою системою лише для читання, але спостереження під час виконання каже вам, чи процес породив оболонку, торкнувся чутливого шляху або встановив підозріле мережеве з’єднання. Falco важливий, бо він перетворює події ядра та Kubernetes на збіги правил, які команди безпеки можуть використовувати під час розслідування.

Засоби контролю безпеки Linux — це місце, де багато адміністраторів Kubernetes відчувають найкрутіший підйом. AppArmor і seccomp працюють нижче об’єктної моделі Kubernetes, проте Kubernetes надає способи запитувати профілі для Под’ів. Якщо робоче навантаження раптом виходить з ладу, коли застосовано профіль, ви маєте міркувати про поведінку процесу, посередництво ядра, підтримку середовища виконання контейнерів і події Под’а разом.

┌─────────────────────────────────────────────────────────────┐
│              ADMINISTRATOR vs SECURITY THINKING             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Administrator sees:          Security specialist sees:     │
│  ─────────────────────────────────────────────────────────  │
│  "Pod is running"             "Pod runs as root"            │
│  "Service is accessible"      "Service has no NetworkPolicy"│
│  "App deploys successfully"   "Image has many CVEs"         │
│  "Cluster is operational"     "API server allows anonymous" │
│  "Secrets are mounted"        "Secrets are data in etcd"    │
│                                                             │
│  Key insight:                                              │
│  Working ≠ Secure                                          │
│  Everything you built in CKA, CKS teaches you to harden    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Діаграма навмисно різка, бо CKS винагороджує інший вид уваги. Под у стані Running може все одно порушувати принцип найменших привілеїв. Service, який спрямовує трафік, може все одно не мати межі вхідного або вихідного трафіку. Секрет, змонтований правильно, може все одно бути доступним для читання надто широко, мати надто довгий термін життя або зберігатися без захисту, якого очікує ваша організація.

Перш ніж запускати цю інспекцію, який вивід ви очікуєте від невеликого практичного кластера, який ніколи навмисно не посилювали? Більшість учнів передбачають одну-дві проблеми, але перше сканування часто показує одразу кілька класів прогалин: жодних NetworkPolicies, простори імен без міток Pod Security Admission, Под’и без runAsNonRoot і контейнери з невстановленими полями привілеїв. Цей сюрприз корисний, бо вчить вас не плутати типову поведінку кластера із посиленим станом.

Мислення безпеки — це не параноя; це структурований скептицизм. Ви питаєте, яка межа має захищати робоче навантаження, чи ця межа насправді налаштована, як зловмисник рухався б у разі її провалу та який лог довів би, що цей рух стався. Ці питання дають вам змогу читати звичайний вивід Kubernetes як докази безпеки.

Коли тренуєтеся, записуйте контроль і доказ окремо. Наприклад, «Pod Security Admission обмежує небезпечні поля робочого навантаження» — це контроль, тоді як «мітка простору імен pod-security.kubernetes.io/enforce=restricted» — це один шматок доказу. Тримання цих ідей окремо запобігає поширеній помилці: побачити мітку, команду або вивід інструмента й припустити, що передбачений захист повний.

Структура навчального плану та стратегія підготовки

Напрямок CKS у KubeDojo побудований за доменами іспиту, тож ваш шлях підготовки віддзеркалює мапу балів. Part 0 встановлює середовище та звички для іспиту, а потім пізніші частини будуються від контролю кластера до посилення робочих навантажень, безпеки ланцюга постачання та реагування під час виконання. Цей порядок важливий, бо кожен пізніший домен використовує припущення з ранніх доменів.

Частина	Домен	Вага	Модулі
0	Налаштування середовища	-	Підготовка до іспиту, налаштування лабораторії, інструменти
1	Cluster Setup	15%	Мережеві політики, CIS, ingress
2	Cluster Hardening	15%	RBAC, ServiceAccounts, API
3	System Hardening	10%	AppArmor, seccomp, ОС
4	Microservice Vulnerabilities	20%	Контексти безпеки, PSA, секрети
5	Supply Chain Security	20%	Аналіз образів, підписання, SBOM
6	Runtime Security	20%	Falco, аудит, інциденти

Part 1 — це місце, де мережеві знання з CKA стають примусовим виконанням безпеки. NetworkPolicy — це не просто об’єкт YAML; це різниця між скомпрометованим фронтендом, який досягає кожної бази даних, і скомпрометованим фронтендом, обмеженим відомими залежностями. Посилення ingress працює так само, бо TLS, конфігурація контролера та розкриття кінцевих точок визначають, чого може торкнутися зовнішній світ.

Part 2 затягує ідентичність і доступ до API. Завдання RBAC часто виглядають знайомими з CKA, але CKS просить найменших привілеїв, а не просто функціональності. Безпечніша звичка — починати з дієслова, ресурсу, простору імен і суб’єкта, які насправді потрібні, а потім додавати лише той дозвіл, який необхідний для сценарію.

Part 3 рухається нижче об’єктів Kubernetes у контролі хоста та ядра. AppArmor і seccomp можуть здаватися непов’язаними з Kubernetes, аж поки ви не побачите, що Под запитує профіль і потім виходить з ладу, бо процес спробував заблоковану дію. Ця частина вчить вас поєднувати поведінку робочого навантаження, конфігурацію середовища виконання та політику операційної системи.

Part 4 зосереджується на вразливостях мікросервісів усередині межі робочого навантаження. Контексти безпеки, Pod Security Standards, секрети, пісочниці (sandboxing) та техніки ізоляції — усе це формує те, що може зробити скомпрометований процес далі. Цінність для іспиту тут не в називанні поля; вона в тому, щоб вибрати поле, яке зменшує реалістичний шлях зловживання, не ламаючи застосунок без потреби.

Part 5 зсувається ліворуч у безпеку ланцюга постачання. Ви оцінюєте базові образи, походження артефактів, SBOM, дозволені реєстри, підписи та результати статичного аналізу. Цей домен має високу вагу, бо багато виробничих компрометацій починаються ще до того, як Kubernetes узагалі планує Под, а кластер може забезпечити лише те, що зробив видимим конвеєр доставки.

Part 6 замикає цикл моніторингом, логуванням та безпекою під час виконання. Політики аудиту, правила Falco, незмінність контейнерів і реагування на інциденти перетворюють безпеку з контрольного списку перед розгортанням на операційну практику. У цій частині правильна відповідь часто поєднує виявлення, збір доказів і крок із пом’якшення.

Стратегія трьох проходів нижче — це модель управління часом, а не жорсткий сценарій іспиту. Вона допомагає вам уникнути надто довгого зосередження на одному складному завданні, поки залишаються відкритими легші можливості набрати бали. Використовуйте її під час тренування, щоб звичка стала автоматичною ще до того, як стартує справжній таймер.

┌─────────────────────────────────────────────────────────────┐
│              CKS THREE-PASS STRATEGY                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  PASS 1: Quick Security Wins (1-3 min each)                │
│  ├── Create NetworkPolicy                                  │
│  ├── Apply existing AppArmor profile                       │
│  ├── Fix obvious RBAC issue                                │
│  └── Set runAsNonRoot: true                                │
│                                                             │
│  PASS 2: Tool-Based Tasks (4-6 min each)                   │
│  ├── Scan image with Trivy, fix vulnerabilities            │
│  ├── Create seccomp profile                                │
│  ├── Configure Pod Security Admission                       │
│  ├── Run kube-bench, fix findings                          │
│  └── Configure audit policy (when task supplies manifest)  │
│                                                             │
│  PASS 3: Complex Scenarios (7+ min each)                   │
│  ├── Write custom Falco rule                               │
│  ├── Investigate runtime incident                          │
│  ├── Multi-step hardening task                             │
│  └── Complex NetworkPolicy scenarios                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Перший прохід має охопити завдання, чиї критерії успіху є видимими й вузькими. Просту NetworkPolicy, відсутнє поле контексту безпеки, очевидне виправлення RoleBinding або мітку простору імен часто можна розв’язати швидко, якщо ви тренували форми YAML. Ці завдання цінні, бо вони нарощують бал і впевненість, не споживаючи середини іспиту.

Другий прохід — для завдань, де очікується інструмент або пошук у документації. Вам може знадобитися запустити сканер, прочитати вивід, скоригувати маніфест або адаптувати приклад постачальника. Небезпека тут — надмірне читання: щойно вивід ідентифікує те, що цікавить завдання, зробіть цільову зміну і рухайтеся далі замість того, щоб гнатися за кожним попередженням.

Третій прохід — для багатокрокової роботи, що вимагає синтезу. Розслідування під час виконання може попросити вас інтерпретувати правило, ідентифікувати процес, зберегти докази та застосувати пом’якшення. Складна NetworkPolicy може вимагати розуміння міток, селекторів простору імен, вихідного DNS-трафіку та залежностей застосунку. Це завдання з високою цінністю, але вони можуть поглинути забагато часу, якщо взятися за них перед легшою роботою.

Який підхід ви обрали б тут і чому: суворий потік іспиту від першого до останнього завдання чи потік на основі проходів, який навмисно пропускає нерозв’язані завдання та повертається до них пізніше? Потік на основі проходів зазвичай безпечніший для CKS, бо іспит змішує короткі виправлення контролю з глибшими розслідуваннями, і ваш бал не має залежати від того, чи перший складний сценарій з’явиться рано.

Будуйте свій особистий план навколо циклів зворотного зв’язку. Після кожної практичної сесії записуйте, до якого домену належало завдання, чи розв’язали ви його без документації, яка команда або шлях документації вас сповільнили та який тип помилки стався. За кілька сесій цей запис стане кориснішим за загальний контрольний список підготовки, бо він показує ваш фактичний патерн провалів.

Розбір прикладу: перетворення одного активного Под’а на знахідку про безпеку

Сценарій вправи: простір імен містить вебнавантаження, яке є справним з операційної точки зору. Деплоймент має бажану кількість реплік, Под’и в стані Running, Service має кінцеві точки, а HTTP-перевірка повертає успіх. Огляд у стилі CKA, ймовірно, рухався б далі після підтвердження логів, подій, готовності та маршрутизації. Огляд у стилі CKS продовжує, бо питання безпеки — не в тому, чи обслуговує робоче навантаження трафік, а в тому, що робоче навантаження могло б зробити після компрометації.

Почніть з ідентичності, бо ідентичність визначає, що робоче навантаження може просити сервер API зробити. Якщо Под використовує типовий ServiceAccount, знахідка не є автоматично серйозною, але це підказка перевірити, чи має простір імен типову поведінку токена, чи якийсь RoleBinding надає широкі дієслова цьому акаунту та чи робоче навантаження насправді потребує доступу до API. Навчальна дія — потренуватися читати об’єкти ServiceAccount, Role, RoleBinding, ClusterRole і ClusterRoleBinding як одну історію привілеїв, а не як ізольовані фрагменти YAML.

Далі перевірте привілеї процесу. Под, який пропускає runAsNonRoot, дозволяє ескалацію привілеїв, використовує типові можливості (capabilities) або монтує файлову систему з кореневим записом, може все одно працювати без помилок. Знахідка в тому, що маніфест залишає забагато поведінки на розсуд типових налаштувань образу та середовища виконання контейнерів. Ваша навчальна дія — побудувати невелику матрицю полів контексту безпеки, а потім розгорнути навмисно порушувані Под’и, щоб ви могли розпізнати різницю між відхиленням допуску, збоєм запуску контейнера та збоєм на рівні застосунку.

Тепер перевірте мережеву досяжність. Якщо простір імен не має NetworkPolicy, Под може ініціювати або отримувати трафік ширше, ніж потребує застосунок, залежно від CNI та будь-яких зовнішніх контролів. Правильне питання CKS — не «чи існує об’єкт політики десь у кластері», а «чи обраний політикою обмежує необхідні шляхи вхідного й вихідного трафіку цього Под’а». Ваша навчальна дія — потренуватися зі зіставленням міток і вихідним DNS-трафіком, бо політики, які блокують розв’язання імен, часто виглядають як збої застосунку, аж поки ви не пов’яжете симптом із контролем.

Потім перевірте розкриття даних. Робоче навантаження може змонтувати секрет правильно й усе одно розкривати забагато, якщо секрет містить широкі облікові дані, монтується в непотрібні контейнери або доступний для читання ServiceAccount’ом, яким може користуватися забагато суб’єктів. CKS не робить із вас фахівця з продуктів керування секретами, але він очікує, що ви помітите, чи використання секретів Kubernetes розширює радіус ураження. Ваша навчальна дія — простежити, який Под споживає секрет, який акаунт може його читати та чи міг би маніфест зменшити розкриття.

Докази ланцюга постачання надходять перед тим, як ви довіряєте образу. Якщо образ використовує великий базовий образ, не має корисних метаданих, несе відомі вразливості або прибуває без SBOM, коли завдання його просить, сам факт, що навантаження працює, доводить дуже мало. Ваша навчальна дія — потренуватися видобувати посилання на образ, запускати вказаний сканер або інструмент SBOM з інструкцій лабораторної роботи та відділяти релевантні завданню знахідки від шуму. На іспиті з обмеженим часом вам рідко потрібно виправляти кожну можливу проблему; вам потрібно виправити проблему, яку сценарій просить оцінити.

Докази під час виконання завершують картину, бо деякі ризики з’являються лише після старту процесу. Оболонка, породжена всередині контейнера, записи в неочікуваний шлях або виклик чутливого системного виклику можуть узагалі не змінити статус Kubernetes. Ваша навчальна дія — потренуватися читати умови правил у стилі Falco та зіставляти сповіщення назад із простором імен, Под’ом, контейнером, процесом і командою. Це зіставлення перетворює подію виявлення на шлях розслідування, а не на лячний рядок виводу.

Розбір прикладу породжує компактний запис рішення. Ідентичність питає, що може запросити робоче навантаження, привілеї процесу питають, що воно може зробити локально, мережева політика питає, куди воно може переміститися, розкриття даних питає, що воно може прочитати, перевірки ланцюга постачання питають, чи варто запускати артефакт, а докази під час виконання питають, що воно насправді зробило. Ці шість лінз дають вам практичний спосіб перетворити один справний Под на набір навчальних завдань CKS, не вигадуючи виробничого інциденту.

Якщо ви повторите цей приклад на кількох робочих навантаженнях, ви помітите, яку лінзу ви пропускаєте під тиском часу. Деякі кандидати забувають про ідентичність, бо RBAC здається знайомим; інші забувають про докази під час виконання, бо робоче навантаження виглядає тихим; інші надмірно зосереджуються на сканерах, бо вивід інструмента здається конкретним. Цінність вправи в тому, що вона виявляє вашу сліпу пляму ще до того, як це зробить іспит.

Патерни та антипатерни

Для швидкого орієнтаційного модуля найкорисніший патерн — пов’язувати кожну навчальну активність із конкретним рішенням про безпеку. Читати про Pod Security Standards корисно, але застосувати мітку простору імен, розгорнути порушуваний Под, прочитати відхилення, а потім виправити маніфест створює пам’ять, готову до іспиту. Той самий патерн працює для Falco, SBOM, RBAC, NetworkPolicies та профілів ядра.

Інший надійний патерн — тримати вузьку драбину доказів для кожного домену. Починайте з об’єкта Kubernetes, потім перевіряйте вивід контролера чи інструмента, а потім досліджуйте докази хоста чи виконання лише тоді, коли завдання вказує туди. Це запобігає випадковому блуканню командами, водночас нагадуючи вам, що не весь стан безпеки видно з однієї відповіді API.

Використовуйте провал як інструмент тренування. Навмисно розгорніть Под, який порушує обмежений профіль Pod Security, застосуйте NetworkPolicy, що блокує DNS, напишіть правило Falco з поганою умовою або налаштуйте профіль seccomp, що забороняє потрібний системний виклик. Зламати контроль у лабораторії вчить вас, як виглядає помилка, а це саме та навичка розпізнавання, яку винагороджує іспит.

Перший антипатерн — ставитися до CKS як до набування словникового запасу. Запам’ятати, що seccomp фільтрує системні виклики або що Falco виявляє поведінку під час виконання, мало допомагає, якщо ви не можете застосувати, перевірити й полагодити ці контролі. Завдання CKS практичні, тож вашими навчальними артефактами мають бути команди, маніфести, редагування правил і спостережувані результати.

Другий антипатерн — припускати, що безпечне налаштування нешкідливе, бо застосунок усе одно стартує. Контейнер, що працює не від root, кращий за той, що працює від root, але він може все одно мати зайві можливості, файлові системи з можливістю запису, широкий вихідний трафік і потужний ServiceAccount. Безпека є багатошаровою, і CKS часто перевіряє, чи можете ви ідентифікувати відсутній шар, а не радіти наявному.

Третій антипатерн — надмірна довіра до виводу інструмента. Знахідка сканера, результат бенчмарку чи збіг правила — це доказ, а не судження. Вам усе одно потрібно вирішити, чи знахідка в межах завдання, чи рекомендоване виправлення безпечне для робочого навантаження та чи зміна насправді задовольняє питання. На практиці запустіть інструмент, виокремте релевантну знахідку, зробіть найменше захищене виправлення та перевірте конкретний результат.

Варто також назвати, коли цей модуль не застосовується. Якщо ви готуєтеся до KCSA, вам потрібне ширше концептуальне покриття безпеки й менше швидкості команд на практиці. Якщо ви готуєтеся до CKA, вам потрібна глибша практика операцій кластера перед спеціалізацією на безпеці. Якщо ви будуєте виробничу програму безпеки, CKS є корисною основою, але він не замінює моделювання загроз, організаційну політику, навчання з реагування на інциденти та неперервні контролі.

Коли використовувати це проти альтернатив

Використовуйте підготовку до CKS, коли ваша мета — довести практичну компетентність із безпеки Kubernetes за нейтральних до постачальника умов іспиту. Вона особливо доречна, коли ви вже адмініструєте кластери й хочете структурований шлях через посилення робочих навантажень, контролі ланцюга постачання, виявлення під час виконання та розслідування інцидентів. Сертифікація достатньо вузька, щоб бути практичною, і достатньо широка, щоб змусити вас вийти за межі типових налаштувань керованого сервісу одного постачальника.

Використовуйте підготовку до KCSA, коли вам потрібна грамотність із безпеки без припущення про адміністрування рівня CKA. KCSA краще підходить архітекторам, менеджерам, інженерам на ранніх етапах кар’єри та учасникам, дотичним до платформи, яким потрібно розуміти концепції хмарної безпеки, але від яких поки що не очікують розв’язання завдань кластера під таймером у терміналі. Вона також може бути сходинкою перед CKA і CKS.

Використовуйте посилення CKA, коли ваші операції Kubernetes ще не автоматичні. Якщо редагування YAML, перемикання контекстів, інспекція RBAC, усунення несправностей сервісів чи налагодження на рівні вузла досі здаються повільними, то CKS лише підсилить це тертя. Завдання з безпеки накладаються поверх операційних завдань, тож слабкі основи адміністрування стають дорогими під час іспиту.

Використовуйте специфічні для постачальника сертифікації безпеки, коли ваша щоденна робота залежить від конкретного хмарного провайдера чи комерційної платформи. Ті сертифікації можуть глибше за CKS покривати інтеграцію IAM, керовані площини управління, пропрієтарне сканування, конвеєри логування чи рушії політик. Вони не замінюють CKS, бо CKS перевіряє переносні механізми безпеки Kubernetes, але вони можуть доповнювати його для виробничих ролей.

Використовуйте внутрішні виробничі навчання, коли ваша мета — організаційна готовність, а не результат на іспиті. Реальна програма безпеки потребує власності, маршрутизації сповіщень, огляду змін, обробки винятків і комунікацій під час інцидентів. CKS може навчити технічних контролів, але виробнича готовність вимагає соціальної та операційної машинерії навколо цих контролів.

Тому правило вибору просте: обирайте шлях, який відповідає роботі, яку вам потрібно виконати далі. Якщо вам потрібно захищати ресурси Kubernetes у командному рядку, CKS — правильна ціль. Якщо вам потрібен базовий словниковий запас, обирайте KCSA. Якщо вам потрібна швидкість ремонту кластера, обирайте практику CKA. Якщо вам потрібна специфічна для хмари деталь реалізації, додайте відповідний напрямок постачальника після того, як переносна модель Kubernetes стане міцною.

Чи знали ви?

CKS було оголошено загальнодоступним 17 листопада 2020 року. Оголошення CNCF про GA описує запуск як іспит на основі практичних завдань для захисту контейнерних робочих навантажень і платформ Kubernetes на етапах збирання, розгортання та виконання.
Прохідний бал CKS становить 67%, а сертифікація чинна 2 роки. Це поєднання означає, що іспит очікує практичної компетентності, але також очікує, що кандидати оновлюватимуть знання, бо інструментарій безпеки Kubernetes і середовища іспиту з часом змінюються.
Три домени CKS дають 60% балів. Microservice Vulnerabilities, Supply Chain Security та Monitoring, Logging, and Runtime Security несуть по 20% кожен, тому навчальний час не варто рівномірно розподіляти між усіма темами.
Безпека ланцюга постачання стала критичною як інтенсивно перевіряний домен CKS. Напрямок детально розглядає два канонічні інциденти: компрометацію системи збирання, яка надіслала підписані, але шкідливі оновлення тисячам клієнтів нижче за течією та транзитивну вразливість Java-бібліотеки логування, яка наражала будь-який застосунок, що приймає контрольовані зловмисником вхідні рядки .

Типові помилки

Помилка	Чому вона стається	Як її виправити
Вивчення лише об’єктів API Kubernetes	Звички CKA роблять так, що RBAC, NetworkPolicy і Под’и здаються всім іспитом	Додайте навмисні повтори для AppArmor, seccomp, SBOM, правил виконання та доказів аудиту
Сприйняття ваг доменів як дрібниць	Кандидати читають відсотки раз, але все одно вчать те, що здається найлегшим	Розподіляйте час практики за вагою, новизною та недавньою історією провалів
Ігнорування офіційного переліку дозволених ресурсів	Практика з пошуковими системами приховує, наскільки обмежений браузер іспиту	Тренуйте навігацію всередині точних дозволених доменів документації
Заучування назв інструментів без робочих процесів	Розпізнавання інструментів здається прогресом, аж поки завдання не вимагає інтерпретації	Запустіть кожен інструмент проти зламаного прикладу, поясніть релевантну знахідку та перевірте виправлення
Припущення, що `Running` означає безпечно	Операційний успіх видимий, тоді як привілеї та мережеве розкриття тихіші	Перевіряйте контексти безпеки, ServiceAccounts, політики, секрети та докази виконання окремо
Залишення посилення Linux наостанок	AppArmor і seccomp здаються меншими, бо System Hardening має нижчу вагу	Заплануйте інтервальну практику, бо помилки профілів ядра потребують часу для розпізнавання
Витрачання забагато часу на один складний сценарій	Розслідування безпеки можуть розгалужуватися на багато можливих шляхів	Використовуйте стратегію трьох проходів і повертайтеся до складної роботи після збору швидких балів

Тест

1. Ваш колега склав CKA кілька років тому й тепер хоче зареєструватися на CKS. Він планує вивчати лише RBAC і NetworkPolicies, бо це були його найсильніші теми на CKA. Як ви оцінили б його готовність?

Він задовольняє передумову CKS, якщо склав CKA до спроби CKS, але його план підготовки не готовий до іспиту. RBAC і NetworkPolicies важливі, проте вони покривають лише частину Cluster Hardening і Cluster Setup. Йому також потрібна практична робота з посиленням робочих навантажень, аналізом ланцюга постачання, виявленням під час виконання, доказами аудиту та контролями безпеки Linux. Краще судження про готовність порівнює його навички з кожним доменом CKS і дає додатковий час доменам із високою вагою та меншим перетином із CKA.

2. Під час тренування ви швидко розв'язуєте кожне завдання з налаштування кластера, але неодноразово провалюєте завдання SBOM і виявлення під час виконання. Мапа доменів іспиту надає кільком областям різні ваги. Як вам перепроєктувати план підготовки?

Вам варто перенести більше часу на Supply Chain Security та Monitoring, Logging, and Runtime Security, бо кожен із них є доменом із високою вагою, а ваші докази практики показують там слабкість. Налаштування кластера все одно потребує підтримувальних повторів, але додатковий час там має нижчу віддачу, якщо ви вже розв’язуєте ці завдання під тиском. Перепроєктований план має включати інтерпретацію виводу інструментів, навігацію документацією постачальника та сценарії зі зламаними лабораторними роботами для SBOM і доказів виконання. Тримайте короткий цикл огляду для знайомих доменів, щоб швидкість не згасала.

3. Под досягає `Running`, його Service спрямовує трафік, а логи застосунку чисті. Огляд у стилі CKS усе одно відхиляє цей деплоймент. Які докази безпеки ви перевірили б, перш ніж не погодитися?

Вам варто перевірити контекст безпеки Под’а, контекст безпеки контейнера, ServiceAccount, змонтовані секрети, мітки Pod Security Admission простору імен та NetworkPolicies, перш ніж вважати деплоймент прийнятним. Активний Под може все одно працювати від root, мати зайві можливості, використовувати потужний токен, приймати широкий мережевий трафік або монтувати чутливі дані. Вам також варто розглянути докази образу та виконання, якщо завдання вказує на проблеми ланцюга постачання чи виявлення. Мислення CKS полягає в тому, що доступність — лише одна властивість, а не доказ безпечної конфігурації.

4. У браузері іспиту ви шукаєте синтаксис правил Falco в документації Kubernetes і не можете знайти потрібний приклад макроса. Яке правило про дозволені ресурси ви зрозуміли неправильно?

Ви зрозуміли неправильно, що CKS має специфічний перелік дозволених ресурсів поза основною документацією Kubernetes. Документація Falco — це окремий дозволений домен для CKS, тож правильне відновлення — перейти безпосередньо до офіційної документації Falco зсередини середовища іспиту. Ширший урок — тренуватися з дозволеним набором документації перед іспитом. Якщо ви покладаєтеся на пошук у відкритому вебі під час підготовки, ви можете не знати, де живуть офіційні приклади постачальника, коли браузер іспиту обмежений.

5. Ваше перше практичне сканування показує жодних NetworkPolicies, невстановлені поля `runAsNonRoot` і простори імен без міток Pod Security Admission. Чому це корисна діагностика, а не просто список провалів?

Воно показує, яких контролів безпеки бракує в поточному стані кластера, і дає вам навчальну мапу, прив’язану до реальних доказів. Відсутність NetworkPolicies натякає на необмежену взаємодію між Под’ами, якщо CNI не забезпечує інших контролів. Невстановлений runAsNonRoot і відсутні мітки Pod Security вказують на прогалини в посиленні робочих навантажень, які домен мікросервісів CKS перевіряє інтенсивно. Сприйняття сканування як діагностики допомагає перетворити спостереження на пріоритезовані навчальні завдання.

6. Ви на половині пройденого пробного іспиту з обмеженим часом, і розслідування під час виконання поглинуло забагато часу. Кілька коротких завдань із посилення залишаються без відповіді. Якою має бути ваша стратегія іспиту?

Вам варто позначити складне розслідування під час виконання, зафіксувати будь-які часткові докази чи легке пом’якшення, яке ви вже знаєте, і перейти до коротших завдань. Стратегія трьох проходів існує, бо CKS змішує швидкі виправлення конфігурації з глибшими розслідуваннями. Завершення кількох вузьких завдань може дати надійніший бал, ніж надмірне вкладання в один непевний сценарій. Поверніться до складного завдання після збору легших балів.

7. Кандидат каже, що запам'ятовуватиме кожну команду замість тренування навігації документацією, бо пошук у документації повільний. Чому це ризиковано для CKS?

Це ризиковано, бо CKS включає специфічні для інструментів і безпеки завдання, де точний синтаксис, приклади та підтримувані поля мають значення. Запам’ятовування допомагає з поширеними формами команд, але документація постачальника безпечніша для детальних правил Falco, команд SBOM, прикладів політик і конфігурації крайніх випадків. Іспит дозволяє специфічні офіційні ресурси, бо від практичних інженерів очікують уміння добре користуватися документацією. Збалансована стратегія запам’ятовує патерни високої частоти й тренує швидкий пошук деталей.

Практична вправа

Сценарій вправи: використайте практичний кластер Kubernetes 1.35+ або лабораторне середовище, щоб виконати першу інспекцію стану безпеки. Мета — не повністю посилити кластер у цьому модулі; це навчитися, як звичайний вивід kubectl стає доказом CKS. Якщо у вас ще немає готового кластера, прочитайте команди зараз і запустіть їх після модуля з налаштування лабораторії.

Виконайте ці завдання по порядку й запишіть докази, які знайдете. Кожне завдання будується від простого виявлення до судження про безпеку, тож уникайте виправлення чогось, поки не зможете пояснити, що означає поточний стан. Ця звичка важлива в CKS, бо передчасні зміни можуть приховати саме той доказ, який завдання хотіло, щоб ви перевірили.

Визначте, чи розкриває площина управління докази конфігурації допуску або аудиту.
Підрахуйте NetworkPolicies в усіх просторах імен і вирішіть, чи має кластер типову мережеву межу.
Перевірте налаштування runAsNonRoot на рівні робочого навантаження та занотуйте простори імен, де поле не встановлено.
Знайдіть привілейовані контейнери, якщо вони є, і запишіть простір імен, Под і контекст контейнера, який ви перевірили б далі.
Перегляньте мітки Pod Security Admission та вирішіть, які простори імен відхиляли б порушення обмеженої політики.

# Step 1: Check if your cluster has basic security features
echo "=== Checking API Server Security ==="
kubectl get pods -n kube-system | grep apiserver
kubectl get pods -n kube-system -l component=kube-apiserver -o yaml 2>/dev/null | grep -E "enable-admission|audit" | head -5 || echo "Check on control plane node"

# Step 2: Check for NetworkPolicies (most clusters have none by default)
echo "=== NetworkPolicy Count ==="
kubectl get networkpolicies -A
NETPOL_COUNT=$(kubectl get networkpolicies -A --no-headers 2>/dev/null | wc -l)
echo "Total NetworkPolicies: $NETPOL_COUNT"
if [ "$NETPOL_COUNT" -eq 0 ]; then
  echo "No NetworkPolicies found. Pods may communicate freely unless another control enforces policy."
fi

# Step 3: Check Pod-level runAsNonRoot (container-level fields are covered in later modules)
echo "=== Pods Running as Root ==="
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}: runAsNonRoot={.spec.securityContext.runAsNonRoot}{"\n"}{end}' | head -10

# Step 4: List privileged containers with namespace/Pod/container context (positives only)
echo "=== Privileged Containers ==="
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}/{range .spec.containers[*]}{.name}: privileged={.securityContext.privileged}{"\n"}{end}{end}' | grep 'privileged=true'

# Step 5: Check Pod Security Admission labels
echo "=== Pod Security Standards ==="
kubectl get namespaces -o jsonpath='{range .items[*]}{.metadata.name}: {.metadata.labels.pod-security\.kubernetes\.io/enforce}{"\n"}{end}' | grep -v ": $"

# Step 6: Identify security improvements needed
echo ""
echo "=== Security Gaps Identified ==="
echo "Review the output above. Common gaps include:"
echo "- No NetworkPolicies (pods can talk to anything)"
echo "- Pods running as root"
echo "- No Pod Security Standards enforced"
echo "- Missing audit logging"

Перевірка сервера API навмисно консервативна, бо керовані кластери та локальні лабораторії розкривають деталі площини управління по-різному. Якщо команда не може прочитати маніфести статичних Под’ів через API, це не доводить, що допуск чи логування аудиту відсутні. Це означає, що наступним джерелом доказів може бути вузол площини управління, інтерфейс конфігурації керованого сервісу чи інструкції лабораторної роботи.

Підрахунок NetworkPolicy — це відправна точка, а не повний аудит політик. Кластер із нульовою кількістю політик зазвичай не має нативної для Kubernetes межі трафіку Под’ів, але кластер із кількома політиками може все одно дозволяти забагато трафіку, якщо селектори широкі або відсутній вихідний трафік. У пізніших модулях ви перейдете від підрахунку політик до доведення того, які потоки дозволені.

Запит runAsNonRoot перевіряє контекст безпеки на рівні Под’а, що є лише одним місцем, де це налаштування може з’явитися. Контекст безпеки на рівні контейнера може перевизначати чи доповнювати налаштування на рівні Под’а, а Pod Security Admission може застосовувати обмеження навіть тоді, коли маніфест пропускає явні поля. Суть цього першого проходу — помітити невстановлений стан, а потім вивчити глибші правила в модулях із посилення робочих навантажень.

Запит привілейованих контейнерів друкує лише рядки namespace/pod/container: privileged=true, тож ви можете записати точний контекст, який завдання CKS попросило б вас перевірити далі. Якщо вивід з’являється, перевірте повний маніфест Под’а та визначте, чи роблять ризик гіршим простори імен хоста, шляхи хоста, можливості (capabilities) або дозволи ServiceAccount. Якщо вивід порожній, вам усе одно потрібні інші контролі, бо «не привілейований» — це не те саме, що «найменші привілеї».

Перевірка міток Pod Security Admission каже вам, чи оголошують простори імен рівень примусу, як-от baseline чи restricted. Відсутні мітки поширені в практичних кластерах, і вони дають вам конкретний шлях покращення для пізніших модулів. Мітки також нагадують, що CKS часто перевіряє політику на рівні простору імен і поля на рівні робочого навантаження разом.

Орієнтири розв'язання для завдань 1-2

Для завдання із сервером API запишіть, чи бачили ви прапорці, пов’язані з допуском або аудитом, і звідки прийшов доказ. Для завдання NetworkPolicy запишіть кількість та принаймні один простір імен, що не має видимої політики. Захищена відповідь розрізняє «я не мав доступу до цього доказу через API» та «контроль однозначно відсутній».

Орієнтири розв'язання для завдань 3-5

Для runAsNonRoot, привілейованих контейнерів і міток Pod Security Admission запишіть точне поле, яке було невстановленим або налаштованим. Якщо вивід порожній, занотуйте, що команда насправді перевірила і чого не перевірила. Це запобігає хибній упевненості й готує вас до пізніших модулів, де ви перевірятимете поля на рівні контейнера, мітки простору імен і поведінку допуску разом.

Критерії успіху:

Ви можете порівняти операційні докази у стилі CKA з доказами безпеки у стилі CKS з того самого кластера.
Ви можете оцінити, чи має ваш практичний кластер видимі прогалини в мережевій політиці, ідентичності робочих навантажень і Pod Security Admission.
Ви можете спроєктувати наступні три навчальні дії на основі найризикованіших прогалин, які ви спостерігали.
Ви можете діагностувати принаймні одне місце, де успішний стан робочого навантаження не доводить безпечного стану робочого навантаження.
Ви можете впровадити стратегію трьох проходів, позначаючи кожну знахідку як швидку перемогу, завдання на основі інструмента чи складний сценарій.

Перевірка для учня

Двогодинне вікно приблизно на сімнадцять практичних завдань означає, що ви маєте розподіляти час, фіксувати пропущену роботу та уникати того, щоб одна важка задача стала причиною втрати кількох легших. Кількість завдань може змінюватися, коли Linux Foundation оновлює симулятор, тож сприймайте сторінку Important Instructions як джерело істини якнайближче до дати вашого іспиту.

Джерела

Наступний модуль

Модуль 0.2: Налаштування лабораторії безпеки — Побудуйте своє практичне середовище CKS із інструментами безпеки та патернами доступу до кластера, на які посилається цей огляд.