Harbor架构

由于docker registry只提供了基本的镜像上传下载保存功能，在用户认证及鉴权、多用户管理、安全扫描、镜像清理、镜像同步等部分有所欠缺，因此如果要在公司内部使用镜像仓库，推荐使用harbor。

Harbor 2.0版本支持OCI（Open Container Initiative）镜像（如镜像、Helm Chart等）以及OCI镜像索引。镜像索引是一种high level manifest，指向一个manifest列表。通过镜像索引，可以根据client端的架构不同，自动下载对应架构的镜像。（创建多架构支持的镜像方法参考）

Harbor 2.0的整体架构如下图所示。

image.png

整个Harbor架构可以分为三层，分别为Consumer、Fundamental Service和Data Access Layer。

Consumer是Harbor的使用方。除了Harbor自带的前端界面（web portal）外，也可以通过其他client访问harbor，如kubelet、helm、docker等。

Fundamental Service模块较多，后面介绍。

Data Access Layer用于数据存储。主要有三块：

• 键值对存储： 使用的是Redis。redis主要用来进行registry缓存、session存储包括后期的helm chartmuseum缓存。
• 数据存储： 用于存储registry（镜像）和chart数据。支持对接块存储、文件存储和对象存储。
• 数据库： 使用的是PG，存储Harbor使用到的各个表。包括projects, users, roles, replication policies, tag retention policies, scanners, charts, images等

下面介绍下Fundamental Service的各个组成模块。

Harbor自带的模块主要有以下几个：

• Core： Core模块包含较多子模块，每个模块中也有自己的子模块。
  • API Server： 接收Rest 请求，并通过子模块处理后返回结果。
    • Authentication & Authorization
      • Authentication服务：通过本地数据库、AS/LDAP或OIDC对请求进行Authentication（登陆认证）
      • Authorization服务：对action进行RBAC鉴权，如pull/push镜像。
      • Token Service：根据用户对project的权限，签发不同的token用于push/pull等操作。如果docker client发送的请求不含token，Registry会将请求重定向到token服务。
    • MiddleWare： 中间件用于请求的预处理，确定请求是否需要转发到后端。包含的预处理功能有“quota management”， “signature check”， “vulnerability severity check”和“robot account parsing”等。
    • API Handlers： 解析、验证请求参数，根据相应的API controller完成业务逻辑处理，并生成相应的响应。
  • Config Manager： 系统配置管理。
  • Project Management： 管理Project(namespace)。
  • Quota Manager: 管理Project的quota配额。
  • Chart Controller： 转发chart相关的处理请求到后端chartmuseum 。提供了一些扩展来优化chart管理。
  • Retention Manager：管理tag回收（保留）策略，并执行和监控。
  • Content Trust： 方便使用Notary功能的一个扩展（插件）。
  • Replication Controller： 管理镜像复制（备份）策略，并执行和监控；适配不同registry。当前适配的registry有docker registry、Docker hub、Huawei SWR等，参考架构图。
  • Scan Manager： 镜像扫描，提供扫描结果。支持对接Trivy，Clairs等。
  • Notification Manager：webhook回调管理。支持HTTP POST请求和Slack channel。
  • OCI Artifact Manager：提供OCI制品的全生命周期管理（CRUD）。包括安全扫描报告、镜像构建历史等镜像元数据及额外信息的管理；helm charts的readme、dependencies、value.yaml文件管理；制品的Tag管理等。
  • Registry Driver： 与底层的registry（目前是docker registry）进行通信的registry client SDK。OCI Artifact Manager需要通过该组件获取制品的manifest及Config JSON等信息。
• GC controller： GC。删除镜像后，需要通过GC将存储空间释放。
• Log Collector： 日志记录。
• Job Service： 异步任务处理。如镜像定时扫描等。

依赖的外部模块有：

• Proxy：提供代理服务，使用的是Nginx，将consumer的请求代理转发到后端的各个模块。
• Notary：Notary 是一套镜像的签名工具， 用来保证镜像层在 pull、push、transfer 过程中的一致性和完整性。避免中间人攻击，阻止非法的镜像更新和运行。镜像层的创建者可以对镜像层做数字签名，生成摘要，保存在 Notary 服务中。开启 Content Trust 机制之后，未签名的镜像无法被拉取。

关于notary的详细功能见： https://github.com/zj1244/Blog/blob/master/2019/harbor%E7%9A%84Notary%E5%8A%9F%E8%83%BD%E6%B5%8B%E8%AF%95.md

• Chart Museum：用于保存helm chart镜像的组件。
• Docker Distribution（docker registry）：harbor本身不提供镜像上传/下载等功能，相关功能是通过调用docker registry的API实现的。因此，需要依赖到docker registry服务。
  另外支持对接一些外部模块，如镜像扫描使用的Clair和Trivy，镜像备份使用的Docker Distribution、Docker Hub等。

docker login的过程

1. Proxy在80端口接收到请求，并转发给Registry container。
2. Registry container需要token-based authentication。会返回401，并告诉client从指定的URL（指向token service）获取token。
3. docker client发送请求到token service。（请求头中包含username和password，用于HTTP的basic authentication）
4. proxy在80端口接收到请求后，会将请求转发到UI container中（UI container中包含token service）。token service接收到请求后，获取其中的username和password。
5. token service将username和password在数据库或者是LDAP/AD等服务中进行authentication。成功后，返回一个HTTP状态码表示认证成功，并将通过私钥生成的token放在返回的body中。
6. docker client接收到成功的返回后，将用户名密码编码后保存在本地的文件中。

docker push镜像过程。

docker push xxx/library/hello-world

1. 首先，同登陆一样，docker client会发送请求，并拿到token service的URL。
2. 然后，docker client向token service发送请求，除了用户名密码外，在请求中还会提供一些额外信息（action为push，resource为library/hello-world）。
3. token service查询数据库，获取用户绑定的角色（role），查看是否有权限进行push镜像。有权限则编码push操作对应的信息，并使用私钥签发token给docker client。
4. docker client发送push请求到registry，并在header中带上token。registry使用公钥解码token后，验证内部信息。如果验证通过，则开始上传流程。
   如果需要临时访问密钥，则可以用harbor的私钥签发一个带有时效的token即可。