本周 KubeCon + CloudNativeCon North America 2022 已经结束，看 timeline 有了一种几乎所有人都去参加的错觉，大概也是受近几年各类因素的影响，很多人也都没有线下聚会之类的。

在这次大会上，有很多有意思的内容，简单的概括一下：

当前的 Kubernetes 生态中有太多的工具，在做相同或者类似的事情，所以很多人都会面临"选择困难症"，在工具选择上需要考虑很多方面，比如技术匹配度，学习成本，灵活性，可扩展性，社区以及文档等方面。
供应链安全愈发的受到重视，很多的公司 & 工具都在积极的添加此类支持。但国内在此方面并不那么重视。我之前写了一本小册《Kubernetes 安全原理与实践》，其中覆盖了在生产中使用 Kubernetes 需要关注的各方面及其原理等内容，从反馈上看大家对此方面的关注度并不高，当然也有可能是很多公司还处于调研/测试的阶段，尚未真正迈入生产，否则的话，安全还是一个很重要的部分。
混沌工程和模糊测试等在工程实践中得到了更多关注和实践，尤其是构建金融级服务时候，产生了更大的价值。
eBPF, 安全，可观测性等持续让企业从中得到收益，越来越多的公司也选择了相关的技术栈，来丰富自己现有的产品和工具。
多集群，多租户，GitOps, 调度，Service Mesh 等仍然在探索中，并且越复杂的环境，其中衍生出来的问题就越多，尤其是需要与其他的一些工具/平台进行集成。

此外就是一些开源项目的发展和技术等内容了，有兴趣的小伙伴可以再去看看。

Sigstore 正式 GA

在本周的 SigstoreCon 上，Sigstore 社区宣布 Sigstore 正式 GA。

在去年 11 月份，我曾写过一篇文章：《云原生时代下的容器镜像安全（上） | MoeLove》其中就有介绍过 Sigstore 以及利用它来提升镜像安全，有兴趣的小伙伴可以回顾下文章。

Sigstore 的出现就是为了应对日益增长的供应链攻击的问题，并且 Sigstore 一经出现，就成为了历史上采用最快的开源技术之一，迄今为止，已使用 Sigstore 记录了超过 400 万个签名，并且世界上最大的两个开源社区 Kubernetes 和 Python 已使用 Sigstore 进行其生产 release 的签名。最近，npm 宣布他们正在积极整合 Sigstore，因此所有 npm 包都可以可靠地链接到它们的源代码和构建指令。这将极大的提高 Sigstore 的采用率。

此外，无论你在用什么 CI/CD 工具，还是在使用一些云上工具类似 GitHub Action 等都可以很轻松的与 Sigstore 进行集成，以下是一个简单的示例：

...

jobs:
  build:
    steps:
      # ... build steps here

      - uses: sigstore/cosign-installer@main

      - name: Write signing key to disk (only needed for `cosign sign --key`)
        run: echo "${{ secrets.SIGNING_SECRET }}" > cosign.key

      - name: Sign container image
        run: |
          cosign sign --key cosign.key \
            ghcr.io/your-org/your-repo:some-tag
        env:
          COSIGN_PASSWORD: ""

然后在部署之前进行验证：

$ cosign verify --key cosign.pub ghcr.io/your-org/your-repo:some-tag

Verification for ghcr.io/your-org/your-repo:some-tag --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key
  - Any certificates were verified against the Fulcio roots.

[{"critical":{"identity":{"docker-reference":"ghcr.io/your-org/your-repo"},"image":{"docker-manifest-digest":"sha256:..."},"type":"cosign container image signature"},"optional":{}}]

更多详细信息请参考 Sigstore Announces General Availability at SigstoreCon - Open Source Security Foundation

Kyverno 1.8 正式发布

我之前已经写过一些 Kyverno 相关文章了，感兴趣的小伙伴可以回顾下《云原生策略引擎 Kyverno （上） | MoeLove》

