Kubernetes Supply Chain Security：镜像签名、准入控制与策略引擎（OPA/Kyverno）

好的，各位观众老爷，各位技术大咖，以及各位在代码海洋里摸爬滚打的程序猿们，晚上好！(此处应该有掌声👏)

今天咱们要聊的，可是个既重要又有点神秘的话题：Kubernetes Supply Chain Security，也就是Kubernetes供应链安全。

啥是供应链？简单来说，就是你从开始写代码，到最终把应用跑在Kubernetes集群里，这整个过程就像一条链子，环环相扣。任何一个环节出了问题，整个链条都可能断裂，你的应用就可能遭受攻击。

那为啥要重视它呢？你想啊，如果你的镜像被人篡改了，或者你的集群准入策略形同虚设，那岂不是给黑客开了后门，让他们在你家里溜达？细思极恐啊！😱

所以，今天咱们就来扒一扒 Kubernetes 供应链安全这件“皇帝的新衣”，看看它到底有哪些门道，以及我们该如何才能穿得安全又放心。

一、供应链安全：你的代码，真的安全吗？

咱们先来聊聊供应链安全的重要性。想象一下，你辛辛苦苦写了一堆代码，测试得完美无缺，结果打包成镜像的时候，被人偷偷塞了个恶意程序进去，等你部署到集群里，就等着被黑客收割吧！这种事情，可不是危言耸听，而是真实存在的威胁。

供应链安全主要关注以下几个方面：

代码安全： 你的代码有没有漏洞？有没有使用不安全的依赖？
构建安全： 镜像构建过程是否可信？有没有被篡改？
镜像安全： 镜像本身是否包含漏洞？是否符合安全标准？
部署安全： 只有经过验证的镜像才能部署到集群中吗？

二、镜像签名：给你的镜像盖个“防伪章”

镜像签名，顾名思义，就是给你的镜像盖个“防伪章”，证明这个镜像是你发布的，没有被篡改过。就像咱们买东西要认准品牌一样，Kubernetes也要认准“正品镜像”。

1. Sigstore：镜像签名的明星选手

目前，Sigstore 是一个非常流行的镜像签名方案。它是一个开源项目，旨在简化软件签名的过程，让开发者能够轻松地对镜像进行签名和验证。

Sigstore 主要包含以下几个组件：

Cosign： 用于对镜像进行签名和验证的命令行工具。
Fulcio： 用于颁发短期证书的证书颁发机构 (CA)。
Rekor： 一个防篡改的日志服务，用于记录签名信息。

2. Cosign 的工作原理

Cosign 的工作原理大概是这样的：

生成密钥对： 你需要先生成一对密钥，一个公钥，一个私钥。私钥用于签名，公钥用于验证。
使用私钥签名镜像： 使用 Cosign 工具，用你的私钥对镜像进行签名。
将签名信息上传到 Rekor： Cosign 会将签名信息（包括镜像的摘要、签名、公钥等）上传到 Rekor，以便后续验证。
验证镜像： 当你需要验证镜像时，可以使用 Cosign 工具，通过 Rekor 中记录的签名信息来验证镜像的真实性。

3. Cosign 的优势

易用性： Cosign 的命令行工具非常简单易用，即使是新手也能快速上手。
安全性： Sigstore 使用短期证书和防篡改的日志服务，确保签名信息的安全可靠。
集成性： Cosign 可以与 Docker Hub、GitHub Container Registry 等主流的镜像仓库集成。

4. Cosign 的简单示例

# 1. 生成密钥对
cosign generate-key-pair

# 2. 使用私钥签名镜像
cosign sign --key cosign.key your-image:latest

# 3. 验证镜像
cosign verify --key cosign.pub your-image:latest

三、准入控制：守好 Kubernetes 集群的大门

光有镜像签名还不够，你还需要一个可靠的“门卫”，来守住 Kubernetes 集群的大门，只有经过验证的镜像才能进入集群。这就是准入控制的作用。

1. Kubernetes 准入控制器：你的安全卫士

Kubernetes 准入控制器是拦截 Kubernetes API 请求的插件，它们可以在对象被持久化到 etcd 之前，对请求进行验证和修改。你可以把它想象成一个“海关”，对进入 Kubernetes 集群的“货物”进行检查。

Kubernetes 提供了多种准入控制器，例如：

AlwaysAdmit： 允许所有请求通过。（相当于没门卫 😅）
AlwaysDeny： 拒绝所有请求通过。（直接锁国 🤣）
NamespaceLifecycle： 防止在不存在的命名空间中创建对象。
PodSecurityPolicy： 控制 Pod 的安全上下文。
ImagePolicyWebhook： 允许自定义的 Webhook 来验证镜像。

2. ImagePolicyWebhook：自定义你的准入策略

ImagePolicyWebhook 允许你使用自定义的 Webhook 来验证镜像。这意味着你可以编写自己的代码，根据你的需求来定义准入策略。

例如，你可以编写一个 Webhook，只允许使用经过签名的镜像，或者只允许使用来自特定仓库的镜像。

