Comments 8
А есть рекомендации по пользователям в рамках обычной разработки (деплой на кластер с локальной машины) и CI/CD? Не могу определиться лучше давать дженкинсу/гитлабу/… отдельного пользователя (а может нескольких для разных этапов) или делать от имени пользователя, запушившего в репозитории изменения? Второе вроде правильней с точки зрения расследования инцидентов. Но пока до конца не понимаю как просто сделать аутентификацию сквозную
Спасибо. В какие-то неймспейсы планируется деплой напрямую, в какие-то (продакшен) исключительно через CI/CD. Там и через пуш в гит, и через запуск задач в дженкинсу Расследования нужны только в продакшен.
От себя хочу заметить, что в методологии DevOps нет цели разобраться и наказать сотрудника, допустившего ошибку. Это заменяется целью организовать работу таким образом, чтобы ошибки были в принципе не возможны.
В какие-то неймспейсы планируется деплой напрямую
Такое лучше совсем не разрешать)
Смысл заведения пользователей каждому разработчику есть когда разработчики работают с кластером самостоятельно напрямую
Тут скорее имелось ввиду, что разработчики иногда пытаются попасть с контейнер, чтобы выполнить там ту или иную консольную команду. Ну и попав в кластер, могут получить некий доступ, который им не был предназначен. Оставить какие либо не «хорошие» артефакты. Вот это и нужно логировать.
Такое лучше совсем не разрешать)
Неймспейс типа development исключительно для задач разработки. Для каждого деплоя делать коммит и пуш очень не хочется, особенно учитывая, что мы в целом настоятельно рекомендуем не перезаписывать историю после пуша без крайней необходимости и уведомления всех.
Для каждого деплоя делать коммит и пуш очень не хочется
Но вам же нужно собрать контейнер, для того чтобы задеплоить. И тут билдсервер может лучше подходить для данной задачи, как минимум из-за доступных ресурсов, и ширины канала. При «правильно» настроенном CICD, коммитнуть и увидеть результат уже задеплоенным, будет быстрее, чем делать это локально с последующим ручным запуском.
что мы в целом настоятельно рекомендуем не перезаписывать историю после пуша без крайней необходимости и уведомления всех.
Тут кажется, что вам нужно сменить ваш gitflow. Изменять историю в «статичных» ветках типа master/develop, нужно запретить, сделав их protected. Разработчикам нужно пользоваться фича ветками. И когда работа готова, менять историю (вероятно речь про склейку коммитов) и делать пул/мерж реквесты в те самые ветки. Так история будет всегда читаемой и не будет конфликтов у разработчиков.
Азбука безопасности в Kubernetes: аутентификация, авторизация, аудит