TCPDUMP як послуга: робимо налагодження мережі доступним у Kubernetes/OpenShift - javascript.org.ua

Налагодження мережі в середовищах Kubernetes традиційно було привілеєм, доступним лише адміністраторам кластерів. Але що, якщо ми могли б змінити це? Що, якщо ми зможемо дозволити розробникам захоплювати та аналізувати мережевий трафік без компрометації безпеки кластера? Саме це досягає TCPDUMP як послуга (TaaS), надаючи безпечне, автоматизоване рішення для захоплення мережевого трафіку.

Виклик: Налагодження мережі в Kubernetes

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

Звичайні користувачі не мають необхідних прав для захоплення мережевого трафіку
Адміністратори кластерів повинні вручну збирати ці дані
Цей процес створює затримки в циклах усунення неполадок та розробки
Цінний адміністративний час витрачається на рутинні завдання з налагодження
Питання безпеки при наданні підвищених прав розробникам

З’являється TCPDUMP як послуга: глибоке занурення у рішення

TaaS побудований на основі Dumpy, передового плагіна kubectl, що відмінно справляється із захопленням мережевого трафіку в середовищах Kubernetes. Ось детальний огляд того, як працює це рішення:

Огляд архітектури

Стратегія розміщення Pod
— TaaS створює привілейовані контейнери на тому ж вузлі, що й цільові поди
— Ці контейнери спільно використовують мережевий простір імен з цільовими подами
— Всі привілейовані операції ізольовані в окремому просторі імен
Реалізація безпеки
— Політики RBAC контролюють доступ до ресурсів
— Ізоляція просторів імен запобігає ескалації привілеїв
— Security Context Constraints (SCC) підтримують жорсткий контроль безпеки
— ResourceQuotas запобігають зловживанню ресурсами та вузлами
Автоматизація робочих процесів
— Автоматизоване створення та розміщення подів
— Динамічна конфігурація на основі специфікацій цільових подів
— Доставка результатів у спільне місце

Огляд шаблону

apiVersion: template.openshift.io/v1  
kind: Template  
metadata:  
 annotations:  
 description: "Самообслуговування для створення TCPDUMP для клієнтів. tcpdump буде працювати 5 хвилин, а вихідний pcap файл буде збережено в спільному статичному об'ємі."  
 iconClass: icon-openshift  
 openshift.io/display-name: TCPDUMP як послуга  
 name: tcpdump-as-a-service  
 namespace: openshift  
objects:  
- kind: Pod  
 apiVersion: v1  
 metadata:  
 # ім'я пода буде згенеровано випадковим чином  
 generateName: "sniffer-"  
 namespace: dumpy-test  
 labels:  
 app: dumpy-kubectl-plugin  
 component: dumpy-sniffer  
 annotations:  
 spec:  
 # Додано вибір вузла, щоб pod dumpy міг працювати на вузлі цільового пода і виконувати tcpdump  
 nodeSelector:  
 kubernetes.io/hostname: ${node_name}  
 restartPolicy: Never  
 serviceAccountName: dumpy  
 hostPID: true # Дозволяє доступ до ідентифікаторів процесів на рівні хоста для взаємодії з контейнерним виконанням  
 containers:  
 - resources:  
 limits:  
 # додано обмеження CPU, щоб pod dumpy не перевантажував вузол, може бути змінено  
 cpu: 500m  
 ephemeral-storage: 16i  
 memory: 128Mi  
 requests:  
 cpu: 250m  
 ephemeral-storage: 512Mi  
 memory: 64Mi  
 name: dumpy-container  
 # Для отримання ідентифікатора контейнера процесу пода використано бінарник crictl, який використовує OpenShift як контейнерний runtime  
 # Потім цей ідентифікатор зберігається в змінній середовища TARGET_CONTAINERID, яку використовує dumpy.sh.   
 # Усі pcap файли будуть збережені в /tmp/dumpy за замовчуванням. Я переозначив місце збереження файлів за допомогою спільного об'єму і додав CAPTURE_NAME як випадкове число  
 # щоб pcap файли зберігалися під різними іменами для кожного запуску tcpdump і не перезаписували один одного.  
 # tcpdump буде працювати 5 хвилин, це можна налаштувати в команді нижче.
command: ["/bin/sh","-c","export CAPTURE_NAME=$RANDOM && export TARGET_CONTAINERID=$(nsenter -t 1 -m /usr/bin/crictl pods | grep '${target_pod}' | awk '{print $1}' | xargs -I {} sh -c 'nsenter -t 1 -m /usr/bin/crictl ps | grep {}' | awk '{print $1}' | xargs -I {} nsenter -t 1 -m /usr/bin/crictl inspect {} | jq -r .status.id) && timeout 5m ./dumpy_sniff.sh '${params}' || true"]  
env:  
 - name: DUMPY_TARGET_TYPE  
 value: pod  
 - name: TARGET_POD  
 value: ${target_pod}  
 imagePullPolicy: IfNotPresent  
 startupProbe:  
 exec:  
 command:  
 - cat  
 - /tmp/dumpy/healthy  
 volumeMounts:  
 - name: dumpy-tcp-dumps  
 # Я змушений був змінити місце збереження оригінального файлу dumpy, щоб pcap файли зберігалися в об’ємі, який я додав до цього шаблону.  
 mountPath: /tmp/dumpy  
 terminationMessagePolicy: File  
 image: 'larrytheslap/dumpy'  
 securityContext:  
 runAsUser: 0  
 privileged: true  
 volumes:  
 # Я створив статичний об'єм на своєму NAS сервері, щоб всі користувачі могли отримати до нього доступ і зберігати свої pcap файли  
 - name: dumpy-tcp-dumps  
 persistentVolumeClaim:  
 claimName: dumpy-pvc  
