Как связаны k8s и National Security Agency: часть 2
#полезный_материал

Вчера разобрались с audit policy, а сегодня рассмотрим seccomp profiles.

➡️ Подробности и большой чек-лист по k8s hardening — в гайде от NSA.

Инфраструктурные ошибки в работе с k8s

🐈 Один k8s для всего

Когда вы только переезжаете на k8s, то кажется, что можно все объединить под крылом одного кластера, включая dev-среду. Вроде бы проще управлять, да и ресурсы (а значит и деньги) экономим [про деньги за инфру рассказывал тут].

Год-два спустя вы оказываетесь в следующей ситуации: больше команд, микросервисов, баз данных. И вот уже любое изменение в кластере потенциально прикладывает прод.

А решается это так же, как с распилом монолита на сервисы. Вам буквально нужно создавать новые кластеры, переносить туда приложения, переписывать пайплайны и править десятки настроенных интеграций. И не факт, что всё можно сделать без даунтайма.

🐈 Namespaces и resource quotas — изоляция не нужна (на самом деле нужна)

Просто подняли кластера, просто задеплоили приложения. Вроде и так всё работает. А потом оказывается, что сервисы начинают конкурировать за ресурсы CPU и RAM. Один разработчик случайно опечатывается, и вот у вас вместо 10 реплик приложения уже их 100.

О контроле ресурсов можно забыть. А если еще и автоскейлинг worker nodes есть, то от облака придет очень «приятный» счет в следующем месяце. Исправлять это, конечно, можно, но придется довести до всех, что теперь есть лимиты на ресурсы и нельзя просто так запросить себе еще 50 CPU и 200 GB RAM, потому что оптимизировать сервис долго, и проще закидать железом.

🐈 Network policies, или мы можем делать все

Сеть кластера безопасна, она же в закрытом контуре.
Ок, ничего не делаем.
Полгода спустя…

У компании X возникла утечка данных, потому что один из сотен сервисов использовал уязвимую версию библиотеки, вызов функций из которой получилось проэксплуатировать через публичное API вашего проекта, и негодяй смог закрепиться в поде, найти API других сервисов (авторизация внутри сети тоже не нужна, все друг другу доверяют) и слить все, до чего смог дотянуться.

Исправить это постфактум, когда данные уже утекли, задача не из приятных.
Знаете что еще менее приятно? Разгребать последствия. Представьте гипотетическую ситуацию, когда злоумышленник смог разослать клиентам сообщения с нелицеприятным содержанием, когда смог поменять цены на товары, когда смог инициировать вывод денег со счета на сотни левых карт, просто проэксплуатировав внутренние API.

Важно только одно. Безопасность и удобство никогда не идут рядом. Чем безопаснее система, тем менее удобно разрабатывать любые интеграции. Вам нужно заранее запросить у безопасников разрешение на интеграцию сервиса X с сервисом Y. Да еще и указать, какие методы сервиса будут вызываться. И все это для того, чтобы сократить вектор атаки.

🐈 Всегда виноват DNS

Когда вы только начинаете работать с k8s, кажется, что CoreDNS просто работает. k8s писали умные люди, google фигни не сделает.

Спокойно работаете и получаете сообщение в чате: прод лежит 🔥🔥🔥

Представьте себе: вы радостно скейлите сервис, добавляя больше реплик, потому что нужно подготовиться к росту нагрузки перед распродажей, например. Но внезапно видите, что он сыпет ошибками про dns resolve.

Мы набиваем в k8s кластер все больше и больше сервисов, и каждый сервис делает кучу DNS-запросов. А CoreDNS как поставили, так он и работал. Ресурсов стало мало и k8s начал его троттлить по CPU 🙁

Что делать? Тюнить ресурсы (CPU и RAM), мой юный кубарист!

Проверьте используемые ресурсы и поскейлите поды CoreDNS. Подробнее можно почитать здесь.

И конечно node local DNS — просто must have для снижения нагрузки.

И последнее: мониторинг! И алерты! Что толку от дашбордов, где можно увидеть проблему, только зайдя в дашборд. Алерты хотя бы напомнят об их существовании.

— У вас дыра в безопасности!
— Ну, хоть что-то у нас в безопасности.

Вас беспокоит, когда в проектах о безопасности задумываются в последнюю очередь? Проект вроде работает, и даже приносит чуть-чуть денег, а потом приходит мамкин хакер и сливает все ваши данные. Данное обстоятельство вызывает у нас с Маркусом крайнюю степень неудовольствия и обеспокоенности.

А какие аспекты ИБ вызывают у вас эмоциональное напряжение и внутренний дискомфорт? Комментарии — это безопасное пространство, где можно поделиться наболевшим ⬇️

Дайджест материалов за февраль

