Модуль 6.3: Workload Identity та безпека в GKE

Складність: [MEDIUM] | Час на виконання: 2.5 год | Передумови: Модуль 6.1 (Архітектура GKE)

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

У січні 2024 року логістична компанія виявила, що кожен под у їхньому кластері GKE мав доступ на читання та запис до всіх бакетів Cloud Storage та топіків Pub/Sub у їхньому проєкті. Молодший розробник запустив под для відлагодження, який випадково викачав усі повідомлення з продуктової черги замовлень (адреси, телефони, імена 2.1 мільйона клієнтів) і записав їх у свій особистий бакет. Причина: при створенні кластера сервісному акаунту вузлів надали роль Editor, і кожен под успадкував ці права. Компанія заплатила $890 000 штрафів та юридичних витрат. Виправлення — налаштування Workload Identity — зайняло лише два дні.

Ця історія ілюструє найнебезпечніше налаштування за замовчуванням у GKE: без Workload Identity всі поди на сервері ділять одну й ту саму ідентичність хмари. Якщо зловмисник зламає один под — він отримає доступ до всього, що бачить сервер. Workload Identity вирішує це, прив’язуючи конкретний ServiceAccount Kubernetes до конкретного сервісного акаунта Google.

У цьому модулі ви навчитеся налаштовувати Workload Identity, дізнаєтеся, як Binary Authorization гарантує запуск тільки перевірених образів, як Shielded Nodes захищають залізо кластера та як підключати Secret Manager прямо в поди без використання стандартних секретів Kubernetes.

Проблема: Спільна ідентичність вузла

Без Workload Identity поди використовують права віртуальної машини, на якій вони запущені.

Pod A (сайт): не потребує доступу до хмари.
Pod B (база): потребує доступу до бакета.
РЕЗУЛЬТАТ: Обидва поди мають права сервера (напр. Editor).

Це порушує принцип найменших привілеїв. Workload Identity дає кожному поду свій “паспорт” із мінімальними правами.

Workload Identity Federation: Як це працює

Це золотий стандарт безпеки в GCP.

Кроки налаштування:

GCP Service Account (GSA): Створюєте акаунт у хмарі з потрібними правами (напр. тільки читання бакета).
Kubernetes Service Account (KSA): Створюєте акаунт у кластері.
Зв’язок (Binding): Кажете Google Cloud: “Я дозволяю цьому KSA в цьому кластері видавати себе за цей GSA”.
Анотація: Додаєте спеціальну мітку на KSA у Kubernetes.

Результат: Ваш код просто викликає стандартні бібліотеки Google, і вони магічним чином отримують потрібні ключі без жодних JSON-файлів у секретах.

Binary Authorization: Захист ланцюжка поставок

Як гарантувати, що в продуктовому кластері працює саме той код, який пройшов тести, а не образ, який розробник зібрав у себе на ноутбуці?

Binary Authorization — це admission-контролер, який перевіряє “підпис” образу перед запуском.

Attestor: Сервіс, який ставить цифрову печатку (напр. “образ просканований на віруси” або “тести пройшли успішно”).
Policy: Правило кластера: “не запускай нічого, що не має печатки від нашого CI/CD”.

Shielded та Confidential Nodes

Shielded Nodes: Захищають від атак на рівні завантаження (rootkits). Google перевіряє підпис ядра Linux при кожному старті сервера. (Ввімкнено за замовчуванням).
Confidential Nodes: Шифрують дані прямо в оперативній пам’яті сервера. Навіть якщо хтось отримає фізичний доступ до заліза — він не зможе прочитати дані з RAM.

Secret Manager CSI Driver

Стандартні секрети Kubernetes зберігаються в etcd і не мають версійності. Secret Manager CSI Driver дозволяє монтувати секрети з хмарного сховища Google прямо у файл всередині пода.

Секрети не зберігаються в самому Kubernetes.
Є версійність та автоматична ротація.
Аудит логів показує, який саме под і коли звертався до пароля.

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

Помилка	Чому це стається	Як виправити
Роль Editor для вузлів	Default налаштування в багатьох гайдах	Створюйте вузли з мінімальною роллю (напр. `monitoring.viewer` та `logging.logWriter`)
Забута анотація KSA	Документація містить багато кроків	Завжди перевіряйте через `gcloud auth list` всередині пода, під ким він працює
Ключі SA в секретах K8s	”Так звичніше”	Це антипатерн. Видаліть JSON-ключі та перейдіть на Workload Identity
Enforce режим BinAuthz одразу	Бажання бути в безпеці негайно	Починайте з режиму `DRYRUN_AUDIT_LOG_ONLY`, щоб не “покласти” деплой всього кластера

Тест

1. Чому Workload Identity кращий за використання JSON-файлів ключів?

JSON-ключі живуть 10 років, їх легко забути в Git або логах. Workload Identity використовує короткочасні токени (діють 1 годину), які неможливо вкрасти надовго, і вони ніколи не зберігаються у файлах.

2. Чи захищає Binary Authorization від використання вразливих образів (CVE)?

Так, якщо ви налаштуєте конвеєр так, щоб печатка (attestation) ставилася тільки після успішного сканування вразливостей. Сам сервіс лише перевіряє наявність підпису згідно з вашою політикою.

Практична вправа: Доступ без паролів

Увімкніть Workload Identity на вашому кластері.
Створіть GSA з роллю roles/pubsub.publisher.
Налаштуйте зв’язок між KSA my-app та цим GSA.
Запустіть под, зайдіть у нього і спробуйте надіслати повідомлення в Pub/Sub. Переконайтеся, що ви не використовували жодних паролів.
Увімкніть Security Posture Dashboard і перевірте, чи є у вас поди, що працюють від імені root.

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

Ви захистили кластер, тепер час розібратися з даними. Переходьте до Модуля 6.4: Сховища в GKE — ви навчитеся використовувати Persistent Disks, Filestore для спільних файлів та налаштовувати Backup for GKE для захисту вашої інформації.