企业级微服务构建-01搭建和使用Maven私有仓库(Nexus)-07访问控制

亲历的企业级微服务的完整构建过程-系列文章目录

本人参与了这次的企业级微服务的完整构建，想要记录下来以便以后复习，同时也想分享给小伙伴们，抛砖引玉，欢迎大家提出自己的意见和建议，大家一起探讨一起成长。以下为该系列所有文章的链接：

1. 搭建和使用Maven私有仓库(Nexus)（更新中。。。）
2. API网关（待发布）
3. 认证中心（待发布）
4. Redis框架（待发布）
5. RabbitMQ（待发布）
6. MyBatis（待发布）
7. Web模块（待发布）
8. 低代码（待发布）
9. Core
   1. JSON工具类（待发布）
   2. 日期工具类（待发布）
   3. String工具类（待发布）
   4. Number工具类（待发布）
   5. Spring操作工具类（待发布）
   6. API结构统一封装（待发布）
10. 监控和告警（待发布）
11. MongoDB（待发布）

---

搭建和使用Maven私有仓库(Nexus)-系列文章目录

说明：

• 以下部分模块，绝大多数人，在日常工作中都是用不到的，所以我就没有介绍，毕竟时间是最重要的成本，没必要花大量时间在我们用不到的内容上。
• 下面的“1 通用”章节，系列文章中的每一篇内容都相同，介绍一些背景、约定和官网链接等，大家只要知道这些内容了，就不用每篇文章都去看了。

1. 安装步骤
2. 登录和界面
3. 备份和恢复
4. 管理：讲述了Nexus的管理功能，包括用户管理、权限管理、任务管理等
   1. 管理菜单
   2. 仓库管理
   3. 格式（Formats）（暂时用不到，略）
   4. 分期（Staging）（暂时用不到，略）
   5. 标记（Tagging）（暂时用不到，略）
   6. Maven和Jenkins插件（暂时用不到，略）
   7. 任务（Tasks）
   8. 访问控制
      1. 领域（Realms）管理
      2. 权限（Privileges）管理
      3. 角色（Roles）管理
      4. 用户（Users）管理
      5. 默认角色（Default Role）管理
      6. 内容选择器（Content Selectors）管理
   9. 用户认证（暂时用不到，略）
   10. 能力（Capabilities）（暂时用不到，略）
   11. 节点（Nodes）
   12. 配置SSL
   13. HTTP和HTTPS请求和代理设置（暂时用不到，略）
   14. 电子邮件服务器配置
   15. 重试限制配置（暂时用不到，略）
   16. 审计
   17. 安装和更新许可证
   18. 支持功能
5. 使用Nexus仓库：讲述了使用（而非管理） Nexus Repository 的方方面面的知识
   1. 仓库管理器概念：使用 Nexus 需要先理解一些概念，该节内容提供了必要的背景和知识
      1. 组件、仓库和仓库格式（暂时用不到，略）
      2. 一个示例 - Maven 仓库格式（暂时用不到，略）
      3. 管理仓库（暂时用不到，略）
      4. 软件供应链自动化（暂时用不到，略）
      5. 代理仓库概念（暂时用不到，略）
   2. 用户界面概述
   3. 搜索组件（暂时用不到，略）
   4. 浏览仓库和仓库组
   5. 管理当前登录用户的资料
   6. 上传组件
   7. 查看标签（仅可用于Pro版本，略）
6. 集成（主要讲述了如何使用 APIs 和 集成外部工具）（暂时用不到，略）
7. Maven中配置和使用Nexus

---

---

正文

1 通用

1.1 前言

在构建微服务之前，需要先做一些准备工作，比如Maven私有仓库的管理。因为有些微服务模块是作为公共组件被其他微服务引用的，这些公共的微服务，就要设置为依赖，并用Maven仓库管理起来，将自定义的依赖上传到Maven中央仓库并不是一个明智的选择。原因有3个：

1. 最重要的是隐私和安全问题，我们不可能把企业内部开发的组件上传到公共网络，让所有人能够随便下载；
2. 上传很麻烦，上传方法详见 https://blog.csdn.net/agonie201218/article/details/124800163；
3. 可能不允许上外网，则无法上传；
4. 可能会有网络延迟、上传缓慢的问题。
5. 降低了中央仓库的负担。

综上，我们最好是搭建自己的私有Maven仓库，而当前最流行的就是 Sonatype Nexus Repository Manager，以下简称 Nexus。

1.2 约定

