23、Kubernetes 镜像安全与策略治理

最新推荐文章于 2025-11-24 11:01:02 发布

backprop5master

最新推荐文章于 2025-11-24 11:01:02 发布

阅读量47

点赞数

CC 4.0 BY-SA版权

分类专栏： Kubernetes实战精要文章标签： Kubernetes 镜像安全策略治理

本文链接：https://blog.youkuaiyun.com/backprop5master/article/details/152261627

Kubernetes实战精要专栏收录该内容

27 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

Kubernetes 镜像安全与策略治理

1. 镜像安全

Pod 安全的另一个重要部分是确保 Pod 内的代码和应用程序的安全。保障应用程序代码的安全是一个复杂的话题，不过容器镜像安全的基础包括确保容器镜像仓库对已知的代码漏洞进行静态扫描。此外，还应该有一个用于运行时扫描的工具，该工具可以识别镜像开始运行后发现的漏洞，并查找潜在的恶意活动，如入侵。开源和商业公司都提供了许多扫描工具。

除了安全扫描，专注于最小化容器镜像的内容以去除不必要的依赖项，可以减少扫描时的干扰。最后，镜像安全也是投资持续交付的一个重要原因，这样在发现漏洞时可以快速修补和重新部署镜像。

镜像安全要点总结

静态扫描：确保容器镜像仓库对已知代码漏洞进行静态扫描。
运行时扫描：使用工具进行运行时扫描，识别新发现的漏洞和潜在恶意活动。
最小化内容：减少容器镜像中的不必要依赖项。
持续交付：便于快速修补和重新部署镜像。

2. 策略与治理的重要性

在 Kubernetes 集群中，资源数量会随着应用的发展从几个迅速增长到成百上千个，管理这些资源面临着巨大挑战。策略是一组关于如何配置 Kubernetes 资源的约束和条件，治理则提供了验证和执行组织策略的能力，确保所有部署到 Kubernetes 集群的资源遵循当前最佳实践、安全策略或公司规范。

常见策略示例

所有容器必须仅来自特定的容器镜像仓库。
所有 Pod 必须标有部门名称和联系信息。
所有 Pod 必须同时设置 CPU 和内存资源限制。
所有 Ingress 主机名在集群中必须唯一。
某些服务不得在互联网上可用。
容器不得监听特权端口。

3. 准入流程

要理解策略和治理如何确保资源在创建前符合要求，需要了解 API 请求通过 Kubernetes API 服务器的流程。准入控制器在 API 请求流经 API 服务器时进行操作，用于在资源保存到存储之前对其进行修改或验证。其中，变更准入控制器允许修改资源，而验证准入控制器则不允许。

这里主要关注动态可配置的准入 Webhook，集群管理员可以通过创建 MutatingWebhookConfiguration 或 ValidatingWebhookConfiguration 资源来配置一个端点，API 服务器可以将请求发送到该端点进行评估。准入 Webhook 将返回“允许”或“拒绝”指令，告知 API 服务器是否将资源保存到存储。

准入控制器类型

类型	描述
变更准入控制器	允许修改 API 请求资源
验证准入控制器	不允许修改 API 请求资源

准入流程 mermaid 流程图

graph LR
    A[API 请求] --> B[准入控制器]
    B --> C{变更准入控制器}
    C -- 允许修改 --> D[修改资源]
    C -- 不允许修改 --> E[验证资源]
    D --> F[保存到存储]
    E --> F

4. 使用 Gatekeeper 进行策略与治理

Kubernetes 项目本身没有提供实现策略和治理的控制器，但有开源解决方案，这里重点介绍 Gatekeeper。

4.1 Gatekeeper 简介

Gatekeeper 是一个 Kubernetes 原生的策略控制器，它根据定义的策略评估资源，并决定是否允许创建或修改 Kubernetes 资源。这些评估在 API 请求流经 Kubernetes API 服务器时在服务器端进行，这意味着每个集群都有一个单一的处理点。在服务器端处理策略评估意味着可以在现有 Kubernetes 集群上安装 Gatekeeper，而无需更改开发人员工具、工作流程或持续交付管道。

Gatekeeper 使用自定义资源定义（CRD）来定义一组特定于配置它的新 Kubernetes 资源，这使得集群管理员可以使用熟悉的工具（如 kubectl）来操作 Gatekeeper。此外，它还能为用户提供实时、有意义的反馈，说明资源被拒绝的原因以及如何解决问题。这些特定于 Gatekeeper 的自定义资源可以存储在源代码控制中，并使用 GitOps 工作流程进行管理。

4.2 安装 Gatekeeper

在开始配置策略之前，需要安装 Gatekeeper。Gatekeeper 组件作为 Pod 在 gatekeeper-system 命名空间中运行，并配置一个准入 Webhook 控制器。

安装步骤

使用 Helm 包管理器添加 Gatekeeper 仓库：

$ helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts

安装 Gatekeeper：

$ helm install gatekeeper/gatekeeper --name-template=gatekeeper \
  --namespace gatekeeper-system --create-

确认 Gatekeeper 已启动并运行：

$ kubectl get pods -n gatekeeper-system

查看 Webhook 配置：

$ kubectl get validatingwebhookconfiguration -o yaml

4.3 配置策略

安装好 Gatekeeper 后，就可以开始配置策略了。下面通过一个示例来演示如何创建策略，以及开发人员在创建符合和不符合策略的资源时的体验。

示例：限制容器镜像来源

创建约束模板 ：约束模板定义了策略的规则，通常由集群管理员完成。以下是一个示例约束模板 allowedrepos-constraint-template.yaml ：

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8sallowedrepos
  annotations:
    description: Requires container images to begin with a repo string from a
      specified list.
