На наших машинах запущены различные службы, например, cassandra, datadog и т. д.
Иногда нам необходимо изменить конфигурацию, и мы хотим автоматизировать распространение файлов конфигурации и перезапуски.
Мы используем Jenkins для автоматизации рабочего процесса для нашего прикладного программного обеспечения и думали использовать его также для сервисов. Мы не хотим, чтобы сервер, на котором работает Jenkins, имел удаленный root-доступ (или даже sudo) к хост-серверу.
Мне было интересно, можем ли мы безопасно изменить владельца /etc/cassandra на cassandra, /etc/datadog на dd-agent и т. д., потому что это помогло бы нам автоматизировать. (На самом деле, рекомендуется ли, чтобы такие папки/файлыдолженпринадлежать соответствующему пользователю, и что наличие root в качестве владельца неправильно?)
решение1
Идея этого каталога заключалась в том, что /etc
каталог содержит всеобщесистемныйконфигурация - в отличие от конфигурации каждого отдельного пользователя, которая в большинстве случаев находится $HOME/.config
где-то ниже. Поскольку общесистемная конфигурация влияет на всех пользователей, то правильно, что эти файлы принадлежат root.
Теперь, я не знаю вашей системы, но вы, вероятно, запускаете cassandra и т. д. один раз на систему, и поэтому у вас, вероятно, нет необходимости в индивидуальном файле конфигурации пользователя. Я не вижу никаких подводных камней в изменении владельца этих файлов / подкаталогов, за исключением того, что это противоречит тому, как это было спроектировано. (Если только вы не измените владельца основного /etc
каталога!)
Лично я бы создал каталог экземпляра (вероятно, в его домашней папке) и использовал бы конфигурацию, хранящуюся там, но это уже на ваше усмотрение.
решение2
Root не должен быть владельцем файлов конфигурации etc, относящихся к приложениям. Элегантное решение было бы примерно таким: приложение datadog запускается пользователем datadog, а файлы конфигурации принадлежат datadog и группе datadog. Но теперь появляется jenkins, и ему нужно посмотреть/отредактировать некоторые файлы в /etc/datadog, но, возможно, не все.
Итак, мы создаем новую группу под названием "datadogjenkins" и делаем ОБА datadog и jenkins членами этой группы. Затем мы меняем ownerGROUP для файлов/папок, которые jenkins должен читать/писать/выполнять, на нашу новую группу.
Теперь и datadog, и jenkins могут получить доступ к этим ресурсам. И ни одному из них не нужно повышать привилегии до root. И мы можем не допускать jenkins к тому, что ему не нужно видеть, на случай, если jenkins будет скомпрометирован.
Надеюсь, я достаточно хорошо объяснил.