Азбука безопасности в Kubernetes: аутентификация, авторизация, аудит

[VolCh]

А есть рекомендации по пользователям в рамках обычной разработки (деплой на кластер с локальной машины) и CI/CD? Не могу определиться лучше давать дженкинсу/гитлабу/… отдельного пользователя (а может нескольких для разных этапов) или делать от имени пользователя, запушившего в репозитории изменения? Второе вроде правильней с точки зрения расследования инцидентов. Но пока до конца не понимаю как просто сделать аутентификацию сквозную

[seasadm]

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

[VolCh]

Спасибо. В какие-то неймспейсы планируется деплой напрямую, в какие-то (продакшен) исключительно через CI/CD. Там и через пуш в гит, и через запуск задач в дженкинсу Расследования нужны только в продакшен.

[seasadm]

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

[VolCh]

Тут скорее требования безопасности прежде всего, очень чувствительные данные ходят и хочется показать аудиту, что у нас всё, что касается прода, логируется.

[artzcom]

В какие-то неймспейсы планируется деплой напрямую

Такое лучше совсем не разрешать)

Смысл заведения пользователей каждому разработчику есть когда разработчики работают с кластером самостоятельно напрямую

Тут скорее имелось ввиду, что разработчики иногда пытаются попасть с контейнер, чтобы выполнить там ту или иную консольную команду. Ну и попав в кластер, могут получить некий доступ, который им не был предназначен. Оставить какие либо не «хорошие» артефакты. Вот это и нужно логировать.

[VolCh]

Такое лучше совсем не разрешать)

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

[artzcom]

Для каждого деплоя делать коммит и пуш очень не хочется

Но вам же нужно собрать контейнер, для того чтобы задеплоить. И тут билдсервер может лучше подходить для данной задачи, как минимум из-за доступных ресурсов, и ширины канала. При «правильно» настроенном CICD, коммитнуть и увидеть результат уже задеплоенным, будет быстрее, чем делать это локально с последующим ручным запуском.

что мы в целом настоятельно рекомендуем не перезаписывать историю после пуша без крайней необходимости и уведомления всех.

Тут кажется, что вам нужно сменить ваш gitflow. Изменять историю в «статичных» ветках типа master/develop, нужно запретить, сделав их protected. Разработчикам нужно пользоваться фича ветками. И когда работа готова, менять историю (вероятно речь про склейку коммитов) и делать пул/мерж реквесты в те самые ветки. Так история будет всегда читаемой и не будет конфликтов у разработчиков.