Лабораторна робота CNPE: спостережуваність, безпека та операції

Напрямок CNPE | Складність: [СКЛАДНА] | Час на проходження: 75-90 хв

Передумови: CNPE Exam Strategy and Environment, Observability Theory, SRE, Security Principles, DevSecOps, Prometheus, OpenTelemetry, Grafana, Loki, OPA/Gatekeeper, Kyverno, Falco

Результати навчання

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

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

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

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

Операції у стилі CNPE очікують, що ви працюватимете як людина, здатна тримати цю безладну сцену під контролем. Вам потрібно відокремити вплив на користувачів від шуму інструментування, визначити, який компонент площини управління чи площини даних накладає обмеження, і обрати корекцію, яка не обмінює безпеку на короткочасну доступність без доказів. Уміння полягає не в тому, щоб запам’ятати, де саме розташовані Grafana, Prometheus, Loki, OpenTelemetry, Gatekeeper, Kyverno, Falco чи події Kubernetes. Уміння полягає в тому, щоб використовувати їх усі разом як єдину систему доказів, яка перетворює розпорошений, хаотичний інцидент на чітку послідовність тверджень, кожне з яких можна перевірити окремо.

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

Аналогія з кабіною пілота

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

Побудова ланцюга доказів перед зміною кластера

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

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

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

User impact
    |
    v
+---------------------+      +-------------------+
| Metrics and alerts  | ---> | Logs and events   |
+---------------------+      +-------------------+
          |                            |
          v                            v
+---------------------+      +-------------------+
| Traces/dependencies | ---> | Recent change set |
+---------------------+      +-------------------+
          |
          v
+---------------------+
| Smallest safe fix   |
+---------------------+

Перш ніж запускати це, який результат ви очікуєте, якщо проблема — це відмова допуску, а не збій контейнера? Запишіть сигнал, який ви очікуєте від kubectl get events, сигнал, який ви очікуєте від kubectl logs, і метрику, яка, на вашу думку, лишиться незмінною. Цей маленький крок прогнозування важливий, бо він не дає вам шукати, доки щось не видасться підозрілим, а натомість змушує перевіряти гіпотезу проти кластера.

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

kubectl get deploy,pod,rs -n <namespace> -l app=<app-name>
kubectl get events -n <namespace> --sort-by=.lastTimestamp | tail -n 30
kubectl logs deploy/<app-name> -n <namespace> --tail=80
kubectl rollout history deploy/<app-name> -n <namespace>
kubectl describe deploy/<app-name> -n <namespace>

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

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

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

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

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

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

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

Стан контролера також може ввести в оману, коли ви читаєте його без часу. Деплоймент, який зараз повідомляє про доступні репліки, все одно міг збоїти протягом десяти хвилин у вікні впливу на користувачів, а Под, який зараз готовий (Ready), міг неодноразово перезапускатися, перш ніж стабілізуватися. Саме тому впорядкування подій, історія розгортань і часові лінії метрик важать разом. Сценарії CNPE часто містять нещодавню зміну, бо іспит хоче, щоб ви міркували про послідовність, а не лише про стан. Питання рідко звучить як «що є правдою зараз?» саме по собі; воно звучить як «що змінилося перед появою симптому й що доводить цей зв’язок?»

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

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

Сумісне читання сигналів стану та спостережуваності Kubernetes

Kubernetes дає вам кілька шарів стану, і вони не всі означають одне й те саме. Деплоймент може прогресувати, тоді як кожен запит збоїть, Под може бути в стані Running, тоді як застосунок не готовий (Ready), а Сервіс може мати ендпоїнти, тоді як одна залежність тихо вичерпує тайм-аут. Питання CNPE часто ховають відповідь саме в цій різниці. Вам потрібно читати намір контролера, життєвий цикл Под’а, стан контейнера та сигнали SLO, спрямовані на користувача, як пов’язані, але окремі докази, бо кожен шар звітує з іншої точки зору.

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

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

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