3. ImagePolicyWebhook 的工作原理

用户发起请求： 用户尝试在 Kubernetes 集群中创建 Pod。
API Server 拦截请求： Kubernetes API Server 拦截到该请求。
调用 Webhook： API Server 调用你配置的 ImagePolicyWebhook。
Webhook 验证镜像： Webhook 接收到请求后，根据你定义的策略验证镜像。
返回结果： Webhook 将验证结果返回给 API Server。
API Server 决定是否允许请求： 如果 Webhook 返回允许，则 API Server 允许请求通过；否则，API Server 拒绝请求。

4. 配置 ImagePolicyWebhook

你需要配置 Kubernetes API Server，告诉它使用你的 Webhook。这通常需要在 kube-apiserver 的配置文件中进行设置。

具体配置方法可以参考 Kubernetes 官方文档。

四、策略引擎：OPA/Kyverno，让你的策略更灵活

ImagePolicyWebhook 虽然可以自定义准入策略，但如果你的策略非常复杂，或者需要频繁修改，那么编写和维护 Webhook 可能会变得非常困难。这时候，就需要策略引擎来帮忙了。

策略引擎可以让你使用声明式的语言来定义策略，而无需编写大量的代码。目前，比较流行的策略引擎有 OPA 和 Kyverno。

1. OPA (Open Policy Agent)：策略界的“瑞士军刀”

OPA 是一个通用的策略引擎，它可以用于各种场景，例如 Kubernetes 准入控制、API 授权、微服务安全等。你可以把它想象成一把“瑞士军刀”，功能强大，用途广泛。

OPA 使用 Rego 语言来定义策略。 Rego 是一种声明式的查询语言，它可以让你轻松地表达复杂的策略逻辑。

2. Kyverno：专为 Kubernetes 而生

Kyverno 是一个专为 Kubernetes 而设计的策略引擎。它可以直接在 Kubernetes 集群中运行，并且可以与 Kubernetes API 无缝集成。你可以把它想象成一个“量身定制的西装”，非常合身。

Kyverno 使用 Kubernetes 风格的 YAML 文件来定义策略。这意味着你可以使用你熟悉的 Kubernetes API 来管理你的策略。

3. OPA vs Kyverno：如何选择？

特性	OPA	Kyverno
适用场景	通用策略引擎，适用于各种场景	专为 Kubernetes 而设计
策略定义语言	Rego	Kubernetes YAML
学习曲线	较陡峭，需要学习 Rego 语言	较平缓，熟悉 Kubernetes API 即可
集成性	需要手动集成到 Kubernetes 中	与 Kubernetes API 无缝集成
功能	功能强大，可以实现复杂的策略逻辑	功能丰富，可以实现常见的 Kubernetes 策略
社区	成熟的社区，拥有大量的文档和示例	活跃的社区，发展迅速

总的来说，如果你需要一个通用的策略引擎，并且愿意学习 Rego 语言，那么 OPA 是一个不错的选择。如果你只需要在 Kubernetes 中使用策略引擎，并且希望使用熟悉的 Kubernetes API 来管理策略，那么 Kyverno 更加适合你。

4. 使用 Kyverno 定义策略

下面是一个使用 Kyverno 定义策略的示例，该策略要求所有 Pod 必须使用经过签名的镜像：

apiVersion: kyverno.io/v1
kind: Policy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: enforce
  rules:
  - name: check-image-signature
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Image must be signed"
      pattern:
        spec:
          containers:
          - image: "ghcr.io/your-org/*:*" # 修改为你的镜像仓库
            =(securityContext):
              =(seccompProfile):
                =(type): RuntimeDefault
      deny:
        conditions:
          all:
          - key: "{{ images }}"
            operator: AnyNotIn
            value:
            - image: "ghcr.io/your-org/*:*"

这个策略定义了一个名为 require-signed-images 的规则，该规则会检查所有 Pod 的镜像是否经过签名。如果镜像没有经过签名，则会拒绝创建 Pod。

五、总结：打造坚不可摧的 Kubernetes 供应链

今天咱们聊了 Kubernetes 供应链安全的重要性，以及如何使用镜像签名、准入控制和策略引擎来保护你的应用。希望这些知识能够帮助你打造一个坚不可摧的 Kubernetes 供应链，让你的应用安全无忧！

最后，送给大家一句忠告：安全无小事，防患于未然！多一份安全意识，少一份安全风险！

感谢大家的观看！咱们下期再见！(此处应该有热烈的掌声👏和鲜花💐)

六、扩展阅读

Sigstore 官方网站: https://www.sigstore.dev/
OPA 官方网站: https://www.openpolicyagent.org/
Kyverno 官方网站: https://kyverno.io/
Kubernetes 准入控制器官方文档: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/

希望这篇文章能够帮助大家理解 Kubernetes 供应链安全，并在实践中应用这些技术，保护你的应用安全！记住，安全不是一蹴而就的，而是一个持续改进的过程。加油！💪

发表回复 取消回复

发表回复取消回复