➡️ PHP-разработчик.

Другой кандидат, без камеры, не смог даже с поиском ответить на простые вопросы по Symfony. Зато было слышно, как он ищет ответы. Серьезно, после каждого вопроса был слышен стук клавиш.

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

Мораль: собеседование — это стресс, готовьтесь заранее и помните, что все, что вы пишете в резюме, может всплыть! Поэтому следующая часть поста для тех, кто не собеседует, но проходит собеседования.

Как составлять резюме

🟠 Пишите правду, но не забывайте про ключевые слова, потому что ваше резюме сначала проверит машина. Если не забракуют, смотрим дальше.

🟠 Краткость важна, потому что если вам повезло и вы дошли до HR, человек должен сразу увидеть достаточный уровень компетенции и соответствия должности, не тратя время на вчитывание в N страниц текста.

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

🟠 Если вы написали, что «5 лет работал с Redis», будьте готовы рассказать не только про GET и SET, но и про тонкости работы со streams (если использовали) и как оптимизировать работу на больших RPS (pipelining, если работали с ним).

Речь конечно же про разработчика, а не про OPS позицию. И нет, это снова не про академические знания. Можете написать в комментариях свои за и против. Но далеко не всем удалось поработать на сложных проектах с большими нагрузками, это справедливо, и не все пробовали использовать каждый инструмент на полную катушку.

Если стоит задача нанять человека под конкретный стек с конкретным уровнем сложности задач, то очевидно, что спрашивать вещи, которые ему гарантированно не пригодятся сейчас на работе, стоит только чтобы оценить уровень компетенций. Никто не станет отказывать из-за того, что вы не знаете, как правильно готовить X, с которым команда сама полгода назад познакомилась.

Не страшно говорить, что с чем-то не работали. Честность ценится, а научиться всегда можно.

На что лично я обращаю внимание на собеседованиях

➡️ Насмотренность и кругозор. Если кандидат не знает/не помнит нюансов использования конкретного инструмента, но может в правильном направлении рассуждать относительно своего опыта, то есть большая вероятность, что за пару запросов в google/ChatGPT он сможет найти ответ, что он и сделает в реальном проекте. Бизнесу важно решать проблемы и получать прибыль, а не нанимать тех, кто может по памяти вспомнить все сложности настройки очередной вундервафли.

В заключение: Собеседование — это двусторонний процесс. Не только компания выбирает кандидата, но и кандидат выбирает компанию (на самом деле кандидат скорее команду выбирает, если речь о больших компаниях). Будьте честны, объективны (на самом деле мы скорее всегда субъективны) и, главное, помните: все мы люди, все мы ошибаемся. Даже при деплое в production. Удачи!

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

➡️ Посмотрим на примере audit policy и seccomp profiles, как можно повысить безопасность кластера.

Второе видео — завтра. Не переключайтесь!

А пока жду ваших вопросов в комментариях ⬇️

Как связаны 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%, пока оно включено 🙂)