Skip to main content

Command Palette

Search for a command to run...

使用 Harbor 提供可信镜像

Published
•2 min read•View as Markdown

应用上云的过程中,过了部署关和应用改造关之后,安全就是下一个大问题了。对于容器化应用来说,镜像的安全是个非常根本的问题,例如 Harbor 中集成了 Clair 组件,用于对镜像进行漏洞扫描;之前介绍的 Trivy 也能够提供对镜像各层进行扫描的能力,类似的工具还有很多。在完成镜像本身的安全保障之后,一方面要把安全构建出来的镜像能够”原汁原味“的提供给运行时进行使用,同时还要对运行时环境进行约束,只允许获取和运行可靠镜像,如此才能够保证镜像供应链的完整。

快速上手

Harbor 中提供了 Notary 服务来提供了这方面的保障,Docker 17.12 之后也提供了对应的运行时支持。

这里用 1.10.0 版本的 Harbor 为例,在安装命令中加入参数 --with-notary 就可以启用这个服务了。启动 Harbor 之后,使用 Docker 客户端的终端设置环境变量:export DOCKER_CONTENT_TRUST=1。启用 Docker 的内容信任模式。

使用 docker login 命令登录仓库,然后进行镜像推送,例如:

$ docker push 10.211.55.27/sign/clare:s1
The push refers to repository [10.211.55.27/sign/clare]
bbef02a499c4: Layer already exists
...
47a4bb1cfbc7: Layer already exists
s1: digest: sha256:bafc293fd765dbbad5ed3d57d771f0566e5d63a668213f1f61c469cbb199fca6 size: 1162
Signing and pushing trust metadata
You are about to create a new root signing key passphrase. This passphrase
...
Enter passphrase for new root key with ID b52c1ba:
Repeat passphrase for new root key with ID b52c1ba:
Enter passphrase for new repository key with ID c37e6d2:
Repeat passphrase for new repository key with ID c37e6d2:
Error: trust data missing for remote repository 10.211.55.27/sign/clare or remote repository not found: timestamp key trust data unavailable.  Has a notary repository been initialized?

这里多出了一个初始化过程,在我们照章输入密码之后,发现出了错,这是因为我们没有设置 Notary 服务地址,加入环境变量来解决:export DOCKER_CONTENT_TRUST_SERVER=https://10.211.55.27:4443。

再次推送:

$ docker push 10.211.55.27/sign/clare:s1
The push refers to repository [10.211.55.27/sign/clare]
...
Repeat passphrase for new repository key with ID d6068a9:
Finished initializing "10.211.55.27/sign/clare"
Successfully signed 10.211.55.27/sign/clare:s1

可以看到,推送已经成功了,并且还有签署成功的反馈。查看一下他的签名信息:

$ docker trust inspect 10.211.55.27/sign/clare:s1
[
    {
        "Name": "10.211.55.27/sign/clare:s1",
        "SignedTags": [
            {
                "SignedTag": "s1",
                "Digest": "bafc293fd765dbbad5ed3d57d771f0566e5d63a668213f1f61c469cbb199fca6",
                "Signers": [
                    "Repo Admin"
                ]
            }

...

如果我们取消 Docker 内容信任:unset DOCKER_CONTENT_TRUST。接下来推送一个新镜像:

$ docker push 10.211.55.27/sign/alpine:latest
The push refers to repository [10.211.55.27/sign/alpine]
77cae8ab23bf: Pushed

再次开启 Docker 内容信任开关:export DOCKER_CONTENT_TRUST=1,尝试拉取:

$ docker pull 10.211.55.27/sign/alpine:latest
Error: remote trust data does not exist for 10.211.55.27/sign/alpine: 10.211.55.27:4443 does not have trust data for 10.211.55.27/sign/alpine

可以看到 Docker 拒绝了未经签署的镜像。

幕后

Docker 包含了简写为 DCT 的内容签名(Docker Content Trust)支持,能够借助 Notary 进行内容签署和校验。首次签署时会要求生成根密钥,每次创建一个新的 Repository 时候,会为其单独生成签署密钥。接下来,每个 Tag 的推送都会进行签署,从而保证内容的稳定性。

问题

  • Kubernetes 能享受到这个么?

  • 托管 Kubernetes 怎么办?

  • 多镜像仓库怎么办?

More from this blog

AI Agent 的“莫兰迪时刻”

一个新范式真正走向大众,往往不是从所有人都正确理解它开始,而是从它开始被反复引用、简化、误读,甚至滥用开始。 今天的 AI Agent,可能正走到这样一个时刻。 这篇文章的念头,来自我最近收听《大内密谈》vol.1434《审美升级or消费主义?从莫兰迪在中国聊起》时的一些联想。节目从莫兰迪色在中国的走红,谈到作品价格、知识产权、商业流量与消费主义。[9] 我听着听着想到另一个熟悉的技术史问题:为

Oct 5, 20263 min read

FDE 是传统运维产品厂商的出路吗?

很多传统运维产品厂商,已经不缺产品了。 从 ITSM、CMDB、监控、自动化,到 IAM、数据中心管理和各类大屏,一个成熟厂商往往都能拿出一张很完整的产品地图。销售材料上看,客户运维部门的日常工作几乎都被覆盖了。 但项目一落地,味道就变了。 产品越多,集成越重;模块越全,边界越模糊;客户越大,定制越深。到了后期,项目成功本身也会变成麻烦:现场改出来的东西回不到主干,配置越来越像黑箱,谁都不敢轻易升

Jun 29, 20263 min read

绵里藏针才是 AIOps 的本质?

Agent 让运维编排变得柔性、可变、甚至自演进;但真正敢进入生产环境的 AIOps,仍然离不开坚实、受控、可审计、可回退的自动化底座。 从 Gartner 提出 AIOps 概念到现在,也大概有十年了。这么多年来,这个领域好像发生了很多变化,又好像没什么“本质”的变化。技术上,我们经历了传统机器学习、深度学习和神经网络、以及大模型和智能体这样“翻天覆地”的变化;业务上,我们面对的是更多品种、更大

May 31, 20263 min read

龙虾恐慌:AIOps 又要改名了?

ChatGPT 开始,把 AI 拉近到普罗大众的面前,让无数人感受到 AI 的亲民魅力。而龙虾,则把大模型驱动的自动化能力,突然间变得水灵灵、活泼泼地走进千家万户。它不只是“风口上的猪”,而是风口本身。热度高到让 Mac mini 一度断货,不知道这在不在库克的预料之内。 每代人都有每代人的鸡蛋,春节期间,我就领了我的鸡蛋。翻出古老的 MacBook Air M1,充值各种大模型。当然了,这个工具

Mar 9, 20261 min read
【

【伪】架构师

346 posts