本次发布的 v1.8 包含了很多值得关注的特性，一起来看看：

YAML Manifest 的验证

Kyverno 之前已经与 Sigstore 进行了集成，可以进行镜像的签名校验（常规功能），本次 1.8 中集成了 Sigstore 的 k8s-manifest-sigstore 工具，通过这次的集成，Kyverno 还可以验证 Kubernetes YAML manifest 上的签名，以便确保它们没有被篡改。

一旦用户使用私钥对 YAML manifest 进行了签名，就可以使用类似下方示例中的策略文件对其进行校验了。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-manifest-integrity
spec:
  validationFailureAction: audit
  background: true
  rules:
    - name: verify-deployment-allow-replicas
      match:
        any:
        - resources:
            kinds:
              - Deployment
      validate:
        manifests:
          attestors:
          - count: 1
            entries:
            - keys:
                publicKeys: |-
                  -----BEGIN PUBLIC KEY-----
                  MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEStoX3dPCFYFD2uPgTjZOf1I5UFTa
                  1tIu7uoGoyTxJqqEq7K2aqU+vy+aK76uQ5mcllc+TymVtcLk10kcKvb3FQ==
                  -----END PUBLIC KEY-----                                    
          ignoreFields:
          - objects:
            - kind: Deployment
            fields:
            - spec.replicas

这里需要注意的是，在 Kubernetes 中对 YAML manifest 签名时，需要考虑哪些内容是需要变更的，比如 spec.replicas 就可能经常发生变更，所以此处需要忽略它。否则当出现变更时候，就会被此策略拒绝。当然也还可以根据实际情况去忽略其他的字段。

与 Pod Security 的集成

作为 Pod Security Policy (PSP) 的替代品，Pod Security Admission（PSA）在 Kuberenetes v1.23 中默认启用，并在 1.25 中达到 stable 状态，PSA 带来了 Pod Security Standards | Kubernetes 。

Kyverno 从 1.8 开始增加了 podSecurity 的验证规则，它使用了和 PSA 相同的库，所以是完全兼容的。以下是一个简单的示例：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: podsecurity-restricted
spec:
  background: true
  validationFailureAction: audit
  rules:
  - name: restricted
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      podSecurity:
        level: restricted
        version: latest

它为整个集群实现了 PSA 的 restricted 策略。

上游进展

Normalize HTTP lifecycle handlers with HTTP probers by jasimmons · Pull Request #86139 · kubernetes/kubernetes

我们可以为 Pod 增加 postStart 和 preStop 的 Hook，并且其分别可以设置为 Exec 或 HTTP 模式。这个 PR 主要是在修改 HTTP 模式下的行为。

具体来说，HTTP 模式下的代码与 readiness/liveness 下使用的并不一样，而且也不支持一些常见的功能，比如：

设置自定义 HTTP header
使用 HTTPS 连接

但经过此 PR ,终于将它们的行为进行了统一，但这毕竟是一个比较大的调整，如果你不希望应用此变更，可以通过 -feature-gates=ConsistentHTTPGetHandlers=false 进行全局禁用，避免这个功能影响到你的环境。

其他

#952 Cilium 正在申请从 CNCF 毕业。

在几年前，部署 Kubernetes 集群选择 CNI 时，Flannel 和 Calico 还是最流行的选项。不过现在 Cilium 也已经成为了一个备选。这有几个方面的原因：

eBPF 的持续火热，让 cilium 大放异彩；。
Flannel 不支持 Network Policy 等特性，无法满足企业在安全性方面的需求；
越来越多的公司开始将 Linux 内核升级到 5.x 以上了，不像之前总是在用 3.10.x ，所以可以尝试使用 eBPF 等技术了；
cilium 已经成为了很多厂商的首选，比如 GKE。我之前还写过一篇 K8S 生态周报| Google 选择 Cilium 作为 GKE 下一代数据面 | MoeLove