Модуль 1.2: Безпека хмарного провайдера

Складність: [СЕРЕДНЯ] — фундаментальні знання

Час на проходження: 45-60 хвилин

Передумови: Модуль 1.1: Чотири «С» хмарної безпеки

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

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

Оцінювати межу спільної відповідальності для керованих площин управління Kubernetes, робочих вузлів, ідентичностей, мереж і даних.
Діагностувати збої хмарного IAM та Kubernetes RBAC, які дозволяють підміну ідентичності робочого навантаження або надмірний доступ до кластера.
Проєктувати хмарні засоби контролю мережі та шифрування для приватних точок доступу до API, розміщення підмереж, сегментації Pod’ів і керування ключами.
Порівнювати налаштування безпеки за замовчуванням у EKS, GKE та AKS, а потім обирати компенсаційні засоби контролю для робочих кластерів.
Впроваджувати карту відповідальності на основі доказів та робочий процес перевірки за допомогою команд Kubernetes 1.35+ з аліасом k.

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

Патерн підміни через метадані/SSRF, розглянутий у модулі CKS про метадані вузла , віддзеркалює архітектурну межу, яку було перетнуто під час витоку даних Capital One у 2019 році (постраждало ~100 млн осіб; цивільний грошовий штраф OCC у розмірі $80 млн у 2020 році). Помилка в робочому навантаженні стала проблемою хмарної ідентичності, а проблема хмарної ідентичності стала проблемою розкриття даних. Урок, який варто винести для KCSA, — це не конкретний експлойт; це архітектурна межа, яку цей експлойт перетнув. Робоче навантаження, що виконується всередині кластера, водночас виконується всередині хмарного облікового запису, а цей хмарний обліковий запис містить ідентичності, мережеві шляхи, сховища об’єктів та привілеї, які сам кластер не може відкликати. Регуляторні дії та широко висвітлене врегулювання перетворили цю абстрактну межу на питання рівня керівництва.

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

Цей модуль навчає безпеки хмарного провайдера як набору рішень, а не списку назв продуктів. Ви оцінюватимете модель спільної відповідальності, порівнюватимете налаштування керованого Kubernetes за замовчуванням у AWS, Google Cloud та Azure, діагностуватимете розриви між IAM і RBAC та проєктуватимете засоби контролю мережі й шифрування, що відповідають реальним операціям з кластером. Для прикладів команд цей модуль використовує стандартний скорочений запис KubeDojo alias k=kubectl; усі приклади Kubernetes передбачають Kubernetes 1.35+, якщо функція провайдера не має власної вимоги до версії.

alias k=kubectl
k version --client=true

Межа спільної відповідальності

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

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

┌─────────────────────────────────────────────────────────────┐
│              SHARED RESPONSIBILITY MODEL                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  "Security OF the cloud" vs "Security IN the cloud"        │
│                                                             │
│  ┌──────────────────────┬────────────────────────────────┐ │
│  │   CLOUD PROVIDER     │         YOU (CUSTOMER)         │ │
│  │   RESPONSIBILITY     │         RESPONSIBILITY         │ │
│  ├──────────────────────┼────────────────────────────────┤ │
│  │                      │                                │ │
│  │  Physical security   │  Data                         │ │
│  │  Hardware            │  Identity & access management  │ │
│  │  Network infra       │  Application configuration    │ │
│  │  Hypervisor          │  Network configuration        │ │
│  │  Compute/storage     │  OS patches (IaaS)            │ │
│  │  Global network      │  Firewall/security groups     │ │
│  │                      │  Encryption choices           │ │
│  │                      │  Client-side data integrity   │ │
│  │                      │                                │ │
│  └──────────────────────┴────────────────────────────────┘ │
│                                                             │
│  The boundary shifts based on service type (IaaS/PaaS)     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

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

┌─────────────────────────────────────────────────────────────┐
│              RESPONSIBILITY BY SERVICE MODEL                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│              ON-PREM    IaaS      PaaS      SaaS           │
│              ────────   ────      ────      ────           │
│  Data          YOU      YOU       YOU       YOU            │
│  Application   YOU      YOU       YOU       Provider       │
│  Runtime       YOU      YOU       Provider  Provider       │
│  OS            YOU      YOU       Provider  Provider       │
│  Virtualization YOU     Provider  Provider  Provider       │
│  Hardware      YOU      Provider  Provider  Provider       │
│  Network       YOU      Provider  Provider  Provider       │
│  Physical      YOU      Provider  Provider  Provider       │
│                                                             │
│  More managed = less responsibility, but also less control │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

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

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

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

k auth can-i get pods --all-namespaces
k auth can-i create clusterrolebindings
k get namespaces

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