Сигнал	Що показує найкраще	Слабкість	Операційне питання
Метрики	Частота, величина, тренд, насичення, спалювання бюджету помилок	Низька деталізація та слабка причинність	Чи симптом реальний і наскільки він серйозний?
Логи	Локальні деталі помилок, контекст запиту, збої під час запуску	Обсяг, семплування, відсутність структури	Що сталося всередині цього процесу чи контролера?
Трейси	Шлях запиту, тайминг залежностей, поширення контексту	Потребують інструментування та поширення контексту	Де цей запит провів час або зазнав збою?
Події	Планування, допуск, том, образ, проба, рішення контролера	Коротке зберігання та нерівномірна деталізація	Що Kubernetes вирішив або відхилив?
Логи аудиту та політик	Рішення авторизації та допуску	Великий обсяг і чутливий вміст	Хто чи що намагалося виконати операцію?
Сповіщення під час виконання	Підозрілий процес, файл, мережа чи поведінка системних викликів	Потребують налаштування та сортування	Чи поводиться запущений контейнер поза межами політики?

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

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

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

Ось проопрацьований приклад читання заблокованого розгортання без жодних змін. Команди навмисно ставлять контролеру, потоку подій і системі авторизації окремі питання. У реальному кластері ви замінили б заповнювачі на простір імен, деплоймент, сервісний акаунт і назви ресурсів зі сценарію.

kubectl rollout status deploy/<app-name> -n <namespace> --timeout=60s
kubectl get events -n <namespace> --sort-by=.lastTimestamp | tail -n 40
kubectl auth can-i get secrets --as=system:serviceaccount:<namespace>:<service-account> -n <namespace>
kubectl describe pod -n <namespace> -l app=<app-name>

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

Який підхід ви обрали б тут і чому: надати сервісному акаунту застосунку широкий доступ до секретів простору імен, створити Роль для одного названого секрета чи змінити деплоймент так, щоб він посилався на секрет, керований платформою? Найкраща відповідь залежить від контракту платформи, але міркування у стилі CNPE мають надавати перевагу найвужчому дозволу, що відповідає задокументованій потребі робочого навантаження. Широка RoleBinding може зробити так, що розгортання пройде, проте вона також розширює радіус ураження будь-якої майбутньої компрометації.

Ставлення до контролів безпеки як до частини операцій

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

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

Request or runtime behavior
          |
          v
+-------------------------+
| Authentication identity |
+-------------------------+
          |
          v
+-------------------------+
| RBAC authorization      |
+-------------------------+
          |
          v
+-------------------------+
| Admission and policy    |
+-------------------------+
          |
          v
+-------------------------+
| Runtime and network     |
+-------------------------+
          |
          v
+-------------------------+
| Verified workload state |
+-------------------------+

OPA/Gatekeeper та Kyverno — поширені способи виразити політику допуску як код, але вони пасують до дещо різних ментальних моделей. Gatekeeper використовує екосистему Open Policy Agent і ConstraintTemplates, що може бути потужним, коли командам потрібна повторно використовувана логіка політик. Kyverno працює напряму з правилами у стилі Kubernetes YAML, що може бути простіше для команд платформи, які хочуть тримати політики валідації, мутації, генерації та перевірки образів близько до звичайних маніфестів. Операційне питання не в тому, який інструмент модний; воно в тому, чи політика пояснює себе, чи зрозуміло сигналізує про збій і чи підтримує вузьке виправлення.

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

Збої RBAC потребують такої самої обережності, бо помилка дозволу часто спокушає людей надати доступ на рівні всього кластера. Правильне питання — не «який дозвіл змусить помилку зникнути?», а «який ресурс, дієслово, простір імен і суб’єкт відповідають фактичній відповідальності робочого навантаження?». RBAC у Kubernetes є адитивним, тож щойно ви надали дозвіл, ви не можете прибрати його іншою Роллю. Такий дизайн робить найменші привілеї операційною звичкою, а не паперовою формальністю.