1. 我使用的版本是 OSS 3.40.1-01，整个系列的文章都是在该版本上展开介绍，你们可能使用的是 Pro 版，少数模块是我的 OSS 版上没有的。不过一般使用的话，OSS 版已经够用了
2. 文中出现的 Repository ，中文称之为“仓库”
3. 文中出现的变量 $install-dir，值为 /opt/sonatype/nexus
4. 文中出现的变量 $data-dir，值为 /opt/sonatype/sonatype-work/nexus3 ，或 /nexus-data，两者都是在docker容器nexus中的路径，一个是软链接，一个是实际路径
5. 文中出现的变量 ${jetty.etc}，值为 /opt/sonatype/nexus/etc/jetty
6. NXRM：Nexus Repository Manager，即 Nexus 仓库管理器
7. RBAC：Role-Based Access Control，即 基于角色的访问控制

1.3 官方文档

提供Nexus的官方文档：https://help.sonatype.com/repomanager3/
官方文档包含了系统要求、搭建方法，以及各种操作方法等，内容已经非常全面了。

2 访问控制

Nexus Repository 使用基于角色的访问控制（RBAC）来赋予管理员细粒度的用户权限控制：

1. 对 Nexus Repository 网络应用程序的访问
2. 对仓库中组件路径的读访问
3. 对配置模块的管理员访问
4. 发布或上传文件到一个仓库

默认配置附带了 Administrator 角色和可选的匿名访问（Anonymous Access），来浏览和读取所有仓库。当需要创建一个受保护的仓库时，我们不应该使用默认的 Anonomous 角色。Nexus Repository 提供了一个能适应任何场景的安全模型。

注：默认的 Administrator 角色提供了 Nexus Repository 系统的所有方面的权限，并且默认分配给了用户 admin。admin 的初始密码可以在 Nexus 启动后，在 $data-dir/admin.password 文件中找到。注意：一旦修改了初始密码，$data-dir/admin.password 文件会自动被删除。

RBAC 遵循“最小权限”（Least Privilege）原则，该原则基于完成工作需要访问的功能，给予用户最少的访问权限。Nexus Repository内部创建的角色，可以被加入到外部角色和组，该外部角色和组被你的组织的目录服务所管理。将角色的分配委托给外部系统，极大减少了新用户入职/离职的开销成本。

以下是一个新的团队入职的例子：

“Apollo”开发团队需要一个托管仓库“dev-apollo”的访问权限。团队成员们被分配到公司活动目录（Active Directory）的组中。
仓库管理员创建了一个新的角色“team-apollo”，并在活动目录中，将它分配给“Apollo”组。
admin 用户给该角色添加了那个仓库的browse，read 和 write的权限：

1. nx-repository-view-maven2-dev-apollo-add
2. nx-repository-view-maven2-dev-apollo-read
3. nx-repository-view-maven2-dev-apollo-browse

在活动目录中，团队成员们被添加进或移出“Apollo”组。

注：
对 Nexus Repository 的使用权是授予的，不是撤销的。某个权限允许的访问，不能被另一个权限收回。因此，最佳实践是仅仅提供一个团队需要的资源的使用权。从长远来看，使用通配符权限（使用 * ）可能并不可取，因为这需要相当大的精力去审计和回退。

下面先简单介绍下 Nexus 中的一些概念：

1. 领域（Realms）
   RBAC 系统需要不同的认证和授权系统提供支持。

2. 权限（Privileges）
   权限是和 Nexus Repository 的功能进行交互的各个层级的权利。仓库管理器附带了一组不可修改的核心权限。新的仓库在创建时，自动添加了一些权限。

3. 角色（Roles）
   权限可以被分组伟角色，一遍更容易为用户定义通用的访问模式。为了更加容易地通过相似的权限组来管理用户，我们使用角色，而不是分配单独的权限给单独的用户。

4. 用户（Users）
   用户可以被直接添加和管理，而不必使用外部的领域。用户可以被分配给一个或多个角色，也可以直接被分配权限。

5. 内容选择器（Content Selectors）
   我们可以使用内容选择器来配置特定命名空间或仓库位置的访问权。内容选择器被添加到自定义权限上，从而给那些资源授予访问权。

6. 默认角色（Default Role）
   默认角色能力可以被用来分配一个通用权限组给所有已认证的用户。这对于“允许组织中每个人有一个标准级别的访问权”很有用（注意是能够通过你配置的 Realms 进行认证的每个人）。