Налаштування керованого Kubernetes за замовчуванням у провайдерів

Сервіси керованого Kubernetes зменшують недиференційовану операційну роботу, проте їхні налаштування за замовчуванням не однакові. Amazon EKS, Google Kubernetes Engine та Azure Kubernetes Service усі надають керовані площини управління, але вони інтегруються з різними системами ідентичності, операційними системами вузлів, мережевими моделями, додатковими модулями політик та опціями приватного кластера. Хороший інженер з безпеки не запам’ятовує налаштування за замовчуванням як набір дрібниць; він порівнює налаштування за замовчуванням, щоб вирішити, які засоби контролю мають бути явно увімкнені перед тим, як прибудуть робочі навантаження.

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

┌─────────────────────────────────────────────────────────────┐
│              MANAGED KUBERNETES - PROVIDER SCOPE            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  CONTROL PLANE                                              │
│  ├── API server availability and patching                  │
│  ├── etcd availability and backups                         │
│  ├── Controller manager                                    │
│  ├── Scheduler                                             │
│  └── Control plane network security                        │
│                                                             │
│  INFRASTRUCTURE                                             │
│  ├── Physical security of data centers                     │
│  ├── Network backbone                                      │
│  ├── Hardware maintenance                                  │
│  └── Hypervisor security                                   │
│                                                             │
│  COMPLIANCE                                                 │
│  ├── SOC 2 Type II                                         │
│  ├── ISO 27001                                             │
│  └── Various regulatory certifications                     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Сторона, керована замовником, — це місце, де більшість інцидентів Kubernetes стають конкретними. RBAC повідомляє API-серверу, що може робити автентифікована ідентичність. Мережеві політики вирішують, чи може один скомпрометований Pod горизонтально сканувати інший простір імен. Pod Security Standards формують те, що робочі навантаження можуть запитувати в ядра вузла. Контролери допуску, політика образів, обробка секретів, логування та рішення щодо резервного копіювання — усе це залишається рішеннями замовника. Провайдер постачає безпечні будівельні блоки, але він не знає чутливості ваших даних, структури команди чи допустимого рівня інцидентів.

┌─────────────────────────────────────────────────────────────┐
│              MANAGED KUBERNETES - YOUR SCOPE                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  CLUSTER CONFIGURATION                                      │
│  ├── RBAC policies                                         │
│  ├── Network policies                                      │
│  ├── Pod Security Standards                                │
│  ├── Admission controllers                                 │
│  └── Audit policy configuration                            │
│                                                             │
│  WORKLOADS                                                  │
│  ├── Container images                                      │
│  ├── Pod security contexts                                 │
│  ├── Application configuration                             │
│  └── Secrets management                                    │
│                                                             │
│  WORKER NODES (varies by provider)                         │
│  ├── Node OS security                                      │
│  ├── Node group configuration                              │
│  └── Node patching (often automated)                       │
│                                                             │
│  DATA                                                       │
│  ├── Your application data                                 │
│  ├── Encryption key management                             │
│  └── Backup and recovery                                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

Функція безпеки	Amazon EKS	Google GKE	Azure AKS
Точка доступу API-сервера	Публічна за замовчуванням (можна обмежити)	Публічна за замовчуванням (рекомендовано приватні кластери)	Публічна за замовчуванням (доступні приватні кластери)
ОС вузла	Amazon Linux 2023 / Bottlerocket (AL2 — застаріла)	Container-Optimized OS (COS)	Ubuntu / Azure Linux
Ідентичність робочого навантаження	IAM Roles for Service Accounts (IRSA/Pod Identity)	Workload Identity (увімкнено за замовчуванням в Autopilot)	Microsoft Entra Workload ID (раніше Azure AD Workload Identity)
Мережеві політики	Потребують додаткового модуля (напр., Calico або VPC CNI)	Вбудовані, коли увімкнено Dataplane V2 (за замовчуванням в Autopilot; за вибором під час створення на кластерах Standard)	Azure Network Policies або Calico

Ця таблиця — відправна точка, а не вирок. EKS дає сильну інтеграцію з AWS IAM, але команда має обрати налаштування точки доступу, обсяг ролі вузла, додаткові модулі та дизайн ідентичності робочого навантаження. GKE пропонує сильні керовані налаштування за замовчуванням, особливо в Autopilot, проте командам усе одно потрібно переглядати авторизовані мережі, сервісні акаунти та стан політик. AKS природно інтегрується з Microsoft Entra ID та мережею Azure, але готовність до робочого середовища все одно залежить від рішень щодо приватного кластера, засобів контролю пулу вузлів, ідентичності робочого навантаження та застосування політик.

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

