4. 基于角色的访问控制（RBAC）与用户权限

在数据中心网络运维中，把“谁能登录设备、登录后能做什么”交给本地账号逐台维护，很快就会失控：人员变动、权限调整、审计追溯都会变成负担。Arista EOS 的 RBAC 机制把权限抽象成“角色”，再把角色绑定到用户，配合 TACACS+/RADIUS 集中认证与授权，形成一套可审计、可复用的访问控制体系。本节围绕角色创建、权限分配、命令集限制以及集中认证授权集成展开。

一、RBAC 的三个基本对象

EOS 的 RBAC 由三个对象构成：角色（role）定义一组权限规则；用户（user）是登录主体，被赋予一个或多个角色；规则（rule）是角色内部的最小授权单元，由“动作 + 路径”组成。动作包括 permit、deny，路径使用 EOS 命令模式与命令关键字描述，例如 show interfaces、configure、interface Ethernet1。规则按顺序匹配，先匹配到的规则生效，因此“先拒绝、后放行”或“先放行、后拒绝”的顺序会直接改变最终权限。

需要特别区分两个概念：认证（authentication）解决“你是谁”，授权（authorization）解决“你能做什么”。RBAC 属于授权层，TACACS+/RADIUS 属于认证层，两者通过 AAA 框架衔接。EOS 默认存在 network-admin（全权限）和 network-operator（只读）两个内置角色，自定义角色应基于最小权限原则设计。

二、创建角色与分配权限

创建角色使用 role 命令进入角色配置模式，再用 rule 逐条定义权限。下面是一个面向“监控运维人员”的角色示例，只允许查看接口、路由和日志，禁止进入配置模式：

role monitor
   10 permit mode exec command show
   20 permit mode exec command ping
   30 permit mode exec command traceroute
   40 deny mode exec command configure
   50 deny mode exec command reload
   60 deny mode exec command write

规则编号（10、20……）决定匹配顺序，编号小的先匹配。这里第 10 条放行所有 show 命令，第 40 条显式拒绝 configure，即使后续没有其他规则，监控角色也无法进入配置模式。若把第 40 条编号写成 5，则它会先于 show 匹配，但只影响 configure 本身，不影响 show，这说明规则之间是独立匹配的，不是“一旦命中就整体放行”。

角色创建后需要绑定到用户。本地用户绑定方式如下：

username ops1 privilege 1 role monitor secret 0 Str0ngP@ss
username ops2 privilege 1 role monitor secret 0 An0therP@ss

其中 privilege 是 EOS 的权限级别（0～15），role 才是 RBAC 的实际授权来源。一个用户可绑定多个角色，权限取并集。例如同时绑定 monitor 和 backup，用户就同时拥有两个角色的权限。

三、限制命令集与命令模式

限制命令集的关键是精确描述“模式 + 命令”。EOS 常见模式包括 exec、configure、interface、router bgp 等。规则中的 mode 必须与命令实际所在模式一致，否则规则不会生效。例如要限制某角色只能修改 VLAN，可写：

role vlan-admin
   10 permit mode configure command vlan
   20 permit mode configure command interface
   30 permit mode configure command no
   40 deny mode configure command router
   50 deny mode configure command reload

这里第 30 条放行 no 是为了允许删除 VLAN 或接口配置，但 no 本身是通用前缀，若不加限制，用户可能通过 no router bgp 绕过第 40 条。更严谨的做法是把 no 与具体对象组合，或使用更细的路径匹配。EOS 支持在命令后使用通配符，例如 command show interfaces *，但通配符范围要谨慎评估，避免意外放行敏感命令。

四、集成 TACACS+/RADIUS 集中认证与授权

本地 RBAC 适合设备数量少、人员固定的场景；当设备规模扩大，应把认证和授权交给 TACACS+ 或 RADIUS 服务器。EOS 通过 AAA 框架集成，典型配置如下：

aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
aaa authorization commands all default group tacacs+ local
tacacs-server host 10.10.10.20 key 7 <encrypted-key>
tacacs-server timeout 5

第一行表示登录认证优先走 TACACS+，服务器不可达时回退本地；第二行表示 exec 授权走 TACACS+；第三行表示所有命令授权走 TACACS+。TACACS+ 的优势在于它把认证、授权、审计分离，且支持按命令授权，服务器可以返回“允许/拒绝某条命令”的决策，比 RADIUS 更细粒度。RADIUS 通常只做认证和粗粒度授权，命令级控制能力较弱。

在 TACACS+ 服务器侧，需要为每个用户或用户组配置 service=exec 和 service=shell 的授权属性，并返回 priv-lvl 与命令集。例如返回 priv-lvl=1 表示只读，priv-lvl=15 表示全权限。若服务器返回 cmd=show 且 cmd-arg=interfaces，则只放行该条命令。EOS 会把服务器返回的授权结果与本地角色规则合并判断，通常以服务器决策优先。

五、验证与排障

配置完成后，用 show role 查看角色及规则，用 show user 查看当前登录用户及其角色，用 show aaa 查看 AAA 状态。验证时建议用测试账号实际登录，执行被允许和被拒绝的命令各一条，观察返回是正常输出还是 % Invalid input 或权限拒绝提示。若 TACACS+ 授权失败，先检查 tacacs-server host 可达性、共享密钥是否一致、服务器是否返回了正确的 priv-lvl，再检查本地回退是否生效。

图中展示了从用户登录到命令执行的完整链路：认证由 TACACS+/RADIUS 完成，授权决策由服务器返回的属性与本地角色规则共同决定，最终在命令执行时按规则编号顺序匹配。理解这条链路，就能在权限异常时快速定位是认证失败、授权属性缺失，还是本地规则顺序写错。