Kubernetes Basics
Last updated
Last updated
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Оригінальний автор цієї сторінки Хорхе (читайте його оригінальну публікацію тут)
Дозволяє запускати контейнери в контейнерному двигуні.
Планування дозволяє ефективно виконувати місії контейнерів.
Підтримує контейнери в живому стані.
Дозволяє комунікацію між контейнерами.
Дозволяє техніки розгортання.
Обробляє обсяги інформації.
Вузол: операційна система з подом або подами.
Под: обгортка навколо контейнера або кількох контейнерів. Под повинен містити лише один додаток (тому зазвичай под запускає лише 1 контейнер). Под є способом, яким Kubernetes абстрагує технологію контейнерів.
Сервіс: Кожен под має 1 внутрішню IP-адресу з внутрішнього діапазону вузла. Однак його також можна відкрити через сервіс. Сервіс також має IP-адресу і його мета - підтримувати зв'язок між подами, тому якщо один з них помре, новий замінник (з іншою внутрішньою IP-адресою) буде доступний за тою ж IP-адресою сервісу. Його можна налаштувати як внутрішній або зовнішній. Сервіс також діє як балансувальник навантаження, коли 2 поди підключені до одного й того ж сервісу.
Коли сервіс створюється, ви можете знайти кінцеві точки кожного сервісу, запустивши kubectl get endpoints
Kubelet: Основний агент вузла. Компонент, який встановлює зв'язок між вузлом і kubectl, і може запускати лише поди (через API-сервер). Kubelet не керує контейнерами, які не були створені Kubernetes.
Kube-proxy: це сервіс, відповідальний за комунікацію (сервіси) між apiserver і вузлом. Основою є IPtables для вузлів. Найбільш досвідчені користувачі можуть встановити інші kube-proxy від інших постачальників.
Контейнер Sidecar: Контейнери Sidecar - це контейнери, які повинні працювати разом з основним контейнером у поді. Цей шаблон Sidecar розширює та покращує функціональність поточних контейнерів без їх зміни. Сьогодні ми знаємо, що використовуємо технологію контейнерів, щоб обернути всі залежності для запуску додатка в будь-якому місці. Контейнер виконує лише одну задачу і робить це дуже добре.
Головний процес:
Api Server: Це спосіб, яким користувачі та поди спілкуються з головним процесом. Дозволяються лише автентифіковані запити.
Планувальник: Планування означає забезпечення того, щоб поди відповідали вузлам, щоб Kubelet міг їх запустити. Він має достатньо інтелекту, щоб вирішити, який вузол має більше доступних ресурсів, і призначити новий под. Зверніть увагу, що планувальник не запускає нові поди, він лише спілкується з процесом Kubelet, що працює всередині вузла, який запустить новий под.
Kube Controller manager: Він перевіряє ресурси, такі як набори реплік або розгортання, щоб перевірити, чи, наприклад, працює правильна кількість подів або вузлів. У разі відсутності пода він зв'яжеться з планувальником, щоб запустити новий. Він контролює реплікацію, токени та облікові сервіси для API.
etcd: Сховище даних, постійне, послідовне та розподілене. Це база даних Kubernetes і сховище ключ-значення, де зберігається повний стан кластерів (кожна зміна тут реєструється). Компоненти, такі як планувальник або менеджер контролера, залежать від цих даних, щоб знати, які зміни відбулися (доступні ресурси вузлів, кількість запущених подів...)
Cloud controller manager: Це специфічний контролер для управління потоками та додатками, тобто: якщо у вас є кластери в AWS або OpenStack.
Зверніть увагу, що оскільки може бути кілька вузлів (які запускають кілька подів), також може бути кілька головних процесів, доступ до яких до API-сервера збалансований за навантаженням, а їх etcd синхронізовані.
Томи:
Коли под створює дані, які не повинні бути втрачені, коли под зникне, їх слід зберігати в фізичному томі. Kubernetes дозволяє прикріпити том до пода для збереження даних. Том може бути на локальному комп'ютері або в віддаленому сховищі. Якщо ви запускаєте поди на різних фізичних вузлах, вам слід використовувати віддалене сховище, щоб усі поди могли до нього отримати доступ.
Інші конфігурації:
ConfigMap: Ви можете налаштувати URL-адреси для доступу до сервісів. Под отримає дані звідси, щоб знати, як спілкуватися з іншими сервісами (поди). Зверніть увагу, що це не рекомендоване місце для збереження облікових даних!
Secret: Це місце для зберігання секретних даних, таких як паролі, API-ключі... закодованих у B64. Под зможе отримати доступ до цих даних, щоб використовувати необхідні облікові дані.
Deployments: Тут вказуються компоненти, які будуть запущені Kubernetes. Користувач зазвичай не працює безпосередньо з подами, поди абстраговані в ReplicaSets (кількість однакових подів, що реплікуються), які запускаються через розгортання. Зверніть увагу, що розгортання призначені для безстанційних додатків. Мінімальна конфігурація для розгортання - це ім'я та зображення для запуску.
StatefulSet: Цей компонент призначений спеціально для додатків, таких як бази даних, які потребують доступу до одного й того ж сховища.
Ingress: Це конфігурація, яка використовується для викриття додатка публічно з URL-адресою. Зверніть увагу, що це також можна зробити за допомогою зовнішніх сервісів, але це правильний спосіб викриття додатка.
Якщо ви реалізуєте Ingress, вам потрібно буде створити Ingress Controllers. Ingress Controller - це под, який буде кінцевою точкою, що отримуватиме запити, перевірятиме їх і балансуватиме навантаження на сервіси. Ingress controller направлятиме запит на основі налаштованих правил ingress. Зверніть увагу, що правила ingress можуть вказувати на різні шляхи або навіть піддомени для різних внутрішніх сервісів Kubernetes.
Кращою практикою безпеки буде використання хмарного балансувальника навантаження або проксі-сервера як точки входу, щоб жодна частина кластера Kubernetes не була відкритою.
Коли отримується запит, який не відповідає жодному правилу ingress, контролер ingress направить його на "Default backend". Ви можете describe
контролер ingress, щоб отримати адресу цього параметра.
minikube addons enable ingress
CA є надійним коренем для всіх сертифікатів у кластері.
Дозволяє компонентам перевіряти один одного.
Усі сертифікати кластера підписані CA.
ETCd має свій власний сертифікат.
типи:
сертифікат apiserver.
сертифікат kubelet.
сертифікат планувальника.
Minikube можна використовувати для виконання деяких швидких тестів на Kubernetes без необхідності розгортання цілого середовища Kubernetes. Він запустить головні та вузлові процеси на одному комп'ютері. Minikube використовуватиме virtualbox для запуску вузла. Дивіться тут, як його встановити.
Kubectl
- це інструмент командного рядка для кластерів kubernetes. Він спілкується з Api сервером головного процесу для виконання дій у kubernetes або для запиту даних.
Дашборд дозволяє вам легше бачити, що виконує minikube, ви можете знайти URL для доступу до нього в:
Кожен конфігураційний файл має 3 частини: метадані, специфікація (що потрібно запустити), статус (бажаний стан). Всередині специфікації файлу конфігурації розгортання ви можете знайти шаблон, визначений з новою структурою конфігурації, що визначає образ для запуску:
Приклад розгортання + служби, оголошених в одному конфігураційному файлі (з тут)
Оскільки служба зазвичай пов'язана з одним розгортанням, можливо оголосити обидва в одному конфігураційному файлі (служба, оголошена в цій конфігурації, доступна лише внутрішньо):
Приклад конфігурації зовнішнього сервісу
Цей сервіс буде доступний зовні (перевірте атрибути nodePort
та type: LoadBlancer
):
Це корисно для тестування, але для продуктивного середовища у вас повинні бути лише внутрішні сервіси та Ingress для відкриття додатку.
Приклад конфігураційного файлу Ingress
Це відкриє додаток за адресою http://dashboard.com
.
Приклад конфігураційного файлу секретів
Зверніть увагу, як паролі закодовані в B64 (що не є безпечним!)
Приклад ConfigMap
ConfigMap - це конфігурація, яка надається подам, щоб вони знали, як знаходити та отримувати доступ до інших сервісів. У цьому випадку кожен под буде знати, що ім'я mongodb-service
є адресою пода, з яким вони можуть спілкуватися (цей под буде виконувати mongodb):
Тоді, всередині deployment config ця адреса може бути вказана наступним чином, щоб вона завантажувалася в середовище pod:
Приклад конфігурації обсягу
Ви можете знайти різні приклади конфігурації зберігання yaml файлів за посиланням https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes. Зверніть увагу, що обсяги не знаходяться всередині просторів імен
Kubernetes підтримує декілька віртуальних кластерів, які базуються на одному фізичному кластері. Ці віртуальні кластери називаються просторами імен. Вони призначені для використання в середовищах з багатьма користувачами, розподіленими по кількох командах або проектах. Для кластерів з кількома до десятків користувачів вам не потрібно створювати або думати про простори імен. Ви повинні почати використовувати простори імен, щоб мати кращий контроль і організацію кожної частини програми, розгорнутої в kubernetes.
Простори імен забезпечують область для імен. Імена ресурсів повинні бути унікальними в межах простору імен, але не між просторами імен. Простори імен не можуть бути вкладеними один в одного, і кожен ресурс Kubernetes може бути тільки в одному просторі імен.
За замовчуванням є 4 простори імен, якщо ви використовуєте minikube:
kube-system: Це не призначено для використання користувачами, і вам не слід його чіпати. Це для процесів master і kubectl.
kube-public: Публічно доступні дані. Містить configmap, який містить інформацію про кластер.
kube-node-lease: Визначає доступність вузла.
default: Простір імен, який користувач буде використовувати для створення ресурсів.
Зверніть увагу, що більшість ресурсів Kubernetes (наприклад, pods, services, replication controllers та інші) знаходяться в деяких просторах імен. Однак інші ресурси, такі як ресурси простору імен та низькорівневі ресурси, такі як nodes і persistentVolumes, не знаходяться в просторі імен. Щоб побачити, які ресурси Kubernetes є в просторі імен, а які ні:
Ви можете зберегти простір імен для всіх наступних команд kubectl у цьому контексті.
Helm - це менеджер пакетів для Kubernetes. Він дозволяє пакувати YAML файли та розповсюджувати їх у публічних і приватних репозиторіях. Ці пакети називаються Helm Charts.
Helm також є шаблонним двигуном, який дозволяє генерувати конфігураційні файли з змінними:
Secret - це об'єкт, який містить чутливі дані, такі як пароль, токен або ключ. Таку інформацію інакше можна було б помістити в специфікацію Pod або в образ. Користувачі можуть створювати Secrets, а система також створює Secrets. Ім'я об'єкта Secret повинно бути дійсним DNS піддоменом. Читайте тут офіційну документацію.
Secrets можуть бути такими, як:
API, SSH ключі.
OAuth токени.
Облікові дані, паролі (в чистому вигляді або b64 + шифрування).
Інформація або коментарі.
Код підключення до бази даних, рядки… .
Існують різні типи секретів у Kubernetes
Вбудований тип | Використання |
---|---|
Opaque | произвольні дані, визначені користувачем (за замовчуванням) |
kubernetes.io/service-account-token | токен облікового запису служби |
kubernetes.io/dockercfg | серіалізований файл ~/.dockercfg |
kubernetes.io/dockerconfigjson | серіалізований файл ~/.docker/config.json |
kubernetes.io/basic-auth | облікові дані для базової аутентифікації |
kubernetes.io/ssh-auth | облікові дані для SSH аутентифікації |
kubernetes.io/tls | дані для TLS клієнта або сервера |
bootstrap.kubernetes.io/token | дані токена для завантаження |
Тип Opaque є типом за замовчуванням, типовою парою ключ-значення, визначеною користувачами.
Як працюють секрети:
Наступний конфігураційний файл визначає secret під назвою mysecret
з 2 парами ключ-значення username: YWRtaW4=
та password: MWYyZDFlMmU2N2Rm
. Він також визначає pod під назвою secretpod
, який матиме username
та password
, визначені в mysecret
, доступними в змінних середовища SECRET_USERNAME
__ та __ SECRET_PASSWOR
. Він також монтує секрет username
всередині mysecret
за шляхом /etc/foo/my-group/my-username
з правами 0640
.
etcd є узгодженим і високодоступним сховищем ключ-значення, яке використовується як основне сховище Kubernetes для всіх даних кластера. Давайте отримати доступ до секретів, збережених в etcd:
Ви побачите, де сертифікати, ключі та URL-адреси розташовані у файловій системі. Як тільки ви їх отримаєте, ви зможете підключитися до etcd.
Якщо ви зможете встановити зв'язок, ви зможете отримати секрети:
Додавання шифрування до ETCD
За замовчуванням всі секрети зберігаються у відкритому тексті всередині etcd, якщо ви не застосуєте шар шифрування. Наступний приклад базується на https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
Після цього вам потрібно встановити прапорець --encryption-provider-config
на kube-apiserver
, щоб вказати на місце розташування створеного конфігураційного файлу. Ви можете змінити /etc/kubernetes/manifest/kube-apiserver.yaml
і додати наступні рядки:
Прокрутіть вниз у volumeMounts:
Прокрутіть униз у volumeMounts до hostPath:
Перевірка, що дані зашифровані
Дані зашифровані при запису в etcd. Після перезапуску вашого kube-apiserver
, будь-який новостворений або оновлений секрет повинен бути зашифрований при зберіганні. Щоб перевірити, ви можете використовувати програму командного рядка etcdctl
для отримання вмісту вашого секрету.
Створіть новий секрет під назвою secret1
у просторі імен default
:
Використовуючи командний рядок etcdctl, прочитайте цей секрет з etcd:
ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
де [...]
повинні бути додаткові аргументи для підключення до сервера etcd. 3. Перевірте, що збережений секрет має префікс k8s:enc:aescbc:v1:
, що вказує на те, що провайдер aescbc
зашифрував отримані дані. 4. Перевірте, що секрет правильно розшифрований при отриманні через API:
повинен відповідати mykey: bXlkYXRh
, mydata закодовано, перевірте декодування секрету, щоб повністю декодувати секрет.
Оскільки секрети зашифровані при запису, виконання оновлення секрету зашифрує цей вміст:
Останні поради:
Намагайтеся не зберігати секрети у файловій системі, отримуйте їх з інших місць.
Ознайомтеся з https://www.vaultproject.io/ для додаткового захисту ваших секретів.
Вчіться та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вчіться та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)