Налаштування провайдера за замовчуванням також змінюються з часом, тому базові рівні безпеки слід виражати як бажані властивості, а не як припущення про майстер налаштувань у консолі. «API-сервер має бути приватним або обмеженим затвердженими діапазонами CIDR» є більш надійним, ніж «налаштування точки доступу за замовчуванням є прийнятним». «Кожне робоче навантаження в робочому середовищі має використовувати ідентичність робочого навантаження, а не статичні хмарні ключі» є більш надійним, ніж «ми наслідували приклад застосунку». Базовий рівень, написаний таким чином, переживає зміни інтерфейсу провайдера та оновлення версій кластера.

Реалістична бойова історія виглядає так: платформена команда швидко створює кластер для розробки, залишає увімкненою публічну точку доступу API та зіставляє операційну роль IAM з адміністратором кластера задля зручності. Через кілька місяців автоматизація починає розгортати чутливі тестові дані в той самий кластер, тому що кластер «уже існує». У Kubernetes нічого драматичного не змінилося, але ризик змінився, тому що змінилося призначення кластера. Збій перевірки полягав не в одному неправильному полі; це була відсутність контрольної точки життєвого циклу, коли середовище з низьким рівнем довіри стало середовищем із вищим рівнем довіри.

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

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

Хмарний IAM, Kubernetes RBAC та ідентичність робочого навантаження

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

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

