权限控制

DNS-Go 采用基于角色的访问控制（RBAC）模型，通过角色和权限的组合实现细粒度的权限管理。

权限模型

DNS-Go 的权限控制基于以下模型：

用户 → 角色 → 权限 → 资源操作

• 用户：系统的登录账号
• 角色：一组权限的集合
• 权限：对特定资源的操作权限
• 资源：系统的功能模块（域名、记录、上游等）

内置角色

系统预定义了四个角色，覆盖大多数使用场景：

超级管理员（super_admin）

拥有系统的所有权限，包括：

• ✅ 用户管理（增删改查、重置密码、解锁）
• ✅ 域名管理（增删改查、导入导出）
• ✅ 解析记录管理（增删改查、批量操作）
• ✅ 上游管理（配置、策略、健康检查）
• ✅ 系统配置（参数设置、缓存配置）
• ✅ 日志查看（查询日志、操作日志）
• ✅ 监控查看（系统监控、性能指标）

适用对象：系统部署者、最高管理员

管理员（admin）

拥有除用户管理外的所有权限：

• ❌ 用户管理（只能查看，不能增删改）
• ✅ 域名管理
• ✅ 解析记录管理
• ✅ 上游管理
• ✅ 系统配置
• ✅ 日志查看
• ✅ 监控查看

适用对象：运维管理员、日常管理人员

操作员（operator）

拥有域名和记录管理的权限：

• ❌ 用户管理
• ✅ 域名管理（增删改查）
• ✅ 解析记录管理（增删改查）
• ⚠️ 上游管理（仅查看）
• ❌ 系统配置
• ✅ 日志查看（仅查看）
• ✅ 监控查看

适用对象：日常操作人员、DNS 维护人员

访客（viewer）

只拥有查看权限：

• ❌ 用户管理
• ⚠️ 域名管理（仅查看）
• ⚠️ 解析记录管理（仅查看）
• ⚠️ 上游管理（仅查看）
• ❌ 系统配置
• ⚠️ 日志查看（仅查看）
• ⚠️ 监控查看（仅查看）

适用对象：审计人员、访客、只读用户

权限矩阵

详细的权限对照表：

功能模块	操作	超级管理员	管理员	操作员	访客
用户管理	查看列表	✅	✅	❌	❌
	创建用户	✅	❌	❌	❌
	编辑用户	✅	❌	❌	❌
	删除用户	✅	❌	❌	❌
	重置密码	✅	❌	❌	❌
	解锁用户	✅	❌	❌	❌
域名管理	查看列表	✅	✅	✅	✅
	创建域名	✅	✅	✅	❌
	编辑域名	✅	✅	✅	❌
	删除域名	✅	✅	✅	❌
	批量导入	✅	✅	✅	❌
	批量导出	✅	✅	✅	✅
解析记录	查看列表	✅	✅	✅	✅
	创建记录	✅	✅	✅	❌
	编辑记录	✅	✅	✅	❌
	删除记录	✅	✅	✅	❌
	批量导入	✅	✅	✅	❌
	批量导出	✅	✅	✅	✅
上游管理	查看上游	✅	✅	✅	✅
	创建上游	✅	✅	❌	❌
	编辑上游	✅	✅	❌	❌
	删除上游	✅	✅	❌	❌
	配置策略	✅	✅	❌	❌
	健康检查	✅	✅	❌	❌
系统配置	查看配置	✅	✅	❌	❌
	修改配置	✅	✅	❌	❌
日志管理	查看日志	✅	✅	✅	✅
	导出日志	✅	✅	✅	✅
	清理日志	✅	✅	❌	❌
系统监控	查看监控	✅	✅	✅	✅

权限校验流程

前端权限控制

前端界面根据用户角色显示/隐藏功能：

// 检查是否有权限
const hasPermission = (requiredRole) => {
  const userRole = getUserRole();
  const roleHierarchy = {
    'super_admin': 4,
    'admin': 3,
    'operator': 2,
    'viewer': 1
  };
  return roleHierarchy[userRole] >= roleHierarchy[requiredRole];
};

