Atlas没有原生临时用户类型，因其底层MongoDB不支持用户级TTL，所有用户持久存储于system.users集合，所谓“临时”需依赖密码过期、角色限制、手动清理等外部策略实现。
临时数据库用户在 Atlas 中不能“临时创建”，只能通过标准用户生命周期管理 + 权限时效控制来模拟——本质是用标准 db.createUser() 创建，再配合密码过期、角色限制和手动清理实现“临时性”。直接调用 API 或 UI 并不存在 isTemporary: true 这类字段。
为什么 Atlas 没有原生的“临时用户”类型
Atlas 的数据库用户模型基于 MongoDB 原生用户系统，而 MongoDB 本身不支持用户级 TTL（自动销毁）。所有用户都持久存在于 admin 或目标数据库的 system.users 集合中。所谓“临时”，必须靠外部策略兜底：
- 密码设置为强随机串，且不复用已有凭证
- 分配最小必要角色（如
read而非readWrite），避免授予dbAdmin或clusterAdmin - 不绑定 IP 白名单（否则会卡住调试），但可通过 Atlas 网络访问列表 + 应用层网关做二次收敛
- 记录创建时间与预期有效期，靠人工或脚本在到期后执行
db.dropUser()
用 atlas cli 创建带明确用途的短期用户
Atlas CLI 是最可控的方式，能避免 UI 里误选全局角色。关键点在于：角色限定到具体数据库 + 不启用通配符权限。
例如，为某次数据分析任务创建只读用户：
atlas databaseUsers create \ --projectId <your-project-id> \ --username analyst-20260721 \ --password "v9X!kL2$mQz" \ --databaseName reporting \ --roleName read \ --databaseName admin \ --roleName clusterMonitor
注意：
-
--databaseName出现两次：一次指定授权目标库（reporting），一次指定角色作用域（admin中的clusterMonitor是集群级只读监控角色） - 不要用
readAnyDatabase或readWriteAnyDatabase—— 这类角色绕过数据库粒度隔离，违背“临时即受限”原则 - 密码必须满足 Atlas 强度要求（至少 12 位，含大小写字母、数字、符号）
如何安全地“到期清理”用户
Atlas 不提供自动删用户功能，但可结合 atlas databaseUsers delete + cron 或 CI/CD 流水线触发：
先查用户是否存在：
atlas databaseUsers list --projectId <pid> --output json | jq -r '.results[] | select(.username == "analyst-20260721") | .username'
再删除：
atlas databaseUsers delete analyst-20260721 \ --projectId <your-project-id> \ --force
容易踩的坑：
- 忘记加
--force会导致交互式确认，CI 环境下直接失败 - 误删其他同名用户（比如测试环境也用了相同命名规则）——建议用户名带环境前缀，如
prod-analyst-20260721 - 删除后未同步更新应用配置，导致连接报错
Authentication failed
替代方案：用短期 token 替代长期用户（适用于应用接入）
如果临时需求来自服务间调用，更推荐用 Atlas 的 Atlas App Services 或 OIDC 认证 配合短期 JWT，而非创建数据库用户。这类 token 可设 exp 字段（如 1 小时），由应用自行刷新或失效，数据库侧零配置。
此时数据库用户只需一个固定的服务账号（如 app-service），所有权限收束到该账号，token 仅作身份断言，不暴露凭证。
真正难的不是创建，而是追踪谁建了、用在哪、何时该删——没自动化就别谈“临时”。
