2026/9/20 20:48:09
FEATURED · 精选文章 
Celery 安全加固实战broker 防护、auth 消息签名与入侵检测指南【免费下载链接】celeryDistributed Task Queue (development branch)项目地址: https://gitcode.com/gh_mirrors/ce/celery本文是 Celery 分布式任务队列安全配置的实操指南核心围绕官方安全文档docs/userguide/security.rst展开首先分析 broker、client、worker 三大威胁面然后重点讲解从 pickle 风险到accept_content白名单的序列化器安全策略并深入拆解基于公钥密码学的auth消息签名序列化器——包括security_key、security_certificate、security_cert_store等全部配置项、setup_security()的调用时机与底层校验逻辑最后给出日志与文件完整性层面的入侵检测方案。读完本文你将能够为生产环境的 Celery 集群配置签名 白名单双重防护并具备排查安全配置问题的源码级视野。引言把 Celery 当作不可信组件来防护Celery 官方文档在 docs/userguide/security.rst 的开篇就给出了一个重要定位While Celery is written with security in mind, it should be treated as an unsafe component.也就是说虽然 Celery 在编写时考虑了安全性但任何部署都应把它当作一个不安全组件来对待。具体的加固程度取决于你的安全策略Security Policy本文按照官方文档的脉络从威胁面分析 → 序列化器安全 → 消息签名 → 入侵检测四个层次逐步展开。威胁面分析Broker、Client、WorkerCelery 系统的信任模型可以拆成三个角色broker消息中间件、client发送消息的一方例如触发任务的 Web 服务器、worker消费并执行任务的进程。官方文档建议对三者分别设防。Broker第一道防线是防火墙Broker 必须防止未授权访问尤其是当它暴露在公网时。默认情况下worker 会信任从 broker 拿到的数据未被篡改因此 broker 本身的可信度直接决定整个系统的安全下限。官方的加固建议分三层防火墙白名单在 broker 前面放置防火墙只允许白名单机器访问。但文档同时提醒防火墙误配置、被临时关闭在现实中非常常见安全策略应当包含对防火墙设备的监控以便及时发现其被有意或无意关闭——换句话说不能盲目信任防火墙本身。细粒度访问控制如果你的 broker 支持如 RabbitMQ应当启用细粒度的访问控制vhost、用户权限等。端到端 SSL 加密与认证如果 broker 后端支持可以通过broker_use_ssl配置项启用 SSL 加密与认证。该设置的定义位于 celery/app/defaults.py 的 broker 命名空间可配置ca_certs、certfile、keyfile、cert_reqs等 TLS 选项对 Redis、RabbitMQ 等 broker 传输层均适用。关于消息可信度本身可以进一步通过下文消息签名一节让 worker 验证消息来源。Clientbroker 安全不代表消息可信在 Celery 中client指一切向 broker 发送消息的角色典型如发起任务的 Web 服务器。如果攻击者能通过某个客户端任意发送消息那么 broker 再安全也无济于事。因此 client 侧需要认证与授权防止任意消息注入。官方文档在此处明确标注了*[Need more text here]*说明该小节尚待完善——但结合后文可知真正的 client 信任问题正是由auth签名序列化器解决的让 worker 只接受由可信私钥签名的消息。Worker任务的权限边界等于 worker 自身Worker 内执行的任务其默认权限与 worker 进程本身的权限一致涵盖内存、文件系统、设备等资源。这里有几个关键点prefork 池的 fork 语义当前默认的任务池是基于 multiprocessing 的 prefork。在这种模式下任务可以访问fork调用时复制进来的内存也能访问同一 worker 子进程中父任务写入的内存内容。若需严格隔离内存可以改为让每个任务在独立子进程中启动forkexecve。文件系统与设备隔离可以通过chroot、FreeBSD jail、sandboxing、虚拟机或平台提供的其他机制实现。网络访问worker 中执行的任何任务都拥有与运行机器相同的网络访问能力。如果 worker 位于内网建议为出站流量添加防火墙规则防止被攻破的任务作为跳板发起横向攻击。配置层面任务池相关设置在 celery/app/defaults.py 的worker命名空间如worker_pool默认preforkconcurrency 池的具体实现位于 celery/concurrency/prefork.py 与 celery/concurrency/base.py。序列化器安全pickle 的便利与风险默认序列化器与 pickle 风险自 Celery 4.0 起默认序列化器是JSONDEFAULT_TASK_SERIALIZER json见 celery/app/defaults.py。JSON 只支持有限的数据类型因此有些开发者会改用pickle序列化器——它几乎能序列化任意 Python 对象甚至函数非常方便。但正是这种什么都能反序列化的能力使 pickle 天生不安全攻击者构造的恶意 pickle 数据在反序列化时可以执行任意代码。只要 client 不可信或未认证就应当避免使用 pickle。官方文档引用了一篇经典分析见文档脚注来佐证 pickle 的可利用性。因此一个基本原则是在不可信的网络/客户端环境中永远不要让 pickle 数据进入 worker。accept_content白名单机制自 3.0.18 版本起Celery 支持通过accept_content设置只接受白名单中的内容类型更早的版本会忽略该设置需确认运行版本支持。它接受序列化器名称或 content-type 列表# 只接受 json 序列化器按序列化器名称 accept_content [json] # 或者按 content-type 指定 accept_content [application/json]该设置在 celery/app/defaults.py 中的默认值为(json,)。收到白名单之外的 content-type 消息时worker 会直接拒绝从源头阻断 pickle、YAML 等危险序列化器。需要说明的是accept_content只限制接收发送侧序列化器由task_serializer决定默认json。如果你同时希望结果后端也只接受白名单类型可以另行配置result_accept_contentexamples/security/mysecureapp.py 中就将其显式设为[json]。底层实现禁用不安全序列化器accept_content白名单在底层通过 kombu 的disable_insecure_serializers实现。在 celery/security/init.py 中可以看到disable_untrusted_serializers(whitelistNone)直接转调 kombu 的_disable_insecure_serializers(allowedwhitelist)kombu 的不安全序列化器清单包括 pickleapplication/x-python-serialize和 YAMLapplication/x-yaml等。测试用例验证了这一行为调用disable_insecure_serializers([application/json, application/x-python-serialize])后application/x-yaml被禁用而 json、pickle 被豁免而allowedNone时则全部不安全类型都被禁用。这与你下文要调用的setup_security()行为一致——它会自动禁用所有不安全序列化器。消息签名auth 序列化器从原理到实战accept_content只能防住不该有的内容类型却无法证明消息确实来自可信来源。为此Celery 内置了一个特殊的auth序列化器它基于公钥密码学Public-key cryptographyclient 用私钥给消息签名worker 用公钥证书验证签名从而确认消息确实来自可信发送方。签名/验签的底层流程auth序列化器的核心实现在 celery/security/serialization.py 的SecureSerializer类签名serialize先用内部序列化器默认json将数据dumps成 body然后用PrivateKey.sign(body, digest)对序列化后的 body签名——官方注释说明这是为了接收方无需解码内容即可验签避免解码环节的潜在缺陷。随后将signer证书标识、signature、content_type、content_encoding、body 打包并整体 base64 编码。验签deserialize解包出 signature、signer、body 后通过cert_store[signer].verify(body, signature, digest)校验签名校验通过后才loads反序列化。配套的密码学组件celery/security/key.pyPrivateKey负责加载 PEM 私钥可选密码解密并执行签名。注意它只支持 RSA 私钥非 RSA 会抛出ValueError签名使用 PSS 填充 MGF1。celery/security/certificate.pyCertificate加载并校验 X.509 证书同样只支持 RSA 公钥提供get_id()issuer serial number 唯一标识与verify()会先检查证书是否过期过期抛SecurityError。FSCertStore则从文件系统批量加载证书传入目录会被自动补成dir/*也支持直接传 glob如/etc/ssl/certs/*.pem加载时发现过期证书会直接抛SecurityError。celery/security/utils.pyget_digest_algorithm(digest)把sha256这类字符串转成 cryptography 的哈希对象reraise_errors把密码学异常统一包装成 Celery 的SecurityError便于上层统一处理。证书的身份标识与存储逻辑在CertStore中以get_id()为键存放证书重复添加或未知证书都会抛SecurityError——这保证了验签时只能使用你预先放入证书库的可信证书。前置条件安装 cryptographyauth序列化器依赖cryptography库。在 celery/security/init.py 中import cryptography失败会直接抛ImproperlyConfigured提示$ pip install cryptography全部相关配置项配置项说明默认值task_serializer任务序列化器需设为authjsonaccept_content只接受签名消息需设为[auth](json,)event_serializer事件协议签名可设为authjsonsecurity_key私钥文件路径无security_key_password加密私钥的密码bytes类型无security_certificate自身 X.509 证书路径无security_cert_store可信证书目录/glob用于验签无security_digest签名摘要算法如sha256sha256这些安全设置在 celery/app/defaults.py 的security命名空间中统一定义certificate、cert_store、key、key_password、digest默认DEFAULT_SECURITY_DIGEST sha256配置时以security_前缀引用即security_key、security_certificate、security_cert_store、security_key_password、security_digest。security_digest的值会传给get_digest_algorithm并大写后从cryptography.hazmat.primitives.hashes中取值因此支持该库提供的摘要算法名。setup_security()唯一的启用入口配置好上述设置后还必须调用app.setup_security()全局操作会影响所有应用实例。其签名与实现在 celery/app/base.py 与 celery/security/init.py执行顺序如下禁用不安全序列化器调用_disable_insecure_serializers(allowed_serializers)可用allowed_serializers参数豁免白名单项。校验配置自洽要求task_serializer auth且accept_content [auth]否则抛ImproperlyConfigured错误信息见SETTING_MISSING——文档明确如果签名后不验签签名就毫无意义。校验密钥/证书路径齐全security_key、security_certificate、security_cert_store三者缺一不可否则抛ImproperlyConfigured见SECURITY_SETTING_MISSING。注册 auth 序列化器读取私钥与证书内容调用register_auth()把SecureSerializer注册进 kombu 序列化器注册表content-type 为application/data、编码为utf-8并把默认序列化器切换为auth。test_security.py 完整覆盖了这些分支正常配置可成功 setuptask_serializer不是auth、accept_content不含auth、缺少密钥/证书路径、未安装 cryptography 等场景均抛ImproperlyConfigured同时验证了setup_security确实会禁用 json/pickle 等不安全序列化器。端到端配置示例官方文档给出的配置示例docs/userguide/security.rst如下——注意原文代码块中缺失的逗号在下方已补齐可直接运行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_digestsha256, task_serializerauth, event_serializerauth, accept_content[auth], ) app.setup_security()仓库中还有一个可直接运行的完整示例 examples/security/mysecureapp.py使用 Redis 作为 broker/backend并额外设置了result_accept_content[json]结果返回用 json任务收发用 auth。运行方式# 1. 生成证书见下文 # 2. 启动 worker $ python examples/security/mysecureapp.py worker -l INFO # 3. 另一个终端发送签名任务 $ python from mysecureapp import boom boom.delay().get() I am a signed messagesetup_security()之后一切经过 broker 的任务消息都必须由持有私钥的 client 签名worker 用证书库中的公钥验证从机制上杜绝了伪造任务与篡改内容。生成自签名证书官方文档指出证书最好由权威 CACertificate Authority签发但也可以自签名。仓库示例 examples/security/mysecureapp.py 的 docstring 给出了用 openssl 生成 RSA 证书的完整命令$ mkdir ssl $ openssl req -x509 -newkey rsa:4096 -keyout ssl/worker.key -out ssl/worker.pem -days 365 # 可选移除私钥口令若保留则需配置 security_key_password $ openssl rsa -in ssl/worker.key -out ssl/worker.key测试套件中证书的生成方式与此一致openssl genrsa/openssl req/openssl x509见 t/unit/security/test_security.py且测试还覆盖了加密私钥场景配置security_key_password后同样可以正常加载签名test_security.py。注意事项与局限路径建议用绝对路径相对路径虽未被禁止但官方明确推荐为密钥/证书文件使用绝对路径。auth 不加密消息内容auth序列化器只负责签名 验签不加密消息正文。若消息内容需要保密必须在传输层如 broker 的 TLS/SSL另行启用加密。算法约束私钥与证书均只支持 RSAcelery/security/key.py、celery/security/certificate.py 中非 RSA 直接抛ValueError证书过期后验签会失败FSCertStore加载过期证书也会直接报错运维时需关注证书轮换。证书库即信任根security_cert_store里放入哪些证书worker 就信任哪些 signer务必只放入可信证书。入侵检测假设会被攻破如何发现加固的最终目的是能在被入侵后发现问题。官方文档强调防御入侵最重要的能力是检测系统是否已被攻破并给出两个抓手。日志集中化 防篡改日志通常是寻找安全事件证据的第一现场但如果日志本身可被篡改就毫无价值。建议搭建集中式日志服务器把所有日志汇总到一处并严格限制其访问权限。集中化不仅便于检索配置得当还能显著增加入侵者篡改日志的难度。Celery 使用 Python 标准库logging本身已支持 syslog配合 syslog-ng、rsyslog 即可较容易地搭建集中日志。相关配置项可参考 docs/userguide/configuration.rst 中worker_log_format、worker_redirect_stdouts等日志设置。文档还附带了一个偏执狂建议用 UDP 发送日志甚至拔掉日志服务器网卡的发送线 :-) —— 物理隔离是防篡改的终极手段。Tripwire文件完整性监控Tripwire 是一类数据完整性工具现在为商业产品但有多个开源实现原理是持续维护文件系统中文件的密码学哈希一旦文件变化就向管理员告警。这样即使系统已被攻破你也能精确知道入侵者改动了哪些文件密码文件、日志、后门、rootkit 等——文档指出这往往是你发现入侵的唯一途径。开源实现包括OSSECSamhainOpen Source TripwireAIDE此外ZFS文件系统自带完整性校验也可作为替代方案。结合 Celery 场景建议将 worker 的代码目录、密钥/证书文件、配置文件和日志目录全部纳入完整性监控范围。总结一张安全加固检查清单将官方安全文档与仓库源码综合生产环境加固可按如下清单逐项落实Broker防火墙白名单 细粒度访问控制 broker_use_ssl传输加密监控防火墙状态。Client限制可发送消息的主机与账号配合auth签名确保消息来源可信。Worker按最小权限运行 worker 进程prefork 池下注意 fork 内存隔离对出站网络加防火墙必要时用 chroot/jail/sandbox/容器隔离文件系统与设备。序列化器accept_content [json]或[auth]白名单拒绝 pickle/YAML 等危险类型不信任的环境绝不启用 pickle。消息签名安装cryptography配置security_key、security_certificate、security_cert_store将task_serializer、event_serializer设为authaccept_content设为[auth]最后调用app.setup_security()证书由 CA 签发或自签名均可密钥/证书使用绝对路径并纳入轮换与监控。入侵检测集中式 syslog 日志 Tripwire 类文件完整性工具OSSEC/Samhain/AIDE或 ZFS 内建校验。核心结论一句话broker 防住未授权访问accept_content挡住危险序列化器auth签名保证消息来源可信集中日志与文件完整性检测兜底发现入侵——四层叠加才是可落地的 Celery 安全方案。【免费下载链接】celeryDistributed Task Queue (development branch)项目地址: https://gitcode.com/gh_mirrors/ce/celery创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Celery 安全加固实战：broker 防护、auth 消息签名与入侵检测指南
Celery 安全加固实战broker 防护、auth 消息签名与入侵检测指南【免费下载链接】celeryDistributed Task Queue (development branch)项目地址: https://gitcode.com/gh_mirrors/ce/celery本文是 Celery 分布式任务队列安全配置的实操指南核心围绕官方安全文档docs/userguide/security.rst展开首先分析 broker、client、worker 三大威胁面然后重点讲解从 pickle 风险到accept_content白名单的序列化器安全策略并深入拆解基于公钥密码学的auth消息签名序列化器——包括security_key、security_certificate、security_cert_store等全部配置项、setup_security()的调用时机与底层校验逻辑最后给出日志与文件完整性层面的入侵检测方案。读完本文你将能够为生产环境的 Celery 集群配置签名 白名单双重防护并具备排查安全配置问题的源码级视野。引言把 Celery 当作不可信组件来防护Celery 官方文档在 docs/userguide/security.rst 的开篇就给出了一个重要定位While Celery is written with security in mind, it should be treated as an unsafe component.也就是说虽然 Celery 在编写时考虑了安全性但任何部署都应把它当作一个不安全组件来对待。具体的加固程度取决于你的安全策略Security Policy本文按照官方文档的脉络从威胁面分析 → 序列化器安全 → 消息签名 → 入侵检测四个层次逐步展开。威胁面分析Broker、Client、WorkerCelery 系统的信任模型可以拆成三个角色broker消息中间件、client发送消息的一方例如触发任务的 Web 服务器、worker消费并执行任务的进程。官方文档建议对三者分别设防。Broker第一道防线是防火墙Broker 必须防止未授权访问尤其是当它暴露在公网时。默认情况下worker 会信任从 broker 拿到的数据未被篡改因此 broker 本身的可信度直接决定整个系统的安全下限。官方的加固建议分三层防火墙白名单在 broker 前面放置防火墙只允许白名单机器访问。但文档同时提醒防火墙误配置、被临时关闭在现实中非常常见安全策略应当包含对防火墙设备的监控以便及时发现其被有意或无意关闭——换句话说不能盲目信任防火墙本身。细粒度访问控制如果你的 broker 支持如 RabbitMQ应当启用细粒度的访问控制vhost、用户权限等。端到端 SSL 加密与认证如果 broker 后端支持可以通过broker_use_ssl配置项启用 SSL 加密与认证。该设置的定义位于 celery/app/defaults.py 的 broker 命名空间可配置ca_certs、certfile、keyfile、cert_reqs等 TLS 选项对 Redis、RabbitMQ 等 broker 传输层均适用。关于消息可信度本身可以进一步通过下文消息签名一节让 worker 验证消息来源。Clientbroker 安全不代表消息可信在 Celery 中client指一切向 broker 发送消息的角色典型如发起任务的 Web 服务器。如果攻击者能通过某个客户端任意发送消息那么 broker 再安全也无济于事。因此 client 侧需要认证与授权防止任意消息注入。官方文档在此处明确标注了*[Need more text here]*说明该小节尚待完善——但结合后文可知真正的 client 信任问题正是由auth签名序列化器解决的让 worker 只接受由可信私钥签名的消息。Worker任务的权限边界等于 worker 自身Worker 内执行的任务其默认权限与 worker 进程本身的权限一致涵盖内存、文件系统、设备等资源。这里有几个关键点prefork 池的 fork 语义当前默认的任务池是基于 multiprocessing 的 prefork。在这种模式下任务可以访问fork调用时复制进来的内存也能访问同一 worker 子进程中父任务写入的内存内容。若需严格隔离内存可以改为让每个任务在独立子进程中启动forkexecve。文件系统与设备隔离可以通过chroot、FreeBSD jail、sandboxing、虚拟机或平台提供的其他机制实现。网络访问worker 中执行的任何任务都拥有与运行机器相同的网络访问能力。如果 worker 位于内网建议为出站流量添加防火墙规则防止被攻破的任务作为跳板发起横向攻击。配置层面任务池相关设置在 celery/app/defaults.py 的worker命名空间如worker_pool默认preforkconcurrency 池的具体实现位于 celery/concurrency/prefork.py 与 celery/concurrency/base.py。序列化器安全pickle 的便利与风险默认序列化器与 pickle 风险自 Celery 4.0 起默认序列化器是JSONDEFAULT_TASK_SERIALIZER json见 celery/app/defaults.py。JSON 只支持有限的数据类型因此有些开发者会改用pickle序列化器——它几乎能序列化任意 Python 对象甚至函数非常方便。但正是这种什么都能反序列化的能力使 pickle 天生不安全攻击者构造的恶意 pickle 数据在反序列化时可以执行任意代码。只要 client 不可信或未认证就应当避免使用 pickle。官方文档引用了一篇经典分析见文档脚注来佐证 pickle 的可利用性。因此一个基本原则是在不可信的网络/客户端环境中永远不要让 pickle 数据进入 worker。accept_content白名单机制自 3.0.18 版本起Celery 支持通过accept_content设置只接受白名单中的内容类型更早的版本会忽略该设置需确认运行版本支持。它接受序列化器名称或 content-type 列表# 只接受 json 序列化器按序列化器名称 accept_content [json] # 或者按 content-type 指定 accept_content [application/json]该设置在 celery/app/defaults.py 中的默认值为(json,)。收到白名单之外的 content-type 消息时worker 会直接拒绝从源头阻断 pickle、YAML 等危险序列化器。需要说明的是accept_content只限制接收发送侧序列化器由task_serializer决定默认json。如果你同时希望结果后端也只接受白名单类型可以另行配置result_accept_contentexamples/security/mysecureapp.py 中就将其显式设为[json]。底层实现禁用不安全序列化器accept_content白名单在底层通过 kombu 的disable_insecure_serializers实现。在 celery/security/init.py 中可以看到disable_untrusted_serializers(whitelistNone)直接转调 kombu 的_disable_insecure_serializers(allowedwhitelist)kombu 的不安全序列化器清单包括 pickleapplication/x-python-serialize和 YAMLapplication/x-yaml等。测试用例验证了这一行为调用disable_insecure_serializers([application/json, application/x-python-serialize])后application/x-yaml被禁用而 json、pickle 被豁免而allowedNone时则全部不安全类型都被禁用。这与你下文要调用的setup_security()行为一致——它会自动禁用所有不安全序列化器。消息签名auth 序列化器从原理到实战accept_content只能防住不该有的内容类型却无法证明消息确实来自可信来源。为此Celery 内置了一个特殊的auth序列化器它基于公钥密码学Public-key cryptographyclient 用私钥给消息签名worker 用公钥证书验证签名从而确认消息确实来自可信发送方。签名/验签的底层流程auth序列化器的核心实现在 celery/security/serialization.py 的SecureSerializer类签名serialize先用内部序列化器默认json将数据dumps成 body然后用PrivateKey.sign(body, digest)对序列化后的 body签名——官方注释说明这是为了接收方无需解码内容即可验签避免解码环节的潜在缺陷。随后将signer证书标识、signature、content_type、content_encoding、body 打包并整体 base64 编码。验签deserialize解包出 signature、signer、body 后通过cert_store[signer].verify(body, signature, digest)校验签名校验通过后才loads反序列化。配套的密码学组件celery/security/key.pyPrivateKey负责加载 PEM 私钥可选密码解密并执行签名。注意它只支持 RSA 私钥非 RSA 会抛出ValueError签名使用 PSS 填充 MGF1。celery/security/certificate.pyCertificate加载并校验 X.509 证书同样只支持 RSA 公钥提供get_id()issuer serial number 唯一标识与verify()会先检查证书是否过期过期抛SecurityError。FSCertStore则从文件系统批量加载证书传入目录会被自动补成dir/*也支持直接传 glob如/etc/ssl/certs/*.pem加载时发现过期证书会直接抛SecurityError。celery/security/utils.pyget_digest_algorithm(digest)把sha256这类字符串转成 cryptography 的哈希对象reraise_errors把密码学异常统一包装成 Celery 的SecurityError便于上层统一处理。证书的身份标识与存储逻辑在CertStore中以get_id()为键存放证书重复添加或未知证书都会抛SecurityError——这保证了验签时只能使用你预先放入证书库的可信证书。前置条件安装 cryptographyauth序列化器依赖cryptography库。在 celery/security/init.py 中import cryptography失败会直接抛ImproperlyConfigured提示$ pip install cryptography全部相关配置项配置项说明默认值task_serializer任务序列化器需设为authjsonaccept_content只接受签名消息需设为[auth](json,)event_serializer事件协议签名可设为authjsonsecurity_key私钥文件路径无security_key_password加密私钥的密码bytes类型无security_certificate自身 X.509 证书路径无security_cert_store可信证书目录/glob用于验签无security_digest签名摘要算法如sha256sha256这些安全设置在 celery/app/defaults.py 的security命名空间中统一定义certificate、cert_store、key、key_password、digest默认DEFAULT_SECURITY_DIGEST sha256配置时以security_前缀引用即security_key、security_certificate、security_cert_store、security_key_password、security_digest。security_digest的值会传给get_digest_algorithm并大写后从cryptography.hazmat.primitives.hashes中取值因此支持该库提供的摘要算法名。setup_security()唯一的启用入口配置好上述设置后还必须调用app.setup_security()全局操作会影响所有应用实例。其签名与实现在 celery/app/base.py 与 celery/security/init.py执行顺序如下禁用不安全序列化器调用_disable_insecure_serializers(allowed_serializers)可用allowed_serializers参数豁免白名单项。校验配置自洽要求task_serializer auth且accept_content [auth]否则抛ImproperlyConfigured错误信息见SETTING_MISSING——文档明确如果签名后不验签签名就毫无意义。校验密钥/证书路径齐全security_key、security_certificate、security_cert_store三者缺一不可否则抛ImproperlyConfigured见SECURITY_SETTING_MISSING。注册 auth 序列化器读取私钥与证书内容调用register_auth()把SecureSerializer注册进 kombu 序列化器注册表content-type 为application/data、编码为utf-8并把默认序列化器切换为auth。test_security.py 完整覆盖了这些分支正常配置可成功 setuptask_serializer不是auth、accept_content不含auth、缺少密钥/证书路径、未安装 cryptography 等场景均抛ImproperlyConfigured同时验证了setup_security确实会禁用 json/pickle 等不安全序列化器。端到端配置示例官方文档给出的配置示例docs/userguide/security.rst如下——注意原文代码块中缺失的逗号在下方已补齐可直接运行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_digestsha256, task_serializerauth, event_serializerauth, accept_content[auth], ) app.setup_security()仓库中还有一个可直接运行的完整示例 examples/security/mysecureapp.py使用 Redis 作为 broker/backend并额外设置了result_accept_content[json]结果返回用 json任务收发用 auth。运行方式# 1. 生成证书见下文 # 2. 启动 worker $ python examples/security/mysecureapp.py worker -l INFO # 3. 另一个终端发送签名任务 $ python from mysecureapp import boom boom.delay().get() I am a signed messagesetup_security()之后一切经过 broker 的任务消息都必须由持有私钥的 client 签名worker 用证书库中的公钥验证从机制上杜绝了伪造任务与篡改内容。生成自签名证书官方文档指出证书最好由权威 CACertificate Authority签发但也可以自签名。仓库示例 examples/security/mysecureapp.py 的 docstring 给出了用 openssl 生成 RSA 证书的完整命令$ mkdir ssl $ openssl req -x509 -newkey rsa:4096 -keyout ssl/worker.key -out ssl/worker.pem -days 365 # 可选移除私钥口令若保留则需配置 security_key_password $ openssl rsa -in ssl/worker.key -out ssl/worker.key测试套件中证书的生成方式与此一致openssl genrsa/openssl req/openssl x509见 t/unit/security/test_security.py且测试还覆盖了加密私钥场景配置security_key_password后同样可以正常加载签名test_security.py。注意事项与局限路径建议用绝对路径相对路径虽未被禁止但官方明确推荐为密钥/证书文件使用绝对路径。auth 不加密消息内容auth序列化器只负责签名 验签不加密消息正文。若消息内容需要保密必须在传输层如 broker 的 TLS/SSL另行启用加密。算法约束私钥与证书均只支持 RSAcelery/security/key.py、celery/security/certificate.py 中非 RSA 直接抛ValueError证书过期后验签会失败FSCertStore加载过期证书也会直接报错运维时需关注证书轮换。证书库即信任根security_cert_store里放入哪些证书worker 就信任哪些 signer务必只放入可信证书。入侵检测假设会被攻破如何发现加固的最终目的是能在被入侵后发现问题。官方文档强调防御入侵最重要的能力是检测系统是否已被攻破并给出两个抓手。日志集中化 防篡改日志通常是寻找安全事件证据的第一现场但如果日志本身可被篡改就毫无价值。建议搭建集中式日志服务器把所有日志汇总到一处并严格限制其访问权限。集中化不仅便于检索配置得当还能显著增加入侵者篡改日志的难度。Celery 使用 Python 标准库logging本身已支持 syslog配合 syslog-ng、rsyslog 即可较容易地搭建集中日志。相关配置项可参考 docs/userguide/configuration.rst 中worker_log_format、worker_redirect_stdouts等日志设置。文档还附带了一个偏执狂建议用 UDP 发送日志甚至拔掉日志服务器网卡的发送线 :-) —— 物理隔离是防篡改的终极手段。Tripwire文件完整性监控Tripwire 是一类数据完整性工具现在为商业产品但有多个开源实现原理是持续维护文件系统中文件的密码学哈希一旦文件变化就向管理员告警。这样即使系统已被攻破你也能精确知道入侵者改动了哪些文件密码文件、日志、后门、rootkit 等——文档指出这往往是你发现入侵的唯一途径。开源实现包括OSSECSamhainOpen Source TripwireAIDE此外ZFS文件系统自带完整性校验也可作为替代方案。结合 Celery 场景建议将 worker 的代码目录、密钥/证书文件、配置文件和日志目录全部纳入完整性监控范围。总结一张安全加固检查清单将官方安全文档与仓库源码综合生产环境加固可按如下清单逐项落实Broker防火墙白名单 细粒度访问控制 broker_use_ssl传输加密监控防火墙状态。Client限制可发送消息的主机与账号配合auth签名确保消息来源可信。Worker按最小权限运行 worker 进程prefork 池下注意 fork 内存隔离对出站网络加防火墙必要时用 chroot/jail/sandbox/容器隔离文件系统与设备。序列化器accept_content [json]或[auth]白名单拒绝 pickle/YAML 等危险类型不信任的环境绝不启用 pickle。消息签名安装cryptography配置security_key、security_certificate、security_cert_store将task_serializer、event_serializer设为authaccept_content设为[auth]最后调用app.setup_security()证书由 CA 签发或自签名均可密钥/证书使用绝对路径并纳入轮换与监控。入侵检测集中式 syslog 日志 Tripwire 类文件完整性工具OSSEC/Samhain/AIDE或 ZFS 内建校验。核心结论一句话broker 防住未授权访问accept_content挡住危险序列化器auth签名保证消息来源可信集中日志与文件完整性检测兜底发现入侵——四层叠加才是可落地的 Celery 安全方案。【免费下载链接】celeryDistributed Task Queue (development branch)项目地址: https://gitcode.com/gh_mirrors/ce/celery创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