Месяц получился продуктивным, собрал в одном посте все полезные материалы. Забирайте, кто что-то пропустил ⬇️

🔷 План онбординга в компанию
→ Часть 1
→ Часть 2
→ Часть 3

🔷 Как строить надежные приложения?

🔷 Работа с долгоживущими подключениями

🔷 Лучшие практики написания Java и Go приложений под k8s — вебинар
→ YouTube
→ VK Видео

🔷 Как строить отказоустойчивые системы?

🔷 Как надо (и как не надо) проводить собеседования
→ Часть 1
→ Часть 2

🔷 Как связаны k8s и National Security Agency
→ Часть 1
→ Часть 2

🔷 Инфраструктурные ошибки в работе с k8s

Дальше — больше. Stay tuned! 🐈

P.S. В комментариях можно написать, какие темы вы хотели бы разобрать в марте ⬇️

Ну что, котятки, есть среди вас разработчики, которые так и не добрались до кубов?

Новость для вас — сегодня стартовал курс «Kubernetes для разработчиков» 🔷

Впереди — 7 недель, за которые вы структурируете и углубите свои знания в k8s и научитесь:

➡️ самостоятельно разворачивать локальную среду для разработки своих приложений;
➡️ дебажить приложения в кубе так же легко, как в докере — смотреть логи, собирать метрики, писать Helm-чарты, CI/CD;
➡️ самостоятельно вносить изменения в манифесты, не дожидаясь DevOps-команды;
➡️ оптимально, эффективно и правильно использовать k8s в проекте.

Жду всех, кто еще не успел присоединиться — набор открыт до 10 марта.

🐈 Подробности — на странице курса.

Безопасность: интегрируемся с vault

Использование k8s secrets не единственный способ доставить секреты в приложение. Более того, cluster admin может посмотреть эти секреты и есть чуть более надежные подходы.

➡️ Рассмотрим как интегрироваться с vault через vault sidecar injector.

Здесь мы пропускаем шаг создания секретов в k8s, а в vault у нас больше возможностей по аудиту доступа, и способов сказать админу, что он идет не туда, куда нужно, гораздо больше. Вплоть до законодательных запретов и серьезных последствий в некоторых особо зарегулированных сферах.

Рассмотренный подход все еще не 100% bullet proof и cluster admin все еще может зайти в контейнер и увидеть секреты, но это тоже можно решить разными способами, о которых мы поговорим как-нибудь в другой раз.

🟠 Disclaimer:

Я скромно опустил некоторые моменты, которые могут вызвать 🤦 у опытного админа.

Давайте разложим все по полочкам:

➡️ Minikube? Seriously? Да, для демонстрации отлично подходит. В проде вы не увидите minikube (хотя могут быть кейсы), но это тот же самый k8s.

➡️ VAULT_TOKEN=root - BIG NO-NO! Разбрасываться root токенами - это как оставлять ключи от квартиры под ковриком. В продакшене используются более сложные методы аутентификации, например, с помощью AWS IAM.

➡️ Vault в dev режиме внутри кластера? В реальном мире Vault обычно развертывается вне кластера в HA конфигурации.

➡️ Helm Chart без кастомизации. В продакшене вам потребуется тонкая настройка Vault, включая storage backend, репликацию и мониторинг.

➡️ kubectl exec внутри Vault? Зачем лезть внутрь контейнера, если есть Vault CLI? Потому что так проще показать.

➡️ Hardcoded конфиги в Deployment YAML? Используйте ConfigMaps и Secrets (да-да, irony) для хранения конфигурации и избегайте хардкодинга.

Итак, приступим.

🐈 Запустим minikube

minikube start

🐈 Установим vault в dev режиме (в проде vault может быть вне кластера k8s и контролироваться отдельной security командой). Внимание: рестарт контейнера vault потеряет все ваши настройки в dev-режиме!

helm repo add hashicorp https://helm.releases.hashicorp.com
helm repo update
helm install vault hashicorp/vault --set "server.dev.enabled=true" -n vault --create-namespace

🐈 Получим root token

export VAULT_TOKEN=root

Да, в dev-инсталяции все настолько просто. Посмотреть можно в логах vault.

kubectl -n vault logs vault-0

Покажет вам

Development mode should NOT be used in production installations!

Мы не vault изучаем, а как его использовать для решения подобной задачи 🙂

🐈 Включим k8s auth method в Vault и настроим политики, роли и прочие сущности vault, включая секрет

kubectl -n vault exec -it vault-0 -- /bin/sh

# Далее все внутри контейнера vault-0
vault secrets enable -path=k8s kv-v2
vault kv put k8s/myapp/prod mykey="prod-secret"

# И включим интеграцию k8s с vault
vault auth enable kubernetes
vault write auth/kubernetes/config \
      kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443"

Продолжаем настройку все так же внутри контейнера с vault. Создаем политику.

