Павло Селіванов, архітектор рішень Southbridge та викладач Сльорма, виступив з доповіддю на DevOpsConf 2019. Ця доповідь є частиною однієї з тем поглибленого курсу з Kubernetes «Слерм Мега».
проходить у Москві 18-20 листопада.
- Москва, 22-24 листопада.
доступний завжди.
Під катом – розшифровка доповіді.
Доброго дня, колеги та співчуваючі. Сьогодні я розповідатиму про безпеку.
Я бачу, що у залі сьогодні є багато безпечників. Я заздалегідь перед вами вибачаюсь, якщо терміни зі світу безпеки я використовуватиму не зовсім так, як у вас заведено.
Так вийшло, що десь півроку тому мені до рук потрапив один публічний кластер Kubernetes. Громадський — означає, що є n-ное кількість namespaces, у цих неймспейсах є users, ізольовані у своєму неймспейсе. Всі ці користувачі належать різним підприємствам. Ну і передбачалося, що цей кластер потрібно використовувати як CDN. Тобто вам дають кластер, дають туди користувача, ви туди приходите у свій namespace, деплоїть свої фронти.
Моїй попередній компанії спробували таку послугу продати. І мене попросили потикати кластер на предмет — підходить чи не підходить таке рішення.
Прийшов у цей кластер. Мені дали обмежені права, обмежений namespace. Там хлопці розуміли, що таке безпека. Вони читали, що таке Role-based access control (RBAC) у Кубернетеса і вони його закрутили так, що я не міг запускати поди окремо від деплойментів. Не пам'ятаю завдання, яке я намагався вирішити, запускаючи під без деплойменту, але мені дуже хотілося запустити просто під. Я вирішив на удачу подивитися, які права в кластері є, що я можу, що не можу, що вони там накрутили. Заодно розповім, що вони в RBAC налаштовано неправильно.
Так вийшло, що через дві хвилини я отримав адміна до їхнього кластера, подивився у всі сусідні namespaces, побачив там запущені продакшн фронти компаній, які вже купили послугу та задеплоїлися. Я ледве зупинив себе, щоб не прийти до когось у фронт і на головну сторінку не помістити якесь матюки.
Я розповім на прикладах, як це зробив і як від цього треба захищатися.
Але для початку уявлюся. Мене звуть Павло Селіванов. Я архітектор компанії Southbridge. Я розуміюсь на Kubernetes, DevOps і всяких модних штуках. Ми з інженерами Southbridge все будуємо, а я консультую.
Крім основної діяльності, ми ще недавно запустили проекти, які називаються Слерми. Ми наше вміння працювати з Kubernetes намагаємося трохи привнести до маси, навчити інших людей також працювати з К8s.
Про що я сьогодні розповідатиму. Тема доповіді очевидна про безпеку кластера Kubernetes. Але одразу хочу сказати, що ця тема дуже велика — і тому я одразу хочу обговорити, про що я точно розповідати не буду. Я не розповідатиму про заїжджені терміни, які в інтернеті вже сто разів перемусолені. Будь-які RBAC та сертифікати.
Я розповідатиму про те, що у мене та у моїх колег болить від безпеки в кластері Kubernetes. Ми ці проблеми бачимо і у провайдерів, які надають кластери Kubernetes, і клієнтів, які до нас приходять. І навіть клієнти, які приходять до нас від інших консалтингових адмінських компаній. Тобто масштаб трагедії дуже великий насправді.
Буквально три пункти, про які я сьогодні розповім:
- Права користувачів vs права pod'ів. Права користувачів і права подов - це не те саме.
- Збір інформації про кластер. Покажу, що з кластера можна збирати всю інформацію, яка знадобиться, не маючи особливих прав у цьому кластері.
- DoS-атака на кластер. Якщо ми не зможемо збирати інформацію, ми зможемо покласти кластер у будь-якому випадку. Я розповім про DoS-атаки на керуючі елементи кластера.
Ще одна спільна річ, про яку я згадаю — на чому я все це тестував, на чому точно можу сказати, що все це працює.
За основу беремо встановлення кластера Kubernetes за допомогою Kubespray. Якщо хтось не знає, це набір ролей для Ansible. Ми у роботі його постійно використовуємо. Хороший тим, що можна накотити куди завгодно - і на залізки можна накотити, і кудись у хмару. Один спосіб встановлення підходить у принципі для всього.
У цьому кластері я матиму Kubernetes v1.14.5. Весь кластер Куба, який ми розглядатимемо, поділений на неймспейси, кожен неймспейс належить окремій команді, кожен неймспейс має доступ у членів цієї команди. У різні неймспейси вони ходити не можуть, тільки до свого. Але є якась адмінська облік, яка має права на весь кластер.
Я обіцяв, що перше ми матимемо — отримання адмінських прав на кластер. Нам потрібний спеціально підготовлений pod, який ламатиме кластер Kubernetes. Все, що нам потрібно зробити, це застосувати його до кластера Кубернетес.
kubectl apply -f pod.yamlЦей pod у нас приїде на один із майстрів кластера Kubernetes. І кластер нам після цього радісно поверне файл, який називається admin.conf. У Кубі в цьому файлі зберігаються всі сертифікати адміну, а заразом налаштований кластер API. Ось так просто можна отримати адмінський доступ, гадаю, до 98% кластерів Kubernetes.
Повторюся, цей pod зробив один розробник у вашому кластері, який має доступ деплоїти свої пропозиції в один маленький namespace, він весь затиснутий RBAC. Прав у нього ніяких не було. Проте сертифікат повернувся.
А тепер про спеціально підготовлений под. Запускаємо на будь-якому образі. Наприклад візьмемо debian:jessie.
У нас є така штука:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Що таке toleration? Майстри в кластері Кубернетеса зазвичай позначені штукою, яка називається taint («зараза» англійською). І суть цієї «зарази» — вона каже, що на майстрові ноди не можна призначати поди. Але ніхто не заважає в будь-якому випадку вказати, що він толерантний до «зарази». Секція Toleration якраз і каже, що якщо на якійсь ноді стоїть NoSchedule, то наш під такий зараз толерантний — і жодних проблем.
Далі, ми говоримо, що наш під не просто толерантний, а й хоче спеціально потрапляти на майстра. Тому що на майстрах є найсмачніше, що нам потрібно — всі сертифікати. Тому ми говоримо nodeSelector — і ми маємо стандартний лейбл на майстрах, який дозволяє вибрати з усіх нод кластера саме ті ноди, які є майстрами.
Ось із такими двома секціями під точно приїде на майстер. І йому дозволять там жити.
Але просто приїхати на майстер нам замало. Це нам нічого не дасть. Тому далі ми маємо такі дві речі:
hostNetwork: true
hostPID: true Ми вказуємо, що наш під, який ми запускаємо, буде жити в неймспейсі ядра, в неймспейсі network і в PID неймспейсі. Як тільки запуститься на майстрі, він зможе бачити всі справжні, живі інтерфейси цієї ноди, прослуховувати весь трафік і бачити PID всіх процесів.
Далі справа за малим. Берете etcd і читаєте що хочете.
Найцікавіше — це можливість Kubernetes, яка там за замовчуванням є.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host І суть її в тому, що ми можемо в поді, який ми запускаємо, навіть без прав на цей кластер, сказати, що хочемо створити volume типу hostPath. Отже взяти шлях із хоста, на якому ми запустимося — і взяти його як volume. І далі його називаємо name: host. Весь цей hostPath ми монтуємо всередину пода. У цьому прикладі директорію /host.
Ще раз повторюся. Ми сказали поду приїжджати на майстер, отримувати туди hostNetwork і hostPID - і весь root майстра вмонтувати всередину цього пода.
Ви розумієте, що в дебіані у нас запущений bash, і цей bash працює під рутом. Тобто ми тільки що отримали рута на майстер, при цьому не маючи якихось прав у кластері Kubernetes.
Далі все завдання — зайти в директорію /host /etc/kubernetes/pki, якщо не помиляюся, забрати там всі майстрові сертифікати кластера і, відповідно, стати адміном кластера.
Якщо так подивитися, це одні з найнебезпечніших прав у подах - незважаючи на те, які права є у користувача:
Якщо у мене є права запустити під в якомусь неймспейсі кластера, то у цього пода ці права є за замовчуванням. Я можу запускати привілейовані поди, а це взагалі всі права практично рут на ноду.
Моє улюблене – Root user. А Кубернетес має таку опцію Run As Non-Root. Це такий захист від хакера. Знаєте, що таке "молдавський вірус"? Якщо ви раптом хакер і прийшли в мій кластер Кубернетес, то ми, бідні адміністратори, просимо: «Вкажіть, будь ласка, у своїх подах, якими ви хакатимете мій кластер, run as non-root. А то так вийде, що ви запустите процес у своєму поді під рутом, і вам дуже просто мене хакнути. Захиститеся, будь ласка, від себе самі».
Host path volume — мій погляд, найшвидший спосіб отримати бажаний результат від кластера Кубернетеса.
Але що з цим робити?
Думки, які мають приходити будь-якому нормальному адміністратору, який стикається з Кубернетесом: «Ага, я ж казав, Кубернетес не працює. У ньому дірки. І весь Куб фігня». Насправді є така штука, як документація, а якщо туди подивитися, то там є розділ .
Це такий yaml-об'єкт — ми його можемо створювати в кластері Кубернетес, який контролює аспекти безпеки саме в описі подів. Тобто фактично він контролює ті права на використання будь-яких hostNetwork, hostPID, певних типів volume, які є в подах при запуску. За допомогою Pod Security Policy це можна описати.
Найцікавіше в Pod Security Policy, що в кластері Кубернетеса у всіх установників PSP не просто не описані, вони просто за замовчуванням вимкнені. Pod Security Policy вмикається за допомогою admission plugin.
Окей, в кластер задеплоєм Pod Security Policy, скажемо, що у нас є службові деякі поди в неймспейсі, до якого мають доступ тільки адміни. Скажімо, у решті поди мають обмежені права. Тому що, швидше за все, розробникам не потрібно запускати у вашому кластері привілейовані поди.
І в нас начебто все добре. І наш кластер Кубернетес не можна зламати за дві хвилини.
Є проблема. Швидше за все, якщо у вас є кластер Кубернетес, то у вашому кластері встановлено моніторинг. Я навіть беруся передбачити, що якщо у вашому кластері є моніторинг, він називається Prometheus.
Те, що я зараз розповім, буде валідним і для Prometheus-оператора, і для Prometheus, поставленого в чистому вигляді. Питання в тому, що якщо я в кластер не можу так швидко адмініструвати, то це означає, що мені потрібно більше шукати. А шукати я можу за допомогою моніторингу.
Ймовірно, всі читали ті самі статті на Хабре, і моніторинг знаходиться в неймспейсі monitoring. Helm chart у всіх називається приблизно однаково. Я припускаю, що якщо ви зробите helm install stable/prometheus, то ви отримуєте приблизно однакові назви. І навіть швидше за все DNS-ім'я у вашому кластері мені вгадувати не доведеться. Тому що воно є стандартним.
Далі у нас є якийсь dev ns, в ньому можна запустити якийсь під. І далі з цього поду дуже легко зробити так:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics – це один з експортерів прометеуса, який збирає метрики з API самого Kubernetes. Там дуже багато даних, що запущено у вас у кластері, яке воно, які у вас із ним є проблеми.
Як простий приклад:
kube_pod_container_info{namespace="kube-system",pod="kube-apiserver-k8s-1",container="kube-apiserver",image=
"gcr.io/google-containers/kube-apiserver:v1.14.5"
,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1
Зробивши простий запит curl з непривілейованого пода, можна отримати таку інформацію. Якщо ви не знаєте, в якій версії Кубернетес ви запущені, він легко вам розповість.
А найцікавіше, що окрім того, що ви звертаєтесь до kube-state-metrics, ви можете з тим самим успіхом звернутися і до самого Prometheus безпосередньо. Ви можете зібрати звідти метрику. Ви навіть можете збудувати звідти метрики. Навіть теоретично ви можете побудувати такий запит із кластера в Prometheus, який його просто вимкне. І у вас моніторинг взагалі перестане від кластера працювати.
І тут уже постає питання, чи моніторить якийсь зовнішній моніторинг ваш моніторинг. Щойно я отримав можливість діяти в кластері Кубернетес взагалі без наслідків для себе. Ви навіть не дізнаєтесь, що я там дію, тому що моніторингу вже немає.
Так само, як із PSP, виникає відчуття, ніби проблема в тому, що всі ці модні технології — Kubernetes, Prometheus — вони просто не працюють і сповнені дірок. Насправді ні.
Є така штука - .
Якщо ви нормальний адмін, то, швидше за все, про Network Policy ви знаєте, що це черговий yaml, яких у кластері і так дофіга. І Network Policies якісь точно не потрібні. А якщо навіть ви і прочитали, що таке Network Policy, що це yaml-файєрвол Кубернетеса, він дозволяє обмежувати права доступу між неймспейсами, між подами, то ви вже точно вирішили, що фаєрвол у форматі yaml у Кубернетесі на чергових абстракціях… Не-не . Це точно не потрібне.
Навіть якщо у вас фахівцям з безпеки не розповіли, що за допомогою вашого Кубернетеса можна будувати дуже легко і просто фаєрвол, причому дуже гранульований. Якщо вони ще цього не знають і вас не смикають: «Ну дайте, дайте…» То в будь-якому випадку Network Policy вам потрібно, щоб закривати доступ до деяких службових місць, які можна з вашого кластера посмикати, не маючи жодної авторизації.
Як у прикладі, який я наводив, можна посмикати kube state metrics з будь-якого неймспейсу в кластері Кубернетес, не маючи на це жодних прав. Network policies закрили доступ з решти неймспейсів в неймспейс моніторингу і як би все: немає доступу, немає проблем. У всіх чартах, які є, і стандартного прометеуса, і того прометеуса, який в операторі, там просто в хелму values є опція просто включити network policies для них. Потрібно просто увімкнути, і вони будуть працювати.
Є тут, правда, одна проблема. Будучи нормальним бородатим адміном, ви швидше за все вирішили, що network policies не потрібні. І почитавши будь-які статті на ресурсах типу Хабра, ви вирішили, що flannel особливо з режимом host-gateway - це найкраще, що ви можете вибрати.
Що робити?
Ви можете спробувати передеплоїти мережеве рішення, яке стоїть у вас у кластері Кубернетес, спробувати замінити щось більш функціональне. На те саме Calico, наприклад. Але відразу хочу сказати, завдання змінити мережне рішення в робочому кластері Кубернетес — досить нетривіальне. Я її двічі вирішував (обидва рази, щоправда, теоретично), але ми навіть на Слермах показували, як це зробити. Для наших учнів ми показували, як змінити мережне рішення у кластері Кубернетес. У принципі, можете спробувати зробити так, щоб на продакшн-кластері даунтайму не було. Але мабуть у вас нічого не вийде.
І проблема справді вирішується дуже просто. У кластері є сертифікати, і ви знаєте, що сертифікати у вас за рік протухнуть. Ну, і зазвичай нормальне рішення із сертифікатами в кластері — а чого ми паритимемося, ми поруч новий кластер піднімемо, у старому нехай протухне, і все передеплоємо. Правда, коли воно протухне, у нас день все полежить, але зате новий кластер.
Коли новий кластер підніматимете, заодно Calico вставте замість flannel.
Що робити, якщо у вас сертифікати виписані на сто років і кластер ви передеплоювати не збираєтеся? Є така штука Kube-RBAC-Proxy. Це дуже класна розробка, вона дозволяє вбудувати себе, як sidecar container до будь-якого поду в кластері Кубернетес. І вона фактично додає до цього поду авторизацію через RBAC самого Kubernetes.
Одна проблема є. Раніше у прометеус оператора це рішення Kube-RBAC-Proxy було вбудоване. Але його згодом не стало. Наразі сучасні версії спираються на те, що у вас є network policу та закриваєте за допомогою них. І тому доведеться трохи переписати чартом. Насправді якщо ви зайдете в , там є приклади, як це використовувати як sidecars, і чарти доведеться переписати мінімально.
Є ще одна невелика проблема. Не тільки Prometheus віддає свої метрики будь-кому. У нас усі компоненти кластер Кубернетес також свої метрики вміють віддавати.
Але як я вже казав, якщо не можеш отримати доступ до кластера та зібрати інформацію, то можна хоч би нашкодити.
Так що я швиденько покажу два способи, як можна кластеру Kubernetes зіпсувати здоров'я.
Ви сміятиметеся, коли я це розповім, це два випадки з реального життя.
Спосіб перший. Вичерпання ресурсів.
Запускаємо ще один спеціальний під. У нього буде така секція.
resources:
requests:
cpu: 4
memory: 4Gi Як ви знаєте, requests — це та кількість ЦПУ та пам'яті, яка на хості резервується для конкретних подів із реквестами. Якщо у нас є чотириядерний хост у кластері Кубернетес, і туди приїжджає під з реквестами чотири ЦПУ, то значить жодного більше пода з реквестами на цей хост приїхати не зможе.
Якщо я запущу такий під, потім зроблю команду:
$ kubectl scale special-pod --replicas=...То більше ніхто в кластері Кубернетес деплоїтися не зможе. Бо у всіх нодах закінчаться реквести. Та таким чином я ваш кластер Kubernetes зупиню. Якщо я ввечері зроблю таке, то деплої можу зупинити досить надовго.
Якщо ми подивимося в черговий раз у документацію Kubernetes, то побачимо таку штуку, яка називається Limit Range. Він встановлює ресурси об'єктів кластера. Ви можете написати в yaml об'єкт Limit Range, застосувати його в певні неймспейси - і далі в цьому неймспейсі ви можете сказати, що у вас є ресурси для дефолтні, максимальні і мінімальні.
За допомогою такої штуки ми можемо обмежити користувачів у конкретних продуктових неймспейс команд у можливостях вказувати на своїх подах будь-яку гидоту. Але на жаль, навіть якщо ви скажете користувачеві, що не можна запускати поди з реквестами більше одного ЦПУ, є така чудова команда scale, чи через dashboard вони можуть робити scale.
І звідси походить спосіб номер два. Запускаємо 11 подов. Це одинадцять мільярдів. Це не тому, що я вигадав таке число, а тому, що я сам це бачив.
Реальна історія. Пізнього вечора я вже збирався йти з офісу. Дивлюся, у куточку сидить група розробників і щось судорожно з ноутбуками робить. Я підходжу до хлопців і питаю: Що у вас трапилося?
Трохи раніше, годині о дев'ятій вечора один із розробників збирався додому. І вирішив: «Я зараз свою програму заскейлю до одиниці». Натиснув один, а інтернет трошки затупив. Він ще раз натиснув на один, він натиснув на один, клацнув по Enter. Потикав на все, що міг. Тут інтернет ожив - і все почало скейлі до цього числа.
Щоправда, ця історія відбувалася не на Kubernetes, на той момент це був Nomad. Закінчилося це тим, що через годину наших спроб зупинити Nomad від наполегливих спроб скейліться, Nomad відповів, що скейлітися не перестане і нічим іншим не займатиметься. "Я втомився, я йду". І згорнувся.
Я природно спробував зробити те саме на Kubernetes. Одинадцять мільярдів подів Кубернетес не втішили, він сказав: «Не можу. Перевищує внутрішні капи». А ось 1 000 000 000 подів зміг.
У відповідь на один мільярд Куб не пішов. Він справді почав скейлити. Що далі процес заходив, то більше часу в нього витрачалося створення нових подов. Але все одно процес йшов. Єдина проблема в тому, що якщо я можу у своєму неймспейсі необмежено запускати поди, то навіть без реквестів та лімітів я можу позапускати з якимись завданнями таку кількість подів, що за допомогою цих завдань ноди почнуть складатися з пам'яті, ЦПУ. Коли я запускаю стільки подів, інформація з них повинна потрапити в сховище, тобто etcd. А коли туди надходить дуже багато інформації, сховище починає надто повільно віддавати — і Кубернетес починає затупи.
А ще одна проблема… Як знаєте, елементи, що управляють, Кубернетес — це не одна якась центральна штуковина, а кілька компонентів. Там зокрема є контролер менеджер, scheduler тощо. Всі ці хлопці почнуть виконувати одночасно непотрібну безглузду роботу, яка з часом почне займати дедалі більше часу. Контролер менеджер буде нові піди створювати. Scheduler намагатиметься знайти їм нову ноду. Нові ноди у вас у кластері, швидше за все, незабаром закінчаться. Кластер Кубернетес почне працювати все повільніше та повільніше.
Але я вирішив піти далі. Як ви знаєте, у Кубернетес є така штука, яка називається сервіс. Ну і за замовчуванням у ваших кластерах, швидше за все, сервіс працює за допомогою IP tables.
Якщо запустити один мільярд подів, наприклад, а потім за допомогою скриптика змусити Кубернетіс створювати нові сервіси:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done На всіх нодах кластера приблизно одночасно буде генеруватися нові і нові правила iptables. Причому на кожен сервіс генеруватимуться по одному мільярду правил iptables.
Я цю справу перевіряв на кілька тисяч, до десятка. І проблема в тому, що на цьому порозі ssh на ноду зробити досить проблематично. Тому що пакети, проходячи таку кількість ланцюжків, починають не дуже добре почуватися.
І це також все вирішується за допомогою Кубернетеса. Є такий об'єкт Resource quota. Встановлює кількість доступних ресурсів та об'єктів для неймспейсу в кластері. Ми можемо створити yaml об'єкт у кожному неймспейсі кластера Кубернетес. За допомогою цього об'єкта ми можемо сказати, що у нас для цього неймспейсу виділено певну кількість реквестів, лімітів, і далі ми можемо сказати, що в цьому нейспейсі можна створити 10 сервісів та 10 подів. І розробник поодинокою може хоч обдавитися вечорами. Кубернетес йому скаже: «Не можна заскалити ваші поди до такої кількості, тому що перевищує ресурс квоту». Все, проблему вирішено. .
Один проблемний момент у зв'язку із цим виникає. Ви відчуваєте, як складно стає створити в Кубернетесі неймспейс. Щоб його створити, нам необхідно купу всього врахувати.
Resource quota + Limit Range + RBAC
• Створюємо namespace
• Створюємо всередині limitrange
• Створюємо всередині resourcequota
• Створюємо serviceaccount для CI
• Створюємо rolebinding для CI та користувачів
• Опціонально запускаємо потрібні службові поди
Тому, користуючись нагодою, я хотів би поділитися своїми розробками. Є така річ, називається оператор SDK. Це спосіб у кластері Кубернетес писати йому оператори. Ви можете написати оператори за допомогою Ansible.
Спочатку ми були написані на Ansible, а потім я подивився, що є оператор SDK і переписав Ansible-роль в оператор. Цей оператор дозволяє створити в кластері Кубернетес об'єкт, який називається команда. Всередині команди він дозволяє описувати в yaml оточення для цієї команди. І всередині оточення команди він дозволяє описувати, що ми виділяємо стільки ресурсів.
маленька .
І на завершення. Що з цим робити?
Перше. Pod Security Policy – це добре. І не дивлячись на те, що жоден із установників Кубернетес досі їх не використовує, все-таки у ваших кластерах їх використовувати потрібно.
Network Policy – це не якась ще одна непотрібна фіча. Це те, що у кластері реально потрібно.
LimitRange/ResourceQuota - час би використовувати. Ми давно почали цим користуватися, і я довго був упевнений, що всі це поголовно застосовують. Виявилось, що це рідкість.
Крім того, що я згадував у ході доповіді, є незадокументовані фічі, які дозволяють атакувати кластер. Вийшов нещодавно .
Деякі речі настільки сумні та образливі. Як наприклад, за певних умов кублети в кластері Кубернетес можуть віддавати вміст warlocks директорії, причому неавторизованого користувача.
лежать інструкції, як відтворити все, що розповідав. Там лежать файли з продакшн прикладами, як ResourceQuota, Pod Security Policy виглядають. І все це можна доторкнутися.
Всім дякую.
Джерело: habr.com