┌─────────────────────────────────────────────────────────────┐
│              IAM CORE CONCEPTS                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  PRINCIPAL         WHO is requesting access?               │
│  ├── Users         Human identities                        │
│  ├── Groups        Collections of users                    │
│  ├── Roles         Assumable identities                    │
│  └── Service Accts Machine identities                      │
│                                                             │
│  ACTION            WHAT are they trying to do?             │
│  ├── Read          Get, List, Describe                     │
│  ├── Write         Create, Update, Delete                  │
│  └── Admin         Full control, IAM changes               │
│                                                             │
│  RESOURCE          WHICH resource is involved?             │
│  ├── Specific      arn:aws:s3:::my-bucket/file.txt        │
│  ├── Pattern       arn:aws:s3:::my-bucket/*               │
│  └── All           * (dangerous!)                          │
│                                                             │
│  CONDITION         UNDER WHAT circumstances?               │
│  ├── Time-based    Only during business hours             │
│  ├── IP-based      Only from corporate network            │
│  └── MFA-required  Only with second factor                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Kubernetes додає другий рівень авторизації, і порядок має значення. Людина може спочатку автентифікуватися в AWS, Google Cloud чи Azure, а потім отримати токен, який приймає API-сервер керованого Kubernetes. Після цього Kubernetes RBAC вирішує, чи може користувач переглядати секрети, створювати деплойменти чи змінювати прив’язки ролей. Хмарний IAM може відчинити вхідні двері, але RBAC вирішує, до яких кімнат відвідувач може зайти, опинившись усередині будівлі.

┌─────────────────────────────────────────────────────────────┐
│              IAM + KUBERNETES INTEGRATION                   │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. CLUSTER ACCESS                                          │
│     Cloud IAM controls who can access the cluster          │
│                                                             │
│     User → Cloud IAM → API Server → Kubernetes RBAC        │
│                                                             │
│     Example (AWS EKS):                                      │
│     - IAM user/role authenticates to AWS                   │
│     - aws-auth ConfigMap maps IAM to K8s groups            │
│     - RBAC authorizes actions in cluster                   │
│                                                             │
│  2. WORKLOAD IDENTITY                                       │
│     Pods can assume cloud IAM roles                        │
│                                                             │
│     Pod → ServiceAccount → Cloud IAM Role → AWS API        │
│                                                             │
│     Example (GKE Workload Identity):                        │
│     - K8s ServiceAccount annotated with GCP SA             │
│     - Pod automatically gets GCP credentials               │
│     - No static credentials needed                         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

На сучасних кластерах EKS записи доступу EKS (accessConfig.authenticationMode) можуть зіставляти суб’єкти IAM із дозволами Kubernetes; ConfigMap aws-auth залишається застарілим шляхом на старіших кластерах.

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

Щоб зрозуміти, чому ідентичність робочого навантаження є критичною, розгляньмо атаку з підміною IAM. Зловмисник експлуатує вразливість Server-Side Request Forgery у Pod’і вебзастосунку. Цей Pod виконується на робочому вузлі, чий профіль інстансу має широкий доступ до сховища об’єктів, бо кілька команд спільно використовують один пул вузлів. Зловмисник дістається до сервісу метаданих, отримує короткотривалі облікові дані для ролі вузла, а потім використовує ці облікові дані поза кластером, щоб читати непов’язані бакети. Початкова вада була в одному застосунку, але радіус ураження визначався хмарним IAM.

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

apiVersion: v1
kind: ServiceAccount
metadata:
  name: invoice-reader
  namespace: payments
  annotations:
    example.com/cloud-role: payments-invoice-readonly

Цей маніфест навмисно не прив’язаний до конкретного провайдера, бо кожна хмара реалізує прив’язку по-різному. EKS може використовувати IAM Roles for Service Accounts або EKS Pod Identity. GKE використовує Workload Identity Federation for GKE. AKS використовує Microsoft Entra Workload ID. Важлива властивість дизайну однакова для всіх трьох: Pod має отримувати короткотривалі облікові дані через довірений обмін ідентичністю, а не через статичний ключ, скопійований у Secret Kubernetes.

Статичні облікові дані	Ідентичність робочого навантаження
Довготривалі секрети	Короткотривалі токени
Зберігаються в кластері	Автоматична ротація
Однакові облікові дані для всіх Pod’ів	Ідентичність на кожен Pod
Ручна ротація	Керується провайдером
Ризик розкриття	Мінімальний радіус ураження

Статичні облікові дані іноді захищають як «прості», але їхня простота оманлива. Ключ, збережений як Secret, може бути прочитаний будь-якою ідентичністю з відповідним дозволом RBAC, скопійований у резервні копії, виведений інструментами налагодження чи залишений після того, як команда змінить власника. Ротація потребує координації між хмарним обліковим записом, Secret’ом Kubernetes, розгортанням деплойменту та записами реагування на інциденти. Ідентичність робочого навантаження теж має складність, але вона переносить цю складність у придатну для аудиту інтеграцію з провайдером замість того, щоб розсіювати довготривалі ключі по стану кластера.

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

k auth can-i get pods -n payments
k auth can-i get secrets -n payments
k auth can-i create rolebindings -n payments

Людський доступ до кластера заслуговує на ту саму перевірку ланцюжка довіри, що й доступ робочого навантаження. В EKS суб’єкт AWS IAM можна зіставити з групами Kubernetes. У GKE ідентичності Google можуть автентифікуватися до кластера, а потім залежати від Kubernetes RBAC. В AKS ідентичності Microsoft Entra можуть інтегруватися з авторизацією Kubernetes. Конкретні назви продуктів відрізняються, але патерн збою є послідовним: хмарна ідентичність надає вхід, Kubernetes RBAC надає повноваження, а слабке розмежування між цими двома створює шляхи ескалації.

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

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

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

Хмарна мережа, шифрування та засоби контролю мультиоренди

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

┌─────────────────────────────────────────────────────────────┐
│              CLOUD NETWORK SECURITY                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  VPC (Virtual Private Cloud)                               │
│  ├── Isolated network space                                │
│  ├── Your own IP address range                             │
│  └── Foundation for other network controls                 │
│                                                             │
│  SUBNETS                                                    │
│  ├── Public subnets  → Internet-facing resources           │
│  ├── Private subnets → Internal resources                  │
│  └── Control plane   → Often in provider-managed subnet    │
│                                                             │
│  SECURITY GROUPS                                            │
│  ├── Stateful firewalls                                    │
│  ├── Allow rules only (implicit deny)                      │
│  └── Applied to instances/ENIs                             │
│                                                             │
│  NETWORK ACLs                                               │
│  ├── Stateless firewalls                                   │
│  ├── Allow and deny rules                                  │
│  └── Applied to subnets                                    │
│                                                             │
│  Best Practice: Private subnets for worker nodes,          │
│  public only for load balancers if needed                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

NetworkPolicy Kubernetes — це засіб контролю рівня кластера, а не заміна хмарної мережі. Хмарні брандмауери зазвичай кращі для грубих меж, як-от «лише діапазони VPN можуть сягати точки доступу API» або «лише балансувальники навантаження можуть сягати портів вузлів». NetworkPolicy краще підходить для меж робочих навантажень, як-от «лише простір імен фронтенду може викликати сервіс оформлення замовлення» або «лише завдання резервного копіювання може сягати сервісу бази даних». Ці два засоби контролю доповнюють один одного, бо вони працюють на різних рівнях абстракції.

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

Шифрування має такий самий нашарований характер. TLS захищає трафік API-сервера та більшість зв’язку «вузол — площина управління». Шифрування сховища захищає диски, знімки, сховища об’єктів та керовані бази даних. Шифрування секретів Kubernetes захищає об’єкти Secret у спокої в etcd, але воно не зупиняє користувача з дозволом get secrets від читання розшифрованих значень через API-сервер. Керування ключами потім вирішує, хто може використовувати, ротувати, перевіряти, вимикати та відновлювати ключі, що захищають ці рівні.

┌─────────────────────────────────────────────────────────────┐
│              ENCRYPTION LAYERS                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ENCRYPTION IN TRANSIT                                      │
│  ├── TLS for API server communication                      │
│  ├── TLS between nodes and control plane                   │
│  ├── TLS for etcd peer communication                       │
│  └── Service mesh for pod-to-pod encryption                │
│                                                             │
│  ENCRYPTION AT REST                                         │
│  ├── EBS/disk encryption (provider-managed keys)           │
│  ├── etcd encryption (Kubernetes secrets)                  │
│  ├── Object storage encryption (S3, GCS)                   │
│  └── Customer-managed keys (CMK) for more control          │
│                                                             │
│  KEY MANAGEMENT                                             │
│  ├── Cloud KMS for key storage                             │
│  ├── Envelope encryption pattern                           │
│  ├── Key rotation policies                                 │
│  └── Audit logging of key usage                            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

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

┌─────────────────────────────────────────────────────────────┐
│              MULTI-TENANCY ISOLATION LEVELS                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  STRONGEST: Separate Cloud Accounts                        │
│  ├── Complete blast radius isolation                       │
│  ├── Separate IAM boundaries                               │
│  ├── Independent billing                                   │
│  └── Use for: Production vs non-prod, different customers  │
│                                                             │
│  STRONG: Separate Clusters                                  │
│  ├── Cluster-level isolation                               │
│  ├── Separate RBAC                                         │
│  ├── No shared control plane                               │
│  └── Use for: Different security levels, teams             │
│                                                             │
│  MODERATE: Namespace Isolation                              │
│  ├── RBAC per namespace                                    │
│  ├── Network policies between namespaces                   │
│  ├── Resource quotas                                       │
│  └── Use for: Different applications, environments         │
│                                                             │
│  WEAK: Same Namespace (not recommended)                     │
│  └── No isolation between workloads                        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

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

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

Для шифрування практикуйте пояснення, від чого саме захищає кожен рівень. Шифрування дисків допомагає з втраченими носіями, знімками та шляхами сховища провайдера. Шифрування секретів допомагає з розкриттям сховища etcd. TLS допомагає з перехопленням трафіку. Логи аудиту KMS допомагають із криміналістичними запитаннями про використання ключа. Жоден із цих засобів контролю не доводить, що Pod із надмірними дозволами не може читати дані через авторизований API, тому висновки щодо шифрування слід завжди поєднувати з висновками щодо ідентичності.

Робочий процес перевірки на основі доказів

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

Почніть зі сторони Kubernetes, бо вона швидка і навчає вас того, як ідентичності поводяться, опинившись біля API-сервера. Команда k auth can-i не є повним аудитом, але вона є хорошим першим зондом на привілеї. Якщо роль розробника може створювати Pod’и в робочому середовищі, перевірте, чи може вона монтувати токени сервісних акаунтів або читати секрети. Якщо роль автоматизації може патчити деплойменти, перевірте, чи може вона також оновлювати прив’язки ролей. Мета — виявити межі ескалації, а не просто перелічити дозволи.

k auth can-i list secrets -n payments
k auth can-i create pods -n payments
k auth can-i patch rolebindings.rbac.authorization.k8s.io -n payments
k get serviceaccounts -n payments

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

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

Докази шифрування мають також відрізняти конфігурацію від доступу. Корисно знати, що шифрування etcd чи шифрування секретів увімкнено, але наступне запитання — хто може читати розшифровані дані через API-сервер. Корисно знати, що диски використовують зашифровані томи, але наступне запитання — хто може створювати знімки, ділитися образами чи використовувати ключі. Засоби контролю безпеки захищають від конкретних шляхів; вони не є магічними мітками, що роблять дані безпечними в кожному стані.

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

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

Робочий процес також має відрізняти докази усталеного стану від доказів інциденту. Докази усталеного стану доводять, що передбачені засоби контролю існують до інциденту. Докази інциденту допомагають тим, хто реагує, визначити, що сталося після того, як засіб контролю вийшов з ладу або був обійдений. Логи аудиту API, логи хмарного IAM, логи KMS, логи балансувальника навантаження та події Kubernetes — усі відповідають на різні запитання. Робочий кластер не має чекати на інцидент, щоб виявити, що один із цих записів так і не було ввімкнено.

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

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

Патерн	Коли його використовувати	Чому це працює	Аспект масштабування
Приватні або обмежені точки доступу API-сервера	Робочі кластери, регульовані навантаження та середовища з високим рівнем довіри	Зменшує досяжність з інтернету ще до того, як перевіряється автентифікація	Потребує приватних виконавців CI, доступу VPN, процедур аварійного доступу та шляхів моніторингу
Ідентичність робочого навантаження на кожну роль застосунку	Будь-який Pod, що викликає хмарні API, як-от сховище, черги, KMS чи бази даних	Замінює статичні секрети та широкі ролі вузлів короткотривалими обмеженими обліковими даними	Потребує стандартів іменування, перевірки політик та очищення життєвого циклу при виведенні застосунків з експлуатації
Окремі хмарні облікові записи для сильної оренди	Різні клієнти, різні регуляторні сфери чи робоче проти неробочого середовища	Створює жорстку межу IAM та білінгу поза площиною управління Kubernetes	Збільшує складність розгортання, мережі, логування та керування витратами
Перевірки доступу на основі доказів	Квартальні перевірки, перевірки готовності до робочого середовища та подальші дії після інциденту	Прив’язує дозволи до виводу команд та конфігурації провайдера замість пам’яті	Потребує автоматизації, щоб збір доказів не став ручним театром

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

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

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

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

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

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

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

Рішення	Вибір для розробки з низьким ризиком	Налаштування для робочого середовища за замовчуванням	Вибір для сильної ізоляції
Точка доступу площини управління	Публічна точка доступу, обмежена довіреними діапазонами CIDR	Приватна точка доступу або жорстко обмежена публічна точка доступу	Приватна точка доступу, досяжна лише з контрольованих мереж
Хмарний доступ робочого навантаження	Без хмарних дозволів або жорстко обмежена роль пісочниці	Ідентичність робочого навантаження на кожен ServiceAccount застосунку	Окремі хмарні облікові записи та ідентичність робочого навантаження на кожного орендаря
Розміщення робочих вузлів	Приватна підмережа, коли практично	Приватна підмережа з контрольованим вихідним трафіком	Виділені пули вузлів в окремих облікових записах чи кластерах
Трафік «Pod — Pod»	Налаштування простору імен за замовчуванням плюс вибіркові політики	NetworkPolicy «default-deny» з явними дозволами	Окремі кластери плюс мережева політика всередині кожного кластера
Шифрування секретів та даних	Шифрування, кероване провайдером, для нечутливих даних	Шифрування секретів та переглянутий доступ до ключів	Ключі, керовані замовником, зі суворим розмежуванням адміністраторів та аудитом
Докази	Ручний контрольний список для тимчасових кластерів	Автоматизований пакет доказів на кожен реліз чи квартал	Безперервний моніторинг конфігурації та незалежна перевірка

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

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

Цей фреймворк також допомагає порівнювати EKS, GKE та AKS без суперечок щодо брендів. Запитайте, як кожен провайдер реалізує потрібну властивість, а потім перегляньте операційну вартість цієї реалізації. EKS може підійти команді, що вже зріла в AWS IAM. GKE Autopilot може зменшити тягар керування вузлами для команд, що приймають його обмеження. AKS може підійти організаціям, стандартизованим на Microsoft Entra ID та мережі Azure. Безпечна відповідь є специфічною для провайдера, але критерії оцінювання є переносними.

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

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

Чи знали ви?

Багато хмарних витоків даних пов’язані з людською помилкою, і повторюваним патерном зазвичай є неправильно налаштований доступ або відкрите сховище, а не кінематографічний ланцюжок експлойтів.
Ідентичність робочого навантаження (Workload Identity) усуває потребу в статичних хмарних облікових даних у багатьох дизайнах Pod’ів. GKE Workload Identity, EKS IAM Roles for Service Accounts чи Pod Identity та AKS Workload Identity — усі реалізують цей патерн зі специфічними для провайдера деталями.
Модель спільної відповідальності була популяризована AWS і тепер є стандартом серед основних хмарних провайдерів, але кожен сервіс зміщує межу по-різному, бо IaaS, PaaS, SaaS та керований Kubernetes відкривають різні засоби контролю.
Приватні кластери дедалі більше стають нормою для робочого Kubernetes, бо приватна точка доступу API усуває широку досяжність з інтернету, але вони також потребують запланованого доступу для операторів, CI/CD, моніторингу та аварійного реагування.

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

Помилка	Чому це трапляється	Як це виправити
Припущення, що хмарний провайдер захищає все	Керовані сервіси приховують роботу площини управління, тож команди забувають, що вони все одно володіють конфігурацією ідентичності, даних, робочого навантаження та мережі	Підтримуйте карту відповідальності, яка називає засоби контролю, що належать провайдеру й замовнику, з доказами для кожного з них
Використання статичних облікових даних для Pod’ів	Статичні ключі легко створювати, і вони працюють у різних провайдерів, але вони залишаються в Secret’ах, резервних копіях, логах та машинах розробників	Використовуйте ідентичність робочого навантаження з короткотривалими обмеженими обліковими даними та видаліть довготривалі хмарні ключі з кластера
Залишення непоміченою публічної точки доступу API-сервера	Створення кластера за замовчуванням часто оптимізоване для легкого доступу під час налаштування, а не для обмежень видимості робочого середовища	Використовуйте приватні точки доступу або обмежуйте публічні затвердженими мережами, потім задокументуйте шляхи доступу оператора та CI/CD
Надання надмірно дозвільних політик IAM ролям вузлів	Спільні пули вузлів сприймаються як рівень інфраструктури, тож команди прикріплюють широкі політики один раз для багатьох застосунків	Перенесіть дозволи на ідентичності кожного робочого навантаження та тримайте ролі вузлів зосередженими на операціях вузла
Увімкнення шифрування etcd, але ігнорування RBAC	Шифрування в спокої звучить як завершене, проте Kubernetes розшифровує значення Secret’ів для авторизованих читачів API	Поєднуйте шифрування з RBAC найменших привілеїв, логуванням аудиту та зовнішньою ротацією секретів, де це доречно
Ставлення до просторів імен як до сильних меж орендарів	Простори імен дешеві та звичні, але вони спільно використовують площину управління, інфраструктуру вузлів та багато систем політик	Використовуйте окремі кластери чи хмарні облікові записи, коли орендарі представляють клієнтів, різні рівні довіри чи регульовані дані
Забування про специфічну для провайдера поведінку мережевих політик	Той самий маніфест Kubernetes може поводитися по-різному, якщо обраний CNI чи керований режим не застосовує політики	Перевірте режим мережі провайдера, встановіть потрібні додаткові модулі та протестуйте шляхи заборони й дозволу перед робочим середовищем

Тест

Запитання 1: Ваша команда переходить із самостійно керованого Kubernetes на керований сервіс і перестає відстежувати патчинг API-сервера. Під час того самого переходу вона залишає широкі налаштування RBAC та публічної точки доступу незмінними. Як вам слід оцінити межу спільної відповідальності?

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

Запитання 2: Під час перевірки безпеки ви виявляєте, що команда розробників зберігає ключі доступу AWS як Secret'и Kubernetes, щоб Pod'и могли читати бакет сховища об'єктів. Ключі були створені 18 місяців тому і ніколи не ротувалися. Які ризики це створює і що має замінити цей підхід?

Статичні ключі створюють постійний доступ, який може пережити робоче навантаження чи команду, що його створила. Вони можуть витекти через помилки Kubernetes RBAC, резервні копії etcd, логи застосунку, вивід налагодження чи локальні копії розробників. Безпечніша заміна — це ідентичність робочого навантаження, як-от EKS IRSA чи Pod Identity, з роллю, обмеженою точним бакетом та префіксом, які потрібні Pod’у. Цей дизайн використовує короткотривалі облікові дані та зменшує радіус ураження, якщо Pod скомпрометовано.

Запитання 3: Ваша організація використовує EKS із публічною точкою доступу API-сервера, а консультант рекомендує приватну точку доступу. Яку загрозу це пом'якшує і які операційні зміни потрібні?

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

Запитання 4: Мультиорендна SaaS-платформа виконує всі робочі навантаження клієнтів в одному кластері Kubernetes, використовуючи ізоляцію простором імен. Аудит безпеки каже, що цього недостатньо для цінних орендарів. Як ви діагностуєте проблему ізоляції та обираєте альтернативу?

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

Запитання 5: Шифрування в спокої увімкнено для сховища Secret'ів кластера, але колега каже, що облікові дані застосунку тепер у безпеці. Яке припущення вони роблять, що може бути хибним?

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

Запитання 6: Команда порівнює EKS, GKE та AKS для робочої платформи, але обговорення перетворюється на суперечку про переваги бренду. Які критерії безпеки мають натомість керувати порівнянням?

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

Запитання 7: Огляд інциденту виявляє, що скомпрометований Pod використав широку роль вузла, щоб читати непов'язані об'єкти сховища. Які засоби контролю IAM та Kubernetes ви впровадили б першими і чому?

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

Практична вправа: Картування відповідальності та перевірка доказів

У цій вправі ви побудуєте легку карту відповідальності для розгортання керованого Kubernetes та з’єднаєте кожну відповідальність із доказами, які ви могли б зібрати. Ви можете виконати вправу з будь-яким кластером Kubernetes 1.35+, включно з локальним тестовим кластером, бо мета — практикувати міркування перед специфічною для провайдера автоматизацією. Якщо у вас є доступ до EKS, GKE чи AKS, додайте відповідні докази провайдера в стовпці нотаток.

Сценарій

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

Завдання безпеки	Провайдер чи замовник?
Патчинг API-сервера Kubernetes	?
Створення ролей RBAC для розробників	?
Увімкнення шифрування etcd	?
Захист фізичного доступу до дата-центру	?
Налаштування мережевих політик	?
Патчинг ОС робочого вузла	?
Керування секретами вашого застосунку	?
Забезпечення високої доступності API-сервера	?

Завдання

Класифікуйте кожне завдання в таблиці як таке, що належить провайдеру, замовнику чи є спільним, та напишіть одне речення, що пояснює власника.
Запустіть перевірки k auth can-i для доступу в стилі розробника в неробочому просторі імен та запишіть, чи може ця ідентичність читати Pod’и, читати секрети та створювати прив’язки ролей.
Визначте одне робоче навантаження, якому потрібен доступ до хмарного API, та запишіть передбачене зіставлення ідентичності робочого навантаження простими словами.
Оберіть позицію видимості API-сервера для робочого середовища та задокументуйте шляхи доступу оператора, CI/CD та аварійного доступу, яких вона потребує.
Виберіть правильний рівень ізоляції для робочих, staging та специфічних для клієнтів навантажень, використовуючи модель мультиоренди з цього модуля.
Створіть остаточний контрольний список доказів із принаймні одним виводом команди Kubernetes та одним елементом конфігурації провайдера для кожного основного засобу контролю.

Запропоновані команди

k create namespace payments-review
k auth can-i get pods -n payments-review
k auth can-i get secrets -n payments-review
k auth can-i create rolebindings -n payments-review
k get serviceaccounts -n payments-review
k get networkpolicies -A

Посібник із розв’язання

Відповідь до таблиці відповідальності

Завдання безпеки	Відповідальність
Патчинг API-сервера Kubernetes	Провайдер — він керує площиною управління
Створення ролей RBAC для розробників	Замовник — ви налаштовуєте доступ
Увімкнення шифрування etcd	Замовник (зазвичай) — ви вирішуєте налаштування шифрування
Захист фізичного доступу до дата-центру	Провайдер — фізична безпека
Налаштування мережевих політик	Замовник — ви налаштовуєте мережу робочого навантаження
Патчинг ОС робочого вузла	Замовник (але часто автоматизовано)
Керування секретами вашого застосунку	Замовник — це дані вашого застосунку
Забезпечення високої доступності API-сервера	Провайдер — доступність площини управління

Відповідь до контрольного списку доказів

Сильний контрольний список включає докази Kubernetes та докази провайдера для кожної межі. Для RBAC включіть вивід k auth can-i для репрезентативних людських та автоматизованих ідентичностей. Для ідентичності робочого навантаження включіть назву ServiceAccount, простір імен, назву хмарної ролі, дозволені ресурси та поведінку ротації. Для мережевої позиції включіть налаштування точки доступу API, розміщення підмереж, правила брандмауера чи групи безпеки та докази застосування NetworkPolicy. Для шифрування включіть налаштування шифрування провайдера, володіння ключами, дозволи на читання Secret’ів та покриття логуванням аудиту.

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

Кожне перелічене завдання безпеки має власника та джерело доказів.
Доступ розробника протестовано за допомогою k auth can-i, а не вгадано з назв груп.
Принаймні одне зіставлення ідентичності робочого навантаження замінює дизайн зі статичними обліковими даними.
Видимість API-сервера обґрунтована операційними шляхами доступу.
Рішення щодо оренди відповідає чутливості даних та розділенню клієнтів.
Остаточний контрольний список включає докази як Kubernetes, так і хмарного провайдера.

Підсумкова таблиця

Концепція	Ключові тези
Спільна відповідальність	Провайдер захищає «саму хмару», ви захищаєте «всередині хмари»
Керований Kubernetes	Провайдер обробляє площину управління, ви обробляєте робочі навантаження
IAM	Основа для всього хмарного доступу, інтегрується з Kubernetes
Ідентичність робочого навантаження	Усуває статичні облікові дані для Pod’ів
Мережева безпека	Приватні підмережі, групи безпеки, шифрування в дорозі
Мультиоренда	Сила ізоляції: обліковий запис > кластер > простір імен

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

Джерела

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

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