Збої секретів та ідентичності робочого навантаження часто виглядають як помилки застосунку, доки ви не оглянете потік подій і середовище. Под може збоїти, бо Secret не існує, бо проєктований том не вдається примонтувати, бо контролер ще не створив Secret або бо бракує прив’язки зовнішньої ідентичності. Безпечне виправлення залежить від патерну платформи. Ви можете виправити посилання SecretStore, відремонтувати ExternalSecret, прив’язати сервісний акаунт Kubernetes до хмарної ідентичності або виправити роль Vault, але вам слід уникати поміщення чутливих значень безпосередньо в маніфести як аварійного скорочення.

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

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

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

Практичне розслідування безпеки також має розрізняти ідентичність і дозвіл. Ідентичність відповідає на питання «хто робить цей запит?». Дозвіл відповідає на питання «що цій ідентичності дозволено робити?». У Kubernetes суб’єктом може бути людина-користувач, контролер чи сервісний акаунт, примонтований у робоче навантаження. Якщо ідентичність неправильна, додавання їй дозволів може просто благословити неправильну конфігурацію. Якщо ідентичність правильна, але дозволу бракує, Роль чи прив’язку можна виправити вузько. Змішування цих питань — це те, як команди випадково надають владу не тому суб’єкту.

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

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

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

Симптом	Імовірна точка контролю	Докази для огляду	Безпечніше виправлення
`forbidden` від API-сервера	Авторизація RBAC	`kubectl auth can-i`, Role, RoleBinding, ServiceAccount	Надати вузьке дієслово/ресурс/простір імен, що потрібні
`denied the request` у подіях	Політика допуску	Події, логи рушія політик, об’єкт політики	Виправити маніфест або вузьке правило політики
Том секрета не монтується	Доступ до секрета чи існування об’єкта	Події Под’а, Secret, ExternalSecret, сервісний акаунт	Виправити посилання на секрет чи прив’язку ідентичності
Под відхилено через контекст безпеки	Безпека Под’а чи політика допуску	Специфікація Под’а, мітки простору імен, повідомлення політики	Встановити сумісні поля або вузький виняток
Сповіщення про процес під час виконання	Виявлення під час виконання	Подія Falco, логи Под’а, образ, команда, нещодавня зміна	Підтвердити поведінку, ізолювати чи налаштувати з доказами
Трафік заблоковано після деплою	Мережева політика чи ідентичність сітки	Ендпоїнт, мітки політики, події сітки, шлях трейсу	Виправити мітки чи політику для передбаченого шляху

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

Цикли операційного виправлення та перевірки

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

Найменше безпечне виправлення зазвичай те, що змінює найменше припущень. Якщо Деплоймент посилається на неправильну назву Secret, виправте посилання або створіть передбачений Secret через схвалений контролер. Якщо Ролі бракує get для одного ConfigMap, надайте це одне дієслово конкретному сервісному акаунту в конкретному просторі імен. Якщо дроселювання CPU пояснює затримку, а запити занижені, скоригуйте запити й ліміти ресурсів у маніфесті, замість того щоб вручну видаляти Под’и й сподіватися, що перепланування допоможе. Маленькі виправлення не завжди є достатніми самі по собі, але вони зберігають причинно-наслідковий зв’язок недоторканим, тож згодом ви можете чітко довести, що саме спрацювало, а що ні.

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

Ось простий цикл перевірки, який тримає видимим зв’язок «до й після». Його можна адаптувати майже до будь-якого інциденту платформи, бо він не передбачає конкретного стека інструментів. Мета — написати історію інциденту так, щоб інший інженер міг відтворити її з доказів, а не довіряти вашій пам’яті.

kubectl get events -A --sort-by=.lastTimestamp | tail -n 20
kubectl logs deploy/<name> -n <namespace> --tail=50
kubectl describe deploy/<name> -n <namespace>

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

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

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

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

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

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

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

