一条docker ps打出来镜像、端口、存储卷都正常只有环境变量里那对默认值看着眼熟。RustFS 的默认凭据是rustfsadmin/rustfsadmin官方文档写明它只为第一次启动方便正式部署都该换掉。这条要求文档里提得不多但它是部署完之后最容易被扫到的地方。默认值会一直生效直到有人改它RUSTFS_ACCESS_KEY和RUSTFS_SECRET_KEY的默认值都是rustfsadmin。这两个变量都没给、也没给对应的_FILE形式时服务器会退回内置默认凭据并打一条警告。容器入口点把这个说得更明确打印警告照常启动。服务照样起来了区别只在于那条警告埋在一堆启动日志里而默认凭据一直挂在 9000 端口上。Docker 那页的要求说得很死把 RustFS 暴露到网络之前必须先设置唯一的RUSTFS_ACCESS_KEY和RUSTFS_SECRET_KEY谁也不能再沿用默认值容器启动时没带自定义凭据的话要停掉重建文档还专门说了rustfs-data卷会原样保留。这笔账很好算重建容器只花几分钟留着默认凭据的风险是不知道哪天有人猜到它。默认值到底拦不拦你得分开看谁来拦。服务端这一层不拦启动这是文档写明的回退行为。拦你的地方有三处。容器入口点会在配置非法时直接退出包括同一凭据上变量和文件都设了、变量或文件内容是空的、文件读不出来这几种情况。官方 Helm chart 在渲染阶段就会拒绝默认凭据得指定secret.existingSecret、或显式给两个非空非默认值、或打开secret.allowInsecureDefaults仅限本地开发才能过只给其中一个键也会被拒。多节点集群如果全用默认凭据节点间 RPC 的派生会因为公开默认值 fail closed认证建不起来。单机起来没人拦你但 Helm chart、多节点 RPC、安全基线这三处都是拦的。环境变量和文件只能二选一每个凭据有两个入口环境变量和文件。变量默认说明RUSTFS_ACCESS_KEYrustfsadmin根访问密钥RUSTFS_SECRET_KEYrustfsadmin根密钥RUSTFS_ACCESS_KEY_FILE未设置存放访问密钥的文件路径例如容器或 K8s 的 secret 挂载RUSTFS_SECRET_KEY_FILE未设置存放根密钥的文件路径文档对两者同时出现这件事态度很明确是一条硬错误Set either RUSTFS_ACCESS_KEY or RUSTFS_ACCESS_KEY_FILE, not both.。同一个凭据上既设变量又设文件时容器入口点直接退出 1。这样也不用猜系统按哪条规则挑配置写错了当场就炸不会等哪天改了一行配置才发现密钥换了来源。入口点还有四条规则可以抄进部署手册文件只取第一行周围的空白和 CRLF 会被去掉没有换行结尾也算合法变量是空的、文件读不出来都是退出 1文件内容如果写的就是rustfsadmin会触发和直接设变量时一样的那条警告。对应的命令行参数是--access-key-file和--secret-key-file。Docker 那页还提到一层关系同一项设置里命令行 flag 优先于环境变量。改走文件入口多半是合规要求明文写在配置文件里谁读得到这个文件谁就能拿到根凭据进程列表和代码仓库里也不留痕迹。K8s 里对应做法是把凭据放进 Secret 再以 volume 挂载路径直接写进那两个_FILE变量。选值还要注意几件事。SigV4 会把访问密钥嵌进access-key/date/region/service/aws4_request这样的凭据作用域所以访问密钥里不能含斜杠否则签名作用域会被解析错。文档建议只用大写字母和数字跟 RustFS 自己生成的格式保持一致未改动的 Base64 输出不能当作访问密钥用因为它可能带斜杠。根密钥则要另生成一串强随机值别从访问密钥推导出来复用。换掉根凭据不等于业务就安全了上面这些动作只解决一件事不让默认凭据出现在网络上。下一步是别把根凭据分发给业务。官方文档有一节专门讲这件事日常访问不要直接用根凭据对应该通过 9001 控制台或 IAM 管理接口创建范围受限的用户、组、策略和服务账号根凭据只留给管理操作。IAM 那边的表述更具体根账号绕过 IAM 身份策略评估走的是 owner 语义bucket policy 依然可以对根发出的 S3 请求做拒绝只有GetBucketPolicy、PutBucketPolicy、DeleteBucketPolicy三个动作能穿透 bucket policy 的拒绝保证所有者还能把访问收回来。根凭据能做什么是写死的而且是唯一一个策略管不住的身份。业务程序拿到它等于拿到了所有桶的读写和所有管理接口泄漏一次就是全量泄漏。建一个 IAM 用户的成本只是几条接口调用好处是把影响范围从整个集群缩到一个业务。接口调用走的是管理 REST 端点签名凭据需要能admin:CreateUsercurl-XPUThttp://localhost:9000/rustfs/admin/v3/add-user?accessKeybusiness-app\-HContent-Type: application/json\-uadmin-access-key:admin-secret-key\-d{secretKey: user-secret-key, status: enabled}用户名访问密钥不能含空格也不能等于根访问密钥。RustFS 内置的策略里有readwrite、readonly、writeonly、diagnostics、consoleAdmin这几个不够用时按同样的 JSON 格式写自定义策略再绑定给用户或用户组。如果业务还需要短期凭据服务账号可以在创建时带过期时间戳STS 走AssumeRole拿到的临时凭据有效期在 15 分钟到 12 小时之间都适合用来限制单个应用的权限。命令行里写密钥的风险Docker 那页通篇用-e RUSTFS_ACCESS_KEY...举例照着写的时候要留意-e的值会出现在docker inspect的输出里也会留在 shell 历史里。生产环境尽量避免把密钥写在命令行参数上改用--env-file读取外部密钥文件或者直接用RUSTFS_ACCESS_KEY_FILE/RUSTFS_SECRET_KEY_FILE挂载这两条路都不需要密钥出现在命令里。容器里还有一点和裸机不同默认凭据不会被「首次登录后自动改掉」这类机制处理它会一直在默认值上直到你停掉重建。官方给的动作是停掉再重建并说明了数据卷完整保留所以重建是低风险的常规操作不用挑特殊时机。K8s 场景形态又不同凭据放在 Secret 里通过 volume 挂载Secret 更新不会自动同步到已经运行的 Pod改完之后要滚动重启相关 Pod 才生效跟裸机上改完重启是一回事。挂载进去的那个文件容器以 uid 10001 运行时要先用chown -R 10001:10001把属主收好否则会碰到权限被拒。文件本身的权限建议收紧到 0400 或 0440属主给读取它的那个账号就够。容器命令行里的:ro只保证容器侧写不了宿主机上的文件仍然可写谁能读这个文件谁就能拿到根凭据。根凭据是全集群一份不是各节点各配一份RUSTFS_ACCESS_KEY/RUSTFS_SECRET_KEY是集群全局生效的一对文档原话是集群所有节点必须运行同一对因为节点间 RPC 的认证密钥是从它派生的除非显式设置了RUSTFS_RPC_SECRET。各节点配不一样的根凭据节点间认证和 S3 接口都会出异常这一点动手之前就得定成一致的别指望滚动过程中去补。那套流程具体先动哪一步、什么时候能放流量节点间 RPC 密钥那篇讲得更细需要换凭据的时候照那篇走就行。换完之后不能只看日志凭据这块很多人只看启动日志里那条「使用内置默认凭据」的警告有没有消失。这一步不够。日志会经过采集端过滤、降采样、跨节点汇聚警告消失了不代表新凭据真的被读进去了。文件入口那条路径尤其要注意读失败在容器里是启动退出有些编排下会被重启这件事盖过去表现成了反复重启。可靠的办法是从外部真的发一次请求用新凭据读一个桶看返回是否正常再用旧凭据发同样的请求看是否被拒。旧凭据还能用就说明它仍然持有有效身份这一步比看日志靠谱得多。这几步放进镜像构建后的自检里比等扫描报告报上来再发现要好得多。默认凭据这件事本身没什么技术难度难的是它不会自己报错。还有三处默认值容易漏区域回退。RUSTFS_REGION未设置时服务器会回退到us-east-1单机试用无所谓跨区域多站点部署里回退值和预期不一致时客户端按区域解析桶会出现找不到端点的报错。旧名字的映射。映射表里还留着RUSTFS_ROOT_USER对应RUSTFS_ACCESS_KEY、RUSTFS_ROOT_PASSWORD对应RUSTFS_SECRET_KEY此外MINIO_ROOT_USER和MINIO_ROOT_PASSWORD也在映射范围内。旧写法能跑但会打一条一次性弃用警告规范名字优先级更高新部署直接用RUSTFS_前缀。文件权限。写完配置文件之后用chmod 600收一下属主留给部署账号。这一步几乎不花成本但它决定了同主机上的其他账号能不能读到这个文件。收尾还有一件事用add-user给业务建一个受策略约束的 IAM 用户把根凭据收回来只留给管理操作。不做这一步前面所有工作只是把「默认口令」换成了「自己起的口令」影响范围一点没变。