spec:
  crd:
    spec:
      names:
        kind: K8sAllowedRepos
      validation:
        # Schema for the `parameters` field
        openAPIV3Schema:
          properties:
            repos:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sallowedrepos
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          satisfied := [good | repo = input.parameters.repos[_] ; good = starts...
          not any(satisfied)
          msg := sprintf("container <%v> has an invalid image repo <%v>, allowed...
        }
        violation[{"msg": msg}] {
          container := input.review.object.spec.initContainers[_]
          satisfied := [good | repo = input.parameters.repos[_] ; good = starts...
          not any(satisfied)
          msg := sprintf("container <%v> has an invalid image repo <%v>, allowed...)
        }

使用以下命令创建约束模板：

$ kubectl apply -f allowedrepos-constraint-template.yaml

创建约束资源 ：约束资源将策略应用到具体的资源上。以下是一个示例约束 allowedrepos-constraint.yaml ：

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: repo-is-kuar-demo
spec:
  enforcementAction: deny
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces:
      - "default"
  parameters:
    repos:
      - "gcr.io/kuar-demo/"

使用以下命令创建约束资源：

$ kubectl create -f allowedrepos-constraint.yaml

测试策略
- 创建符合策略的 Pod ：使用以下 compliant-pod.yaml 创建一个符合策略的 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: kuard
spec:
  containers:
    - image: gcr.io/kuar-demo/kuard-amd64:blue
      name: kuard
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP

使用以下命令创建 Pod：

$ kubectl apply -f compliant-pod.yaml

- **创建不符合策略的 Pod**：使用以下 `noncompliant-pod.yaml` 创建一个不符合策略的 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: nginx-noncompliant
spec:
  containers:
    - name: nginx
      image: nginx

使用以下命令创建 Pod：

$ kubectl apply -f noncompliant-pod.yaml

此时会收到错误信息，提示容器镜像来源不符合策略要求。

4.4 理解约束模板

约束模板是 Gatekeeper 策略配置的重要组成部分。以 allowedrepos-constraint-template.yaml 为例，它定义了一个名为 K8sAllowedRepos 的约束类型，并包含一个用于配置允许的容器镜像仓库列表的参数。模板中的 Rego 策略代码用于评估容器和初始化容器的镜像仓库名称是否符合要求。如果策略被违反，将返回 msg 部分定义的错误信息。

4.5 创建约束

要实例化一个策略，需要创建一个约束，为模板提供所需的参数。约束的 enforcementAction 字段可以设置为 deny 、 dryrun 或 warn 。 deny 表示拒绝不符合策略的资源； dryrun 用于测试策略，验证其影响； warn 则会向用户发送警告信息，但允许创建或更新资源。

4.6 审计

策略和治理不仅要对新资源实施策略，还需要确保现有资源仍然符合要求。Gatekeeper 的审计功能允许集群管理员获取集群中当前不符合策略的资源列表。

审计示例

更新约束的 enforcementAction 为 dryrun ：

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: repo-is-kuar-demo
spec:
  enforcementAction: dryrun
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces:
      - "default"
  parameters:
    repos:
      - "gcr.io/kuar-demo/"

使用以下命令更新约束：

$ kubectl apply -f allowedrepos-constraint-dryrun.yaml

创建一个不符合策略的 Pod：

$ kubectl apply -f noncompliant-pod.yaml

审计不符合策略的资源：

$ kubectl get constraint repo-is-kuar-demo -o yaml

通过以上步骤，可以全面了解和实施 Kubernetes 集群中的镜像安全和策略治理，确保集群资源的安全和合规性。

5. 策略配置的深入分析

5.1 约束模板的参数配置

在约束模板中，参数配置是非常关键的部分。以 allowedrepos-constraint-template.yaml 为例， parameters 字段定义了一个数组 repos ，用于指定允许的容器镜像仓库列表。这个配置使得策略可以灵活地适应不同的需求。例如，如果需要允许多个镜像仓库，可以在 repos 数组中添加多个值。

spec:
  crd:
    spec:
      names:
        kind: K8sAllowedRepos
      validation:
        # Schema for the `parameters` field
        openAPIV3Schema:
          properties:
            repos:
              type: array
              items:
                type: string

5.2 约束的作用范围

约束的 match 字段定义了策略的作用范围。在 allowedrepos-constraint.yaml 中， match 字段指定了策略只对 default 命名空间中的 Pod 资源生效。可以根据实际需求调整作用范围，例如：
- 可以指定多个命名空间：

match:
  kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
  namespaces:
    - "default"
    - "test"

可以指定不同的 API 组和资源类型：

match:
  kinds:
    - apiGroups: ["apps"]
      kinds: ["Deployment"]
  namespaces:
    - "default"

5.3 不同 enforcementAction 的效果对比

enforcementAction	描述
deny	拒绝不符合策略的资源创建或更新
dryrun	不实际阻止资源创建或更新，但会记录不符合策略的情况，用于测试策略
warn	向用户发送警告信息，但允许创建或更新资源

不同 enforcementAction 效果 mermaid 流程图

graph LR
    A[创建资源请求] --> B{enforcementAction}
    B -- deny --> C[拒绝请求]
    B -- dryrun --> D[记录违规情况，允许请求]
    B -- warn --> E[发送警告，允许请求]

6. 实际应用中的注意事项

6.1 资源创建和更新的影响

约束仅在资源的 CREATE 和 UPDATE 事件中生效。如果集群中已经存在大量运行的工作负载，Gatekeeper 不会重新评估这些资源，直到发生 CREATE 或 UPDATE 事件。例如，创建一个只允许特定镜像仓库的策略后，已经运行的工作负载将继续运行。当对工作负载进行扩展时，如果新创建的 Pod 不符合策略，将被拒绝。