Коли виправлення є зміною політики чи дозволу, включіть негативну перевірку. Позитивна перевірка доводить, що передбачене робоче навантаження тепер працює; негативна перевірка доводить, що захисний бар’єр досі блокує те, що має блокувати. Наприклад, після додавання вузького винятку для одного робочого навантаження перевірте чи обґрунтуйте, чому непов’язані робочі навантаження не можуть використати той самий виняток. Після додавання Ролі перевірте, що сервісний акаунт досі не може отримати доступ до сусідніх секретів чи ресурсів рівня кластера. Цей додатковий крок — те, що перетворює безпеку з перешкоди на операційний інваріант.

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

Нарешті, практикуйте повідомлення про невизначеність. Сильний інженер платформи не каже «дашборд був червоний, тож я це виправив». Він каже «затримка зросла після розгортання, трейси показали затримку залежності, події не показали збою допуску, а відкат відновив початковий SLO, тож випуск, імовірно, змінив поведінку залежності; політика й RBAC не були причетними за зібраними доказами». Це твердження обережне, перевірюване й чесне щодо впевненості. Воно дає наступному інженеру місце, щоб продовжити, замість туманного твердження про першопричину.

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

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

Патерн	Коли використовувати	Чому він працює	Міркування щодо масштабування
Спершу ланцюг доказів	Будь-який інцидент із незрозумілою причиною	Він прив’язує вплив на користувача до незалежних сигналів перед виправленням	Стандартизуйте формат нотатки інциденту між командами
Картування точок контролю	Будь-яка відмова безпеки чи деплою	Він відокремлює рішення RBAC, допуску, виконання, мережі та ідентичності	Підтримуйте володіння кожною системою політик та ідентичності
Найменше безпечне виправлення	Будь-яке виправлення в умовах невизначеності	Він зберігає причинність і обмежує радіус ураження	Надавайте перевагу змінам у Git та вузьким виняткам
Перевірка за початковим симптомом	Після кожного виправлення	Він доводить, що контракт користувача чи платформи відновлено	Тримайте дашборди SLO та запити подій близько до посібників

Антипатерн	Що йде не так	Чому команди в це впадають	Краща альтернатива
Тунельний зір на дашборд	Команда сприймає симптом як першопричину	Графіки видимі й емоційно переконливі	Корелюйте метрики з логами, трейсами, подіями та змінами
Обхід безпеки як виправлення інциденту	Доступність повертається, тоді як довіра до платформи слабшає	Політика здається перешкодою під тиском	Виправте маніфест, політику чи шлях вузького винятку
Налагодження з багатьма змінами	Ніхто не знає, яка зміна допомогла чи зашкодила	Паралельна дія здається продуктивною	Змініть одну захищувану річ і перевірте початковий симптом
Широкі надання RBAC	Робоче навантаження отримує непотрібні дозволи	`cluster-admin` швидко змушує помилки зникнути	Надавайте вузькі дієслова на названих ресурсах, де можливо
Ручне введення секретів	Чутливі значення вислизають із робочого процесу платформи	Це виглядає швидше, ніж ремонт ідентичності чи контролерів	Відремонтуйте потік External Secrets, Vault чи ідентичності навантаження
Ігнорування сповіщень під час виконання	Підозріла поведінка лишається нерозслідуваною	Команди припускають, що шумні виявлення хибнопозитивні	Корелюйте сповіщення, образ, команду, логи й нещодавні зміни

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

Фреймворк прийняття рішень

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

1. Is there confirmed user or platform impact?
   |
   +-- No  -> tune alert, document noise, or monitor with lower urgency
   |
   +-- Yes -> identify the strongest changed signal
              |
              +-- Metrics only changed
              |      -> compare saturation, error rate, deployment time, dependency latency
              |
              +-- Events show control plane rejection
              |      -> inspect admission, RBAC, secret, scheduling, or volume cause
              |
              +-- Logs show local failure
              |      -> compare config, secret, dependency, and rollout history
              |
              +-- Traces show dependency delay
              |      -> inspect upstream health, network policy, identity, and routing
              |
              +-- Runtime alert fired
                     -> correlate process behavior, image, Pod identity, and recent changes

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

