📚 课程目录第4章认证与权限模型

4. 认证与权限模型

在 HPE Alletra 的日常运维与自动化体系中，认证解决“你是谁”，授权解决“你能做什么”，而会话与令牌解决“这次操作在多长时间内、以什么身份被认可”。三者缺一不可。很多自动化脚本失败或权限越界，根源并不在 API 调用本身，而在于账号、角色与令牌的规划没有与业务边界对齐。本节围绕用户角色、RBAC、API Token、会话管理和最小权限原则，梳理一套可直接落地的权限模型与自动化账号规划方法。

一、认证与授权的分层结构

Alletra 的访问控制可以理解为四层：身份层（本地用户或外部目录用户）、角色层（预定义角色或自定义角色）、权限层（RBAC 策略绑定的资源与操作）、凭据层（会话 Cookie 或 API Token）。身份通过认证后，系统根据其被授予的角色计算有效权限集合，最终决定某个 REST 请求是否被放行。

需要特别区分两类凭据：会话（Session）面向交互式登录，通常有较短的空闲超时；API Token面向程序化调用，生命周期更长，但必须显式管理其作用域与吊销。把交互式账号的会话用于脚本，或把长期 Token 硬编码进脚本，都是典型的反模式。

二、用户角色与 RBAC 的落地方式

Alletra 内置角色通常覆盖从只读监控到全量管理的梯度。实际规划时，建议先按“职责域”划分角色，再按“资源域”收窄范围。例如：

monitor：只读权限，可查看阵列状态、告警、性能指标，不能创建或删除任何资源。适合值班监控账号。
operator：可执行卷创建、快照、主机映射等日常操作，但不能修改用户、角色或系统级配置。
storage-admin：可管理存储资源与主机组，但仍不能管理认证体系本身。
super-admin：拥有全部权限，仅限极少数人持有，且必须启用强认证。

如果内置角色粒度不够，可以创建自定义角色，把“资源类型 + 操作动词”组合成策略。例如一个“备份自动化角色”只需要 volume:read、snapshot:create、snapshot:read、snapshot:delete，而不需要 volume:delete 或 host:manage。这样即使 Token 泄露，攻击面也被限制在快照生命周期内。

三、API Token 的规划与使用

API Token 是自动化账号的核心凭据。规划时应遵循以下要点：

一账号一用途：备份、监控、编排、报表各自使用独立服务账号，避免一个 Token 承担多种职责。
最小作用域：Token 绑定到具体角色，角色只包含该用途必需的权限。
设置有效期：为 Token 设置合理的过期时间，例如 90 天，并建立轮换机制。
禁止硬编码：Token 不应写入脚本明文，应通过环境变量、密钥管理服务或配置文件权限控制来注入。
可审计：每个 Token 对应唯一服务账号，便于在审计日志中追溯到具体自动化任务。

下面是一个通过环境变量注入 Token 并调用 REST API 的示例（参数为教学示例，非实测结果）：

# 教学示例：通过环境变量注入 Token，避免硬编码
export ALLETRA_TOKEN="eyJhbGciOi...示例令牌..."
export ALLETRA_HOST="alletra-array.example.com"

# 查询卷列表（只读操作，对应 monitor 或 operator 角色）
curl -s -k \
  -H "Authorization: Bearer ${ALLETRA_TOKEN}" \
  -H "Accept: application/json" \
  "https://${ALLETRA_HOST}/api/v1/volumes" | jq '.members[] | {name, sizeMiB, status}'

# 预期返回结构示例：
# { "name": "vol_prod_01", "sizeMiB": 102400, "status": "normal" }
# { "name": "vol_prod_02", "sizeMiB": 204800, "status": "normal" }

如果返回 401 Unauthorized，说明 Token 无效或已过期；返回 403 Forbidden，说明 Token 有效但角色权限不足。这两个状态码是排查权限问题最直接的依据。

四、会话管理与超时策略

交互式会话应设置合理的空闲超时，例如 15～30 分钟。对于管理界面，建议启用“会话固定保护”和“登出即失效”。自动化场景不应复用交互式会话，因为会话 Cookie 通常绑定浏览器上下文，且超时策略与脚本运行周期不匹配。

会话与 Token 的对比可以归纳为：会话适合“人操作、短时间、可交互”，Token 适合“程序调用、长时间、无人值守”。两者不应混用。

五、自动化账号规划示例

下表给出一个可直接参考的自动化账号规划模板，字段可根据实际环境调整：

服务账号	用途	绑定角色	Token 有效期	轮换周期
svc_backup	快照创建与清理	自定义 backup-role	90 天	每 60 天
svc_monitor	性能与告警采集	monitor	180 天	每 150 天
svc_provision	卷与主机映射编排	operator	90 天	每 60 天
svc_report	容量报表导出	monitor	180 天	每 150 天

实践建议：为每个服务账号建立“创建—使用—轮换—吊销”的完整生命周期记录。Token 轮换时，先创建新 Token 并验证可用，再吊销旧 Token，避免自动化任务中断。

风险提示：不要将 super-admin 角色的 Token 用于任何自动化脚本。一旦泄露，攻击者可以创建新用户、修改角色、删除卷，造成不可逆损失。最小权限原则在自动化场景中不是可选项，而是底线。

总结来看，认证与权限模型的核心不是“能不能登录”，而是“登录后能做什么、做多久、被谁审计”。把身份、角色、权限、凭据四层对齐到具体业务职责，再配合 Token 轮换与最小权限原则，才能让 Alletra 的自动化既高效又可控。