Содержание: Душераздирающая скорость роста auth.log на хостах с neutron-plugin-openvswitch-agent. Анализ причин, метод устранения. Немного про работу sudo, PAM и его сессии.



О чём пойдёт речь? Openstack — платформа для построения облаков. Neutron — название его подсистемы отвечающей за сеть, модной хипстерской вебдванольной, cчитающейся более совершенной и функциональной, чем первая попытка под названием nova-networking. openvswitch-plugin — это плагин к neutron, реализующий его функциональность при помощи Open vSwitch — программного коммутатора, позволяющего делать умные штуки, вроде GRE-туннелей, бондинга и мирроринга портов, наложение правил на порт внутри виртуального коммутатора в стиле iptables и т.д.

neutron-openvswitch-plugin-agent — одна из компонент этого плагина, работающая на всех хостах, которые имеют хоть какое-то реальное отношение к передаче сетевого трафика виртуалок. Иными словами, это все compute-узлы (там, где работают виртуалки), networking-узлы (которые делают «интернет» для виртуалок). Из списка выпадают только сервера API и прочие служебные сервера. С учётом, что большая часть облака состоит из compute + networking, можно, слегка огрубляя, говорить, что этот neutron-openvswitch-plugin-agent установлен на всех хостах. Logstash — система централизованной сборки логов, Elasticsearch — база данных для работы с этими логами.

Для своевременной реакции на проблемы ПО, все логи всех приложений должны собираться и анализироваться системой мониторинга. Подробнее про это у нас уже было написано. Однако, даже хорошего может быть слишком много. Быстро обнаружилось, что большая часть собираемого с хостов — нелепые сообщения следующего вида:

server sudo:  neutron : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf ovs-vsctl --timeout=2 --format=json -- --columns=name,external_ids list Interface
server sudo: pam_unix(sudo:session): session opened for user root by (uid=108)
server sudo: pam_unix(sudo:session): session closed for user root
server sudo:     nova : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/nova-rootwrap /etc/nova/rootwrap.conf chown 107 /var/lib/nova/instances/_base/421f0808ac5dd178bc574eff6abe8df949edc319
server sudo: pam_unix(sudo:session): session opened for user root by (uid=107)
server sudo: pam_unix(sudo:session): session closed for user root

Эти сообщения повторялись каждые две (!) секунды. С каждого сервера, на котором есть агент. Получается, что с каждой сотни серверов мы будем получать по 730 Гб мусора в год. Логи собираются в Elasticsearch, то есть, это, пардон, терабайты в базе данных. Удачи в query-запросах, так сказать.

С одной стороны весь этот хлам так и просится на отключение.

С другой стороны, полное отключение auth.log или его жёсткая локальная ротация — плохое решение, потому что информация о подозрительной активности должна собираться и храниться как можно тщательнее, причём, желательно, вдалеке от жадных ручек скомпрометированного хоста (ежели такой объявится).

Помимо neutron-plugin-openvswitch-agent рядом ещё засветилась и nova-compute (управлялка виртуализаторами в Openstack), хоть и не так часто.

PAM и его сессии

Вероятнее всего, многие читатели пользуются sudo. Вероятнее всего, многие из тех, кто пользуются sudo, особо не задумываются, что происходит при его запуске.

Когда sudo спрашивает пароль, оно может запросить аутентификацию у пользователя. Чаще всего это пароль, но, например, у меня на ноутбуке — это сканер отпечатков пальцев (который не используется при логине, т.к. пароль при логине расшифровывает диск, но отлично подходит для безопасного sudo). Чтобы не реализовывать код для работы с паролями и прочими вещами в каждой программе, был создан PAM — система аутентификации пользователя, позволяющая проверять, что пользователь знает пароль, без самостоятельного написания парсера /etc/shadow и поддержки всех других видов авторизации (включая LDAP, kerberos, OpenID, OTP и любые другие безумные вещи, которые только придумают).

PAM-сессии — это набор ритуалов, которые выполняет PAM при логине пользователя. Среди всего прочего, в ритуал входит запись в auth.log.

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

Подробнее про PAM, историю его возникновения и принципы работы есть на сайте IBM, для дотошных — Linux-PAM System Administration Guide.

Но зачем так часто?

Напомню, проблема состоит в том, что записи в логах от sudo и pam_session происходили почти постоянно — каждые две секунды.

Что за сообщения про pam_session мы уже выяснили. Осталось выяснить, зачем neutron'у (и немножко nova) запускать что-то так часто, да ещё и с sudo?

В модели Openstack'а компоненты не особо стремятся изучать тонкости нижележащих технологий. Вместо того, чтобы получать информацию об изменениях от ovs-vswitchd, libvirtd и т.д., и долго разбираться «что бы это могло значить и надо ли на это реагировать?» используется куда более грубый и эффективный подход: когда api-сервер какой-либо подсистемы хочет узнать состояние сервиса, он посылает ему через очередь сообщений запрос — а сервис, в свою очередь, запрашивает у использующихся программ их текущее состояние.

На выходе сервер имеет кучу информации: во-первых, что сервис ещё жив (heartbeat'ы), во вторых, информацию о текущей конфигурации. Без всяких нюансов «пропустили Очень Важное Обновление Состояния».

Для адекватной работы neutron'а ему надо знать состояние портов. В контексте openvswitch-plugin-agent'а — это запуск ovs-vsctl show и им подобных для получения текущего состояния всех портов.

К сожалению, это требует привилегий.

Для управления привилегиями в Openstack используется свой врапер — root-wraper, который осуществляет более тонкую проверку аргументов для запуска, чем обычное sudo. Но сам root-wraper написан на Питоне (как и всё в Openstack), а на интерпретируемые файлы ставить suid нельзя. В качестве простого и разумного решения root-wraper вызывается как sudo root-wraper.

И что делать?

Наша цель:

1. Не сохранять информацию о выполнении root-warp пользователями nova/neutron через sudo
2. Сохранять всю остальную информацию.

Первый пункт сводится к двум независимым вопросам: отключить запись информации от sudo, и отключить запись информации от pam_session.

Предварительно: если используете старые дистрибутивы, обновите sudo до версии 1.8.7 или новее (Ubuntu 12.04 идёт с 1.8.3, в Ubuntu 14.04 уже всё хорошо).

Далее — для neutron, в файле /etc/sudoers.d/neutron_sudoers заменяем строчки:

- Defaults:neutron !requiretty
+ Defaults:neutron !requiretty, !syslog, !pam_session

Для nova изменения аналогичные, в файле /etc/sudoers.d/nova_sudoers.

Краткая справка по синтакису sudoers, для тех, кому не нравится BNF из man-страниц — восклицательный знак инвертирует значение, Defaults: применяются к конкретной секции.

• syslog — включает логинг в syslog, !syslog, соответственно, отключает.
• pam_session — указывает создавать новую сессию PAM, !pam_session — говорит не создавать новую сессию. Именно для pam_session нам и потребовалась новая версия sudo.

Управление частотой опроса neutron

Очевидная мысль — а давайте понизим частоту опроса? С практической точки зрения снижение частоты означает увеличение интервала между «сделали» и «увидели изменения». Если две секунды кажутся слишком частыми, то можно сделать, например, десять. Но ставить туда минуту — это уже перебор (с интерактивностью беда будет). При этом десять секунд нас особо не спасут — вместо 43 тысяч вызовов в сутки (на каждый сервер) у нас будет почти 9 тысяч.

За снижение частоты это отвечает переменная конфига у neutron-server: report_interval (в секундах).