vault policy write k8s-myapp-prod - <<EOF
path "k8s/data/myapp/prod" {
   capabilities = ["read"]
}
EOF

И связываем ее с service account

vault write auth/kubernetes/role/myapp-prod \
      bound_service_account_names=myapp-prod-sa \
      bound_service_account_namespaces=app-prod \
      policies=k8s-myapp-prod \
      ttl=1h

🐈 Создаем тестовое приложение (уже не в контейнере vault выполняем)

kubectl create ns app-prod
k -n app-prod create sa myapp-prod-sa

И задеплоим

echo '
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
  namespace: app-prod
  labels:
    app: busybox
spec:
  replicas: 1
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "myapp-prod"
        vault.hashicorp.com/agent-inject-template-CREDENTIALS: |
          {{- with secret "k8s/data/myapp/prod" -}}
          MYKEY={{ .Data.data.mykey }}
          {{- end -}}
    spec:
      serviceAccountName: myapp-prod-sa
      terminationGracePeriodSeconds: 1
      containers:
      - name: busybox
        image: busybox
        command:
        - /bin/sh
        - -c
        - |
          while true; do
            env $(cat /vault/secrets/credentials | xargs);
            printenv;
            sleep 10;
          done 
' > app.yaml

kubectl -n app-prod apply -f app.yaml

🐈 Посмотрим, что vault sidecar успешно был добавлен в наше приложение (имя пода будет другим)

kubectl -n app-prod describe pod app-78fd56f64b-vtrks

А также увидим секрет

kubectl -n app-prod exec -it app-78fd56f64b-vtrks -- cat /vault/secrets/credentials
# И в логах
kubectl -n app-prod logs app-7ccc6557fb-bzj2b | grep MYKE

Итого: секрет доставили в приложение всего лишь за пару шагов. Правда k8s это просто? :sarcasm:

Поделитесь вашими кейсами выстраивания относительно защищенных кластеров (нет, ничто не безопасно на 100%, пока оно включено 🙂)

Как я перестал волноваться и полюбил ротацию секретов. Часть 1

Представьте, что вам пришла задача настроить ротацию секретов в вашей инфраструктуре. Кейсы могут начинаться с простого: у нас есть API-ключи от внешних систем, а разработчики имеют свойство иногда уходить в другую компанию и, по-хорошему, все доступы должны забираться.

И могут заканчиваться сложными, когда приходит регулятор и требует внедрения конкретных мер защиты, а то придет снова и сделает [censored].

Посмотрим что в нашем любимом k8s для этого есть ⬇️

Методы ротации

🔷 Ручной способ: стучим по клавиатуре

kubectl patch secret mysecret -p '{"stringData":{"mykey":"newvalue"}}'

Человеческий фактор никто не отменял. Одна ошибка и ты ошибся. Ауф.

Если наше прекрасное приложение может на лету прочитать изменения, то оно увидит изменение секрета при условии, что секрет примонтирован как volume.

Но не сразу, а с лагом в минуту, потому что такие настройки по умолчанию у kubelet (см. тут, параметр syncFrequency)

🔷 2. Внешние операторы: когда хочется как у взрослых

➡️ HashiCorp Vault: Это мы посмотрели в предыдущем посте.
➡️ External Secrets Operator: Еще один способ синхронизировать секреты в кластере.
➡️ AWS Secrets Manager: Если ваша инфраструктура в AWS, то почему бы и нет?

Механизмы доставки

Как секреты попадают в под

🔷 Volume Mount с автообновлением
Kubelet делает это почти незаметно. Знай себе, читай файлики с файловой системы внутри пода.

🔷 Sidecar
Неважно, vault это или что-то еще. Главное, что в большинстве случаев изменения все так же оказываются видны в файловой системе пода.

🚨 ВНИМАНИЕ! ENV переменные не позволяют выполнить ротацию

Никакой динамики, только полный редеплой. Конечно, есть окольные пути, но применять такое на самом деле кажется за гранью.

Сценарии ротации: От простого к сложному

➡️ API ключи: Легкий уровень

🟠 Создаем новый ключ
🟠 Обновляем сервисы
🟠 Удаляем старый ключ

➡️ JWT подписи: Средний уровень сложности

🟠 Добавляем поддержку нового секрета для подписи в приложение
🟠 Деплоим
🟠 Смотрим по метрикам, когда перестали приходить токены со старым секретом (вы же добавили метрики?)
🟠 Удаляем старый секрет и опционально меняет код обратно

func (jm *JWTManager) IsTokenValid(token string) bool {
    // Проверяем токен двумя секретами
    return validateWithCurrentKey(token) ||
           validateWithPreviousKey(token)
}

Продолжение в посте завтра, где посмотрим на более сложный кейс, как менять credentials вашей любимой БД на лету.