у меня есть airflow сервер, где airflow у пользователя установлен домашний каталог /opt/airflow. Здесь хранятся файлы и конфигурации, относящиеся к приложениям. Теперь у меня есть несколько серверов, airflow Пользователь должен подключиться к SSH и запускать команды. Приложение Airflow не установлено на этих серверах, но есть сценарии, airflow пользователю нужно запустить.
Какая домашняя папка должна быть установлена для этих серверов без воздушного потока? обратите внимание, нельзя просто войти в ящик как airflow user, и они не должны использовать его для чего-либо, кроме пары скриптов.
Чтобы разработать модель безопасности для этого, потребуется гораздо больше усилий и информации, чем вы предоставили здесь.
(и, кстати, SELinux - это самый последний то, что вам следует искать для безопасного, поддерживаемого и доступного решения)
Какая бы соответствующая домашняя папка была установлена для этих серверов без воздушного потока?
Он должен соответствовать вашему соглашению об учетных записях служб. Это должно быть основано на требуемых характеристиках ввода-вывода и изоляции от других пользователей системы. В большинстве случаев достаточно просто добавить их в / home.
нельзя просто войти в ящик как пользователь воздушного потока
Я не понимаю, что вы пытаетесь нам здесь сказать. Если вы хотите автоматизировать запуск сценария в удаленной системе, то использование ssh с парами ключей на сегодняшний день является самым простым решением. Использование как пар ключей, так и паролей (при необходимости) на одном сервере OpenSSH немного сложнее, чем только один метод аутентификации, но все же выполнимо. Если вы не хотите, чтобы реальные пользователи использовали учетную запись, не сообщайте им пароль и не запрещайте доступ к закрытому ключу ssh с разрешениями (что openssh делает по умолчанию).
Если вы идете по пути туннелирования вызова через ssh, вам следует взглянуть на параметры для ограниченных оболочек (rbash, rssh).
они не должны использовать его для чего-либо, кроме пары скриптов
Насколько серьезно это нужно обеспечивать? Установить разрешения для всех исполняемых файлов будет сложно. Вы можете chroot оболочки входа в систему, чтобы предотвратить доступ пользователя к большинству команд - и использовать файловую систему наложения, чтобы выборочно сделать доступными те, которые требуются для скрипта. В качестве предпочтения вы должны убедиться, что у пользователя нет разрешения на чтение / запись где угодно, и определить доступ к скриптам через sudo.
Вместо того, чтобы использовать соединение ssh, вы можете общаться с демоном, работающим на цели, для выполнения задачи.
К сожалению, очень много руководств по "безопасности" рекомендуют отключать [x] inetd - когда разделение привилегий является ключевым инструментом для построения безопасных систем. (Я еще не начал пить systemd kool-aid, но у него есть собственные возможности для сервисов по запросу). Однако для этого вам потребуется создать свой собственный уровень аутентификации. Но простая разработка, решающая проблему аутентификации, - это настроить станнель экземпляр, чтобы принимать только сертификаты клиентов, выданные серверу воздушного потока и exec ваш сценарий - или средство мультиплексирования сценариев:
#!/bin/bash
read USERCMD
USERCMD=`basename "${USERCMD}"`
if [ -x "${HOME}/bin/${USERCMD}" ]; then
"${HOME}/bin/${USERCMD}"
fi
exit
... и используйте клиентский stunnel на сервере воздушного потока или openssl s_client для подключения.
Вы можете разместить домашние каталоги где угодно.
Для простоты и разумности я предлагаю, чтобы дом для данного пользователя был одинаковым на всех хостах. Вы можете сохранить его в центральном (LDAP) каталоге.
Использование ключей SSH приведет к хранению потенциально конфиденциальных учетных данных где-то за пределами обычного / home. Обязательно закрепите их должным образом. Убедитесь, что sshd может получить к ним доступ, пометив их соответствующей политикой SELinux.