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

такс, тут знайшли вразливості в Ingress nginx, ніколи такого не було і от знову.

https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities

https://www.wiz.io/crying-out-cloud/ingress-nightmare-how-a-single-request-could-take-over-your-k8s-cluster

Привіт, давно не було постів, згадав, що давно хотів написати про одне рішення, яке довелось імплементувати. Можливо, комусь буде цікаво, а хтось візьме собі до уваги.
Загалом одразу визначу контекст: будемо говорити за Google Cloud і його конкретний сервіс, а саме Private Service Connect. Вирішив написати пост, бо такий солюшн непопулярний, а ніякого rocket science в ньому немає.

Так от, яка проблема? Часто нам потрібно організувати доступ до ресурсів, які знаходяться за межами нашої VPC, але ганяти трафік через публічну мережу ніхто не хоче(і не треба так!;)), тож більшість рішень, коли нашим ресурсам у VPC потрібен доступ до ресурсів іншої VPC, базуються на VPC peering, Shared VPC і інших похідних об'єднань VPC. Однак доступ до всієї VPC нам, скоріш за все, не потрібен, і за найкращими сек'юрними практиками ми маємо обмежувати доступ до інших ресурсів(які не приймають участі в нашому сценарії), але так само часто на це забивають, і в підсумку у вас виходить дві VPC, де можна ганяти трафік як заманеться. А і це я ще нічого не кажу про overlapping VPC CIDRs...

Тепер трошки про наш сценарій: у нас був основний проект, в якому було декілька баз, які були розгорнуті в GKE Kubernetes кластері, а також проект по аналізу даних, зона дата інженерів — це були різні GCP проекти, відповідно різні VPC. Основний проект був доволі великий, з купою ресурсів, і хотілось надати доступ виключно до баз і, звичайно без пірингу, бо навіщо нам пірити мережі задля декількох баз? Звучить нераціонально.

Тож я почав шукати рішення, після огляду різноманітних варіантів об'єднань VPC натрапив на Private Service Connect і подумав, що це може бути саме те, що потрібно. Загалом архітектура сервісу доволі проста: у вас є Publisher(той, хто "надає" ендпоінт) і Consumer(відповідно той, хто буде до цього ендпоінта підключатись).

Аби заекспоузити ендпоінт БД з K8s ми створили NLB, таким чином отримавши приватний айпішник в межах VPC. Тут варто зауважити, що в Private Service Connect є інтеграція з GKE, і тому Publisher можна легко створити за допомогою ресурсу в k8s. Окремо також потрібно створити сабнет для Private Service Connect — ця конфігурація залишилась в тераформі.

apiVersion: networking.gke.io/v1
kind: ServiceAttachment
metadata:
  name: test-db
  namespace: pg
spec:
  connectionPreference: ACCEPT_AUTOMATIC
  natSubnets:
    - stg-test-db-psc
  proxyProtocol: false
  resourceRef:
    kind: Service
    name: test-db-psc

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

Cloudflare пишуть, як відбили найбільшу (задокументовану) DDOS атаку. Пост не новий, проте для тих, хто пропустив буде цікаво. Вони також приділили трохи часу на опис типів атак. Загалом раджу час від часу заглядати в блог Cloudflare, де може бути щось цікавеньке.

https://blog.cloudflare.com/defending-the-internet-how-cloudflare-blocked-a-monumental-7-3-tbps-ddos/

Прочитав невеличку(196с.) книжечку по безпеці і моніторингу куба, доволі вичерпно.

Багато популярних практик описується, як от — сканування імеджів, тестування, RBAC, service mesh, і різного роду шифрування. Проте також є серйозні практики, які більшість загалом не використовують(або більшість в моїй бульбашці), як-от захист від атак/пробиття контуру кластера.

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

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

P.S. ще можна забрати безкоштовно;)

p.s.s. майже немає реклами calico🐯;)

https://flaws.cloud/

Один AWS certified товариш підкинув класний сайт, де можна краще ознайомитись з security проблемами, пов'язаними з AWS. Великий плюс у тому, що можна самостійно шукати вразливості — сайт доволі інтерактивний, а не просто набір сухих статей про безпеку.

Наприклад, на першому рівні вам потрібно буде через вразливість S3 бакета знайти посилання на другий рівень — what a fun!

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

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

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

https://www.figma.com/blog/migrating-onto-kubernetes/

Доволі корисна табличка, якщо перед вами стоїть вибір Ingress контролера(Проте пам'ятаймо, що Куб вже створив наслідника інгреса і поступово все туди буде переїжджати). Пам'ятаю ми якось на це купу сторіпоінтів витратили... хоча потрібно було просто сісти проаналізувати/поспілкуватись з досвідченими людьми.

Дуже хотів по мотивам останніх подій запостити — https://www.cloudflare.com/learning/dns/what-is-dns/
Я думаю, більшість тут все ж в курсі за DNS і як він працює, але стаття хороша для "рефрешу" знань:)

https://blog.cloudflare.com/18-november-2025-outage/

Навіть не dns