Вопрос или проблема
Я создал новую RHEL 8.10 x86_64 с жесткой настройкой CIS и запускаю Singularity/Apptainer на системе, но она зависает на этапе mountGeneric() Монтирование /var/lib/apptainer/mnt/session/fuse/0 в /var/lib/apptainer/mnt/session/final/tmp. Я отключил службу аудита и удалил все правила аудита из системы, и это сработало. Вопрос: почему правила аудита могут блокировать движок Singularity/Apptainer? Как мы можем исключить Singularity/Apptainer из мониторинга аудита?
Ответ или решение
Проблема с монтированием FUSE внутри контейнера Apptainer на системе RHEL 8.10 с жесткой настройкой CIS
При использовании Singularity (также известного как Apptainer) в системе RHEL 8.10, наказанной по стандарту CIS, может возникнуть проблема с монтированием FUSE, когда система зависает на этапе mountGeneric. В данном случае, проблема была устранена отключением службы аудита и удалением всех правил аудита. Важно понять, почему правила аудита могут блокировать работу Singularity/Apptainer и как можно исключить этот инструмент из аудита.
Причины блокировки Singularity/Apptainer службой аудита
-
Правила аудита: Служба аудита в Linux предназначена для отслеживания действий в системе и мониторинга доступа к критически важным файлам и процессам. Когда служба аудита активно работает, она может перехватывать операции монтирования файловых систем, включая те, которые выполняются через FUSE (Filesystem in Userspace). Если правила аудита настроены на отслеживание операций монтирования (например, с использованием правил
-a always,exit), это может привести к конфликтам, где Apptainer не может завершить необходимые операции и зависает. -
Неправильные настройки: Даже если правила аудита написаны правильно, некоторые специфические ограничения, установленные в конфигурации CIS, могут также вызывать проблемы с совместимостью. Например, частые инициализации монтирования FUSE могут считаться нежелательными с точки зрения политики безопасности, в связи с чем они могут блокироваться.
-
Перегрузка системы: При активации службы аудита может наблюдаться значительная нагрузка на систему, так как каждое действие, попадающее под действие правил аудита, должно обрабатываться и записываться. Это может замедлить выполнение операций, необходимых для работы Singularity/Apptainer.
Решение: Исключение Singularity/Apptainer из аудита
Чтобы избежать конфликтов между Servis Auditing и Apptainer/Singularity, необходимо внести изменения в настройки аудита, что позволит исключить процесс Singularity из мониторинга:
-
Добавление правил исключения: Вы можете добавить правила в конфигурацию аудита, которые будут исключать монтирования, которые инициируются Singularity. Например, вы можете добавить следующее правило в файл конфигурации аудита (обычно это
/etc/audit/audit.rules):-a always,exit -F arch=b64 -S mount -F pid!=<PID_Singularity> -k ignore_singularityЗдесь
<PID_Singularity>— это идентификатор процесса Singularity, который можно получить при запуске командыps. -
Тестирование: После внесения изменений рекомендуется перезапустить службу аудита, а затем протестировать функциональность Apptainer на создание и использование контейнеров. Это поможет удостовериться в том, что исключения применяются и проблема монтирования исчезла.
-
Документация: Важно вести документацию всех изменений, которые вносятся в конфигурацию аудита, чтобы другие администраторы системы могли быстро адаптироваться к изменениям и понимать, почему определенные правила были исключены.
Заключение
Решение проблемы с зависанием Singularity/Apptainer при монтировании FUSE на системе RHEL 8.10 с жесткой настройкой CIS заключается в корректной настройке сервисов аудита. Практика исключения определённых процессов из мониторинга позволяет обеспечить стабильную работу контейнеризации при соблюдении стандартов безопасности. Не оставляйте без внимания возможность тестирования всех изменений и документирования процесса, чтобы обеспечить отказоустойчивость и безопасность вашего IT-окружения.