// 使用示例
if (hasPermission('admin')) {
  // 显示管理员功能
}

后端权限控制

后端 API 通过中间件进行权限校验：

// 权限校验中间件
func PermissionMiddleware(requiredRole string) gin.HandlerFunc {
  return func(c *gin.Context) {
    userRole := c.GetString("user_role")
    
    if !checkRolePermission(userRole, requiredRole) {
      c.JSON(403, gin.H{"error": "权限不足"})
      c.Abort()
      return
    }
    
    c.Next()
  }
}

// 路由配置
api.POST("/user/add", 
  middleware.AuthMiddleware(),
  middleware.PermissionMiddleware("super_admin"),
  userHandler.AddUser)

自定义权限（未来规划）

当前版本使用预定义角色，后续版本计划支持：

自定义角色

允许创建自定义角色，灵活组合权限：

角色名称: 自定义管理员
权限列表:
  - domain:read      # 域名查看
  - domain:write     # 域名编辑
  - record:read      # 记录查看
  - record:write     # 记录编辑
  - upstream:read    # 上游查看
  - log:read         # 日志查看
  - monitor:read     # 监控查看

细粒度权限

支持更细粒度的权限控制：

• 数据权限：限定可管理的域名范围
• 操作权限：限定可执行的操作类型
• 时间权限：限定可操作的时间段

API 权限校验

获取当前用户权限

GET /api/user/permissions
Authorization: Bearer YOUR_TOKEN

响应示例：

{
  "code": 200,
  "data": {
    "role": "admin",
    "permissions": [
      "domain:read",
      "domain:write",
      "domain:delete",
      "record:read",
      "record:write",
      "record:delete",
      "upstream:read",
      "upstream:write",
      "log:read",
      "monitor:read"
    ]
  }
}

检查权限

POST /api/user/check-permission
Authorization: Bearer YOUR_TOKEN
Content-Type: application/json

{
  "permission": "domain:write"
}

最佳实践

权限分配原则

1. 最小权限原则

   • 只分配用户完成工作所需的最小权限
   • 避免过度授权

2. 职责分离

   • 用户管理与业务管理分离
   • 关键操作需要多人确认

3. 定期审查

   • 定期审查用户权限分配
   • 及时回收不再需要的权限

角色分配建议

场景	推荐角色	说明
系统部署者	超级管理员	需要完整权限进行初始配置
运维团队负责人	管理员	日常运维管理，不需要用户管理
DNS 维护人员	操作员	仅需要管理域名和记录
安全审计人员	访客	只读权限查看配置和日志
临时协作人员	访客	短期查看权限

安全建议

1. 保护超级管理员账号

   • 限制超级管理员账号数量（建议 1-2 个）
   • 强密码策略
   • 启用双因素认证（后续版本支持）

2. 操作审计

   • 启用操作日志记录
   • 定期审查敏感操作
   • 关注权限变更记录

3. 账号生命周期管理

   • 员工离职及时禁用账号
   • 定期清理长期未使用账号
   • 密码定期更换

常见问题

Q: 如何查看自己的权限？

在 Web 界面的「个人资料」页面查看当前角色和权限列表。

或通过 API：

GET /api/user/permissions

Q: 可以给单个用户分配特定权限吗？

当前版本不支持，用户权限通过角色间接分配。如需特殊权限，建议创建自定义角色（后续版本支持）。

Q: 权限变更何时生效？

权限变更立即生效，但已登录用户需要重新登录才能看到界面变化。

Q: 可以限制用户只能管理特定域名吗？

当前版本不支持域名级别的权限控制，计划在后续版本添加数据权限功能。

Q: 操作日志记录哪些内容？

系统会记录以下操作：

• 用户登录/登出
• 域名增删改
• 解析记录增删改
• 上游配置变更
• 系统配置变更
• 用户管理操作

相关文档

• 用户系统 - 了解用户管理功能
• JWT 认证 - 了解认证机制
• API 文档 - 查看认证相关 API