Ситуація	Надавати перевагу	Уникати	Перевірка
Відмова допуску з чітким повідомленням	Виправлення маніфеста чи вузьке оновлення політики	Глобальне вимкнення політики	Розгортання успішне, а політика досі відхиляє недійсний тестовий випадок
RBAC `forbidden` для одного ресурсу	Вузька Роль і RoleBinding	Прив’язка адміна на рівні кластера	`kubectl auth can-i` проходить лише для передбаченої дії
Затримка з насиченням ресурсів	Коригування запиту чи ліміту ресурсів	Виправлення лише через перезапуск	Затримка, дроселювання, перезапуски й тиск на ноду покращуються
Затримка, ізольована до залежності	Діагностика залежності чи мережевого шляху	Масштабування непов’язаних фронтенд Под’ів	Шлях трейсу й метрики залежності відновлюються
Відсутнє монтування секрета	Виправлення посилання на секрет чи контролера	Жорстко закодоване чутливе значення в маніфесті	Под монтує секрет, а робочий процес секрета лишається керованим
Підозріла поведінка під час виконання	Корелювати й ізолювати, якщо ризик правдоподібний	Ігнорування всіх виявлень виконання як шуму	Сповіщення припиняється для виправленої причини або є запис про ескалацію

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

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

Чи знали ви?

Події Kubernetes зберігаються через API-сервер як об’єкти подій, але термін зберігання подій навмисно обмежений конфігурацією кластера, тож серйозні робочі процеси інцидентів мають експортувати важливі події до довговічного логування чи сховища спостережуваності.
Правила сповіщень Prometheus відокремлюють виявлення від сповіщення: Prometheus обчислює вирази сповіщень, тоді як Alertmanager обробляє групування, придушення, заглушення й маршрутизацію до отримувачів.
OpenTelemetry визначає трейси, метрики й логи як окремі типи сигналів, ось чому платформа може стандартизувати збір, не змушуючи кожну команду використовувати той самий продукт серверного сховища.
Kubernetes v1.35 утримує Pod Security Standards орієнтованими навколо профілів Privileged, Baseline та Restricted, тож сумісне виправлення часто означає виправлення таких полів, як ескалація привілеїв, можливості (capabilities), простори імен хоста та seccomp, а не винайдення власної моделі безпеки.

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

Помилка	Чому вона трапляється	Як її виправити
Дивитися лише на Grafana	Дашборди видимі першими й показують симптоми переконливо, але вони зазвичай не доводять, чому симптом стався.	Корелюйте метрики з логами, трейсами, подіями Kubernetes, історією розгортань і рішеннями політик, перш ніж змінювати платформу.
Ламати безпеку, щоб виправити доступність	Під тиском контроль, який блокує деплоймент, може виглядати як проблема, а не як система, що захищає платформу.	Виправте те, що блокує, зберігаючи контролі через сумісний маніфест, вузький RBAC, вузький виняток чи виправлену політику.
Змінювати кілька речей одночасно	Паралельні виправлення здаються ефективними під час інциденту, але вони стирають причинний зв’язок між доказами й виправленням.	Спершу змініть найменший захищуваний елемент, потім перевірте початковий симптом і підтверджувальні сигнали перед наступною зміною.
Ігнорувати помилки допуску чи RBAC	Команди іноді припускають, що відповідь у логах застосунку, навіть коли робоче навантаження ніколи не було допущене чи авторизоване.	Перевіряйте події, повідомлення політик, `kubectl auth can-i`, Ролі, RoleBinding, сервісні акаунти й мітки простору імен рано.
Забути перевірити після виправлення	Успішну команду можна сплутати з відновленим сервісом, особливо коли CLI завершується чисто.	Перевірте повторно початковий симптом, стан контролера, потік подій, логи та відповідний сигнал політики чи ідентичності.
Надавати широкі дозволи для вузького збою	Швидше додати потужну прив’язку, ніж оглянути точне дієслово, ресурс і простір імен, що зазнали збою.	Використовуйте найменші привілеї, чітко називайте суб’єкт і перевіряйте, що успішно виконується лише передбачена дія.
Сприймати виявлення під час виконання як звичайний шум сповіщень	Повторювані хибнопозитиви можуть змусити команди ігнорувати єдиний сигнал, що заслуговує на сортування безпеки.	Корелюйте сповіщення під час виконання з образом, командою, ідентичністю Под’а, часом деплою й очікуваною поведінкою процесу.
Жорстко кодувати значення секретів під час збою	Ремонт належної ідентичності чи контролера секретів може здаватися повільнішим за поміщення значення прямо в маніфест.	Відновіть схвалений робочий процес секретів через External Secrets, Vault, ідентичність робочого навантаження чи контролер, керований платформою.