parameters:  
 - description: Назва пода, на якому ви хочете запустити tcpdump  
 displayName: Цільовий pod  
 name: target_pod  
 required: true  
 - description: Вузол, на якому працює ваш pod  
 displayName: Назва вузла  
 name: node_name  
 required: true  
 - description: Параметри для tcpdump, за замовчуванням "-i any"

Пояснення ключових компонентів:

objects: Перелічує ресурси (наприклад, pod), які буде створено за допомогою шаблону. У цьому випадку визначено pod, який буде виконувати tcpdump протягом 5 хвилин.
generateName: Забезпечує унікальність імені pod, генеруючи випадковий суфікс.
nodeSelector: Забезпечує, щоб pod був запланований на тому ж вузлі, що й цільовий pod для захоплення мережевого трафіку. Плейсхолдер ${node_name} буде замінено на фактичну назву вузла під час ініціалізації.
hostPID: Дозволяє pod доступ до ідентифікаторів процесів на хості, що необхідно для використання інструментів, таких як crictl, для взаємодії з контейнерними процесами.
containers: Визначає конфігурацію контейнера, включаючи обмеження ресурсів, змінні середовища та команду для запуску tcpdump.
command: Виконує команду оболонки, яка генерує випадкове ім’я для захоплення, отримує цільовий контейнерний ідентифікатор за допомогою crictl і запускає процес tcpdump за допомогою власного сценарію (dumpy_sniff.sh).
volumeMounts: Монтує постійний об’єм (dumpy-tcp-dumps) в /tmp/dumpy для зберігання файлів захоплення tcpdump.
parameters: Визначає параметри, які користувачі повинні вказати при ініціалізації шаблону:
target_pod: Pod, на якому буде працювати tcpdump.
node_name: Вузол, на якому працює цільовий pod.
params: Опційні параметри для tcpdump, за замовчуванням -i any (захоплення на всіх інтерфейсах).

Як це працює:

Шаблон дозволяє розробникам або адміністраторам легко ініціалізувати pod з налаштованим tcpdump для захоплення мережевого трафіку для усунення неполадок.

Коли шаблон ініціалізується, відбувається наступне:

Pod планується на тому ж вузлі, що й цільовий pod, зазначений користувачем, з tcpdump, який працює протягом 5 хвилин (це можна налаштувати в шаблоні YAML).
Вихідні дані tcpdump зберігаються в спільному постійному об’ємі, до якого користувач може отримати доступ після завершення захоплення.

Досвід користувача

Для розробників використання TaaS надзвичайно просте. У них є два варіанти:

Використовуючи OpenShift Console:
1. Перейдіть на вкладку Developer view
2. Натисніть кнопку “+Add”
3. Знайдіть “TCPDUMP як послуга” в Developer Catalog
4. Натисніть “Instantiate Template”

Використовуючи CLI:

oc process tcpdump-as-a-service -n openshift -p target_pod= -p node_name= -p params="" -p target_namespace=dumpy | oc apply -f -

Вбудовані засоби захисту

Для забезпечення стабільності та безпеки кластера TaaS реалізує кілька критичних засобів захисту:

1.
Resource Management
— Обмеження квот на pod запобігають перевантаженню системи
— Обмеження процесора для процесів tcpdump
— Обмеження пам'яті для процесів tcpdump

Обмеження привілеїв
— Привілейовані pod працюють у спеціально визначеному просторі імен, до якого звичайні користувачі не мають доступу.
Обмеження часу

— Pod налаштовано на роботу протягом 5 хвилин. Я хочу обмежити час виконання процесу, щоб зменшити його вплив на продуктивність сервера.

Вплив

TaaS змінює робочий процес налагодження мережі в середовищах Kubernetes, завдяки:
- Зменшенню адміністративного навантаження
- Прискоренню циклів усунення неполадок
- Наданню можливості командам розробників
- Збереженню меж безпеки
- Стандартизації практик налагодження

Початок роботи

Готові спробувати TCPDUMP як послугу? Для цього проекту потрібні:

Кластер OpenShift (4.12 або новіший)
Інструмент командного рядка oc
Привілеї адміністратора кластера для початкового налаштування

Відвідайте https://github.com/yaronyadid/tcpdump-as-a-service, щоб почати, і приєднуйтесь до мене у зробленні налагодження мережі в Kubernetes більш доступним для всіх.

Перекладено з: TCPDUMP as a Service: Making Network Debugging Accessible in Kubernetes/OpenShift