Безопасность
Хотя Celery разрабатывался с учётом требований безопасности, его следует считать небезопасным компонентом.
В зависимости от вашей политики безопасности вы можете предпринять различные шаги, чтобы сделать установку Celery более безопасной.
Крайне важно защитить брокер от нежелательного доступа, особенно если он доступен из публичной сети. По умолчанию рабочие процессы доверяют тому, что полученные от брокера данные не были изменены. Информацию о том, как повысить надёжность соединения с брокером, см. в разделе Подписание сообщений.
Первой линией защиты должен стать межсетевой экран перед брокером, разрешающий доступ только машинам из белого списка.
Имейте в виду, что в реальных условиях часто случаются как ошибки настройки межсетевого экрана, так и его временное отключение. Надёжная политика безопасности предусматривает мониторинг оборудования межсетевого экрана, чтобы обнаруживать его отключение — случайное или преднамеренное.
Иными словами, не следует безоговорочно доверять и межсетевому экрану.
Если ваш брокер поддерживает тонкую настройку контроля доступа, как RabbitMQ, рассмотрите возможность включить эту функцию. Например, см. http://www.rabbitmq.com/access-control.html.
Если ваш брокер поддерживает такую возможность, вы можете включить сквозное SSL-шифрование и аутентификацию с помощью broker_use_ssl.
В Celery термин «клиент» обозначает всё, что отправляет сообщения брокеру, например веб-серверы, запускающие задачи.
Надёжная защита брокера не имеет значения, если через клиента можно отправлять произвольные сообщения.
[Здесь нужно добавить текст]
По умолчанию задачи, выполняющиеся внутри рабочего процесса, обладают теми же правами, что и сам рабочий процесс. Это относится к таким ресурсам, как память, файловые системы и устройства.
Исключение составляет использование пула задач на основе multiprocessing, который в настоящее время используется по умолчанию. В этом случае задача получит доступ к любой памяти, скопированной в результате вызова fork(), а также к содержимому памяти, записанному родительскими задачами в том же дочернем процессе рабочего процесса.
Ограничить доступ к содержимому памяти можно, запуская каждую задачу в отдельном подпроцессе (fork() + execve()).
Ограничить доступ к файловой системе и устройствам можно с помощью chroot, jail, песочницы, виртуальных машин или других механизмов, предоставляемых платформой либо дополнительным программным обеспечением.
Также обратите внимание, что любая задача, выполняемая в рабочем процессе, будет иметь такой же доступ к сети, как и машина, на которой она запущена. Если рабочий процесс находится во внутренней сети, рекомендуется добавить правила межсетевого экрана для исходящего трафика.
Начиная с версии 4.0, сериализатором по умолчанию является JSON. Однако, поскольку он поддерживает лишь ограниченный набор типов, для сериализации можно рассмотреть возможность использования pickle.
Сериализатор pickle удобен тем, что может сериализовать почти любой объект Python, а при определённых усилиях — даже функции. Но по тем же причинам pickle по своей сути небезопасен [*], поэтому его следует избегать, если клиенты не являются доверенными или не прошли аутентификацию.
Вы можете запретить недоверенное содержимое, указав белый список допустимых типов содержимого в параметре accept_content:
Добавлено в версии 3.0.18.
Примечание
Этот параметр впервые поддерживается в версии 3.0.18. В более ранних версиях он будет просто проигнорирован, поэтому убедитесь, что используете версию с его поддержкой.
accept_content = ['json']
Принимается список имён сериализаторов и типов содержимого, поэтому можно также указать тип содержимого для json:
accept_content = ['application/json']
В Celery также есть специальный сериализатор auth, который проверяет подлинность сообщений между клиентами и рабочими процессами Celery, гарантируя, что сообщения отправлены доверенными источниками. С помощью криптографии с открытым ключом сериализатор auth может проверять подлинность отправителей. Чтобы включить эту возможность, ознакомьтесь с разделом Подписание сообщений.
Celery может использовать библиотеку https://pypi.org/project/cryptography/ для подписания сообщений с помощью криптографии с открытым ключом: сообщения, отправленные клиентами, подписываются закрытым ключом, а затем проверяются рабочим процессом с помощью открытого сертификата.
В идеале сертификаты должны быть подписаны официальным центром сертификации, однако они также могут быть самоподписанными.
Чтобы включить эту возможность, настройте параметр task_serializer, указав сериализатор auth. Чтобы рабочие процессы принимали только подписанные сообщения, задайте для accept_content значение [‘auth’]. Чтобы дополнительно подписывать протокол событий, задайте для event_serializer значение auth. Также необходимо настроить пути к закрытым ключам и сертификатам в файловой системе: соответственно параметры security_key, security_certificate и security_cert_store. Алгоритм подписи можно настроить с помощью параметра security_digest. Если используется зашифрованный закрытый ключ, пароль можно задать с помощью параметра security_key_password.
После настройки этих параметров также необходимо вызвать функцию celery.setup_security(). Обратите внимание, что это также отключит все небезопасные сериализаторы, чтобы рабочий процесс не принимал сообщения с недоверенными типами содержимого.
Ниже приведён пример настройки с использованием сериализатора auth, где файлы закрытого ключа и сертификата находятся в каталоге /etc/ssl.
app = Celery()
app.conf.update(
security_key='/etc/ssl/private/worker.key'
security_certificate='/etc/ssl/certs/worker.pem'
security_cert_store='/etc/ssl/certs/*.pem',
security_digest='sha256',
task_serializer='auth',
event_serializer='auth',
accept_content=['auth']
)
app.setup_security()
Примечание
Относительные пути не запрещены, но для этих файлов рекомендуется использовать абсолютные пути.
Также обратите внимание, что сериализатор auth не шифрует содержимое сообщений, поэтому при необходимости эту функцию нужно включить отдельно.
Самое важное в защите систем от злоумышленников — возможность обнаружить факт компрометации системы.
Журналы обычно являются первым местом, где ищут свидетельства нарушений безопасности, но они бесполезны, если их можно подделать.
Хорошее решение — настроить централизованное ведение журналов на выделенном сервере. Доступ к нему следует ограничить. Помимо хранения всех журналов в одном месте, правильная настройка сервера затруднит злоумышленникам подделку журналов.
Это достаточно просто настроить с помощью syslog (см. также syslog-ng и rsyslog). Celery использует библиотеку logging и уже поддерживает работу с syslog.
Совет для особо осторожных: отправляйте журналы по UDP и перережьте передающую часть сетевого кабеля сервера журналов :-)
Tripwire — инструмент обеспечения целостности данных (ныне коммерческий), имеющий несколько реализаций с открытым исходным кодом. Он хранит криптографические хеши файлов в файловой системе, чтобы администраторы получали уведомления об их изменении. Таким образом, когда ущерб уже нанесён и система скомпрометирована, можно точно определить, какие файлы изменили злоумышленники (файлы паролей, журналы, бэкдоры, руткиты и так далее). Часто это единственный способ обнаружить вторжение.
К некоторым реализациям с открытым исходным кодом относятся:
Файловая система ZFS также имеет встроенные механизмы проверки целостности, которые можно использовать.
Сноски
Copyright © 2017-2026 Asif Saif Uddin, core team & contributors. All rights reserved.
Celery is licensed under The BSD License (3 Clause, also known as the new BSD license). The license is an OSI approved Open Source license and is GPL-compatible.
https://docs.celeryq.dev/en/stable/userguide/security.html
