Redis Operator中ACL用户配置的实践与解决方案

背景介绍

Redis Operator作为Kubernetes环境中管理Redis集群的重要工具，在实际生产环境中经常需要配置多用户访问控制。标准部署默认只创建default和pinger两个用户，这往往无法满足企业级应用的多租户需求。

问题现象分析

用户在使用Spotahome Redis Operator时发现，通过customConfig配置的aclfile参数未能生效，而其他配置如slowlog-log-slower-than却能正常应用。深入分析发现，这是由于Redis的ACL机制存在特殊限制：不能同时在配置文件和独立ACL文件中定义用户权限。

技术原理剖析

Redis 7.x版本引入了完善的ACL(访问控制列表)功能，但实现上有以下关键特性：

1. ACL配置只能通过单一来源加载，要么是redis.conf中的user指令，要么是外部aclfile
2. 操作优先级上，最后加载的配置会覆盖之前的内容
3. Operator默认生成的redis.conf中已包含pinger用户的ACL定义

解决方案实践

经过验证，推荐以下两种配置方案：

方案一：合并配置文件法

1. 获取Operator默认生成的redis.conf模板
2. 将自定义用户ACL规则合并到该文件中
3. 通过Secret挂载完整配置文件
4. 修改启动命令指向新配置文件

extraVolumes:
- name: redis-config
  secret:
    secretName: custom-redis-conf
extraVolumeMounts:
- name: redis-config
  mountPath: /etc/redis
command: ['redis-server', '/etc/redis/redis.conf']

方案二：初始化脚本法

1. 创建包含ACL命令的脚本文件
2. 通过ConfigMap或Secret挂载
3. 使用initContainer或启动脚本执行ACL加载

#!/bin/sh
redis-cli ACL LOAD
exec redis-server /redis/redis.conf

注意事项

1. 主从切换时Sentinel节点的ACL配置需要特殊处理
2. 密码等敏感信息必须通过Secret管理
3. Operator版本升级可能影响自定义配置的兼容性
4. 生产环境建议通过ServiceAccount限制Pod权限

最佳实践建议

对于企业级部署，建议：

1. 建立ACL配置的版本控制机制
2. 实现配置变更的自动化测试
3. 监控ACL加载状态和用户连接情况
4. 定期审计用户权限设置

通过以上方案，可以灵活管理Redis Operator中的多用户访问控制，满足不同业务场景的安全需求。