Тест

Питання 1: Ваша команда бачить, що затримка API стрибає одразу після деплою, але перезапуски Под'ів пласкі, а потік подій не має попереджень. Трейси показують, що більшість часу запиту витрачається на очікування висхідного сервісу авторизації. Що вам слід перевірити далі?

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

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

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

Питання 3: Робоче навантаження отримує `forbidden`, намагаючись прочитати один ConfigMap у власному просторі імен. Яке виправлення найкраще зберігає стан безпеки платформи?

Створіть чи оновіть Роль, обмежену простором імен, яка надає конкретне дієслово на конкретному ресурсі, потім прив’яжіть її до сервісного акаунта робочого навантаження. Прив’язка на рівні кластера чи широкий доступ до ресурсів змусили б негайну помилку зникнути, водночас розширивши радіус ураження за межі доказів. Вам слід перевірити через kubectl auth can-i з ідентичністю сервісного акаунта, а потім підтвердити, що застосунок відновлюється. Ця відповідь зіставляє симптом з авторизацією RBAC, а не з політикою допуску чи виконання.

Питання 4: Сповіщення під час виконання у стилі Falco повідомляє про неочікуване виконання командної оболонки в контейнері, але Деплоймент здоровий, а трафік користувачів виглядає нормально. Що має зробити ваше реагування на інцидент?

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

Питання 5: Сервіс не може примонтувати Secret після оновлення контролера платформи. Метрики показують збійні запити, логи показують лише відсутні облікові дані, а події згадують збій проєктованого тома. Який найкорисніший перший шлях виправлення?

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

Питання 6: Мережеву політику було змінено в той самий час, коли внутрішній сервіс почав вичерпувати тайм-аут лише при виклику з одного простору імен. Як вам слід перевірити виправлення?

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

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

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

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

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

Налаштування

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

kubectl get namespaces
kubectl get deploy -A
kubectl get serviceaccount -A

Завдання

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

Посібник з розв'язання для Завдання 1

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

Посібник з розв'язання для Завдання 2

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

Посібник з розв'язання для Завдання 3

Назвіть площину, яка ухвалила рішення чи породила збій. Збої RBAC зазвичай містять forbidden; збої допуску зазвичай з’являються до того, як об’єкт запуститься; збої монтування секретів з’являються в подіях Под’а; виявлення під час виконання з’являються після запуску контейнера; збої залежностей з’являються в трейсах і логах застосунку. Це зіставлення захищає вас від зміни не того шару.

Посібник з розв'язання для Завдання 4

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

Посібник з розв'язання для Завдань 5 і 6

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

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

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

Команди перевірки

kubectl get events -A --sort-by=.lastTimestamp | tail -n 20
kubectl logs deploy/<name> -n <namespace> --tail=50
kubectl describe deploy/<name> -n <namespace>

Джерела

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

Продовжуйте з CNPE Full Mock Exam, де GitOps, платформні API, спостережуваність і безпека поєднуються в один пробіг з обмеженням часу.