Возвращаемся к нашему квизу, который вызвал бурные обсуждения в чате. 59% человек посчитало, что схема является безопасной с точки зрения управления секретами. Как итог они оказались неправы. Дело в том, что упомянутый плагин
сredentials-binding может позволить разработчикам извлечь секреты даже если секреты используются во внешнем хранилище Vault. Но дело даже не в плагине, а в самой возможности разработчика влиять на конфигурацию сборки, ведь с тем же успехом можно извлечь секреты напрямую из $JENKINS_HOME/credentials.xml и $JENKINS_HOME/secrets воспользовавшись hudson.util.Secret.decrypt или сторонними инструментами.Так как разработчик имеет доступ к конфигурации сборки и ее запуску в Jenkins, то помимо извлечения секретов может быть поднят reverse shell или вызван DoS всего сборочного конвейера. Все зависит от сетевых доступов и прав на агенте сборки.
Какой же вывод? Как ни странно, то компенсирующей мерой сделать так, чтобы конфигурация джобы тащилась из внешнего Jenkinsfile, который будет расположен в Git, а разработчик мог эту джобу только запустить. Jenkinsfile на стороне Git-репозитория в свою очередь будет защищен принудительным merge approval и другими мерами, которые могут быть реализованы на стороне SCM.
#dev #ops #talks #attack