Kata Containers genpolicy：从 Kubernetes YAML 自动生成 Kata Agent 策略的完整实战指南

云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载导读genpolicy是 Kata Containers 仓库中位于 src/tools/genpolicy 的 Kata Agent 策略自动生成工具它读取用户的 KubernetesK8sYAML 文件推断用户意图自动生成一份基于 Open Policy AgentOPARego 格式的 Kata Agent 策略文档并将策略文本 base64 编码后以注解形式追加回 YAML 文件。当该 YAML 通过 K8s 部署时Kata Agent 会依据注解指定的策略拒绝与策略不一致的 Agent API 调用。读完本文你将掌握 genpolicy 的构建方法、全部命令行参数、支持的 YAML 类型、设置目录与 drop-in 机制以及自动生成策略的默认值、规则与数据细节并能结合仓库源码验证每个结论。genpolicy 是什么工作原理与适用场景genpolicy 的完整工作流程分为四步见 src/tools/genpolicy/README.md读取用户的 Kubernetes YAML 文件推断用户意图例如 Pod 引用了哪些镜像、环境变量、卷与探针生成一份与输入 YAML 对应的 Kata Agent 策略文件采用 Open Policy Agent 格式编码将自动生成的策略文本以 base64 编码并作为注解追加到用户的 YAML 文件中。当用户通过 K8s 部署该 YAML 时Kata Agent 使用 YAML 注解指定的策略拒绝不符合策略的 Agent API 调用。更详细的机制说明见 如何配置 Kata Agent 策略。genpolicy 自动生成的策略主要用于**机密容器confidential containers**场景此时 Kata Shim 与 Kata Agent 具有不同的信任属性Shim 位于不可信的主机侧而 Agent 运行在受保护的 Guest VM 内。策略为两者之间的信任边界提供了强制手段。警告使用自动生成的策略前用户应仔细审查策略内容并根据自身用例需要修改策略文件确保其与真实部署意图一致。从源码构建 genpolicygenpolicy 是用 Rust 编写的入口为 src/tools/genpolicy/src/main.rs其中main函数依次解析命令行配置、从 YAML/settings/rules.rego 构建AgentPolicy然后调用export_policy导出策略。官方推荐在 Docker 容器中构建$ git clone https://github.com/kata-containers/kata-containers.git $ cd kata-containers $ tools/packaging/kata-deploy/local-build/kata-deploy-binaries.sh --buildgenpolicy构建产物为genpolicy可执行文件。也可以查看 Makefile 了解本地构建目标。基本执行方式最简单的用法是只提供 Kubernetes YAML 文件作为命令行参数$ genpolicy -y test.yamlgenpolicy 会把自动生成的策略文本以 base64 编码并作为注解追加到用户的 YAML 文件中。查看用法说明$ genpolicy --help高级命令行参数详见 genpolicy 高级命令行参数。支持的 Kubernetes YAML 文件类型genpolicy 支持基于以下 Kubernetes 资源类型自动生成策略源码中每种类型均有对应的模块见 src/tools/genpolicy/src 下的deployment.rs、daemon_set.rs、job.rs、pod.rs、replica_set.rs、replication_controller.rs、stateful_set.rs、cronjob.rs等文件DaemonSetDeploymentJobPodReplicaSetReplicationControllerStatefulSet此外仓库还提供了示例输入文件例如 samples/pod-one-container.yaml展示了一个包含环境变量fieldRef与普通 value、stdin、securityContext.privileged的单容器 Pod。设置目录与 drop-in 机制-j参数除了可以指向单个设置文件外还可以传入一个目录。此时 genpolicy 会从该目录加载genpolicy-settings.json并按名称排序依次应用目录下所有genpolicy-settings.d/*.json文件。每个 drop-in 必须是 RFC 6902 JSON Patch一个 JSON 操作数组支持add、remove、replace、move、copy、test六种操作。这带来了精确的控制能力例如指定数组下标并支持可选的test断言。genpolicy-settings.d/— 默认为空将你的 drop-in JSON Patch 文件放在这里。drop-in-examples/— 示例场景 drop-in10-*.json平台基座20-*.json覆盖层每个都是一个 JSON Patch 数组。把需要的文件复制到自己的genpolicy-settings.d/中即可。详见 drop-in 示例文档。这些示例在 Kata Containers CI 中经过测试。示例目录布局my-settings/ genpolicy-settings.json genpolicy-settings.d/ 10-non-coco-drop-in.json 20-oci-1.2.1-drop-in.jsongenpolicy -j my-settings/ ...drop-in 是分层的10-*文件设置平台基座20-*文件覆盖 OCI 版本及其他调整。可以组合多个 drop-in例如10-non-coco-drop-in.json20-oci-1.2.1-drop-in.json。当前仓库提供的示例及其适用场景如下表Drop-in 文件适用场景10-non-coco-drop-in.json非机密 Guest例如标准 VM10-non-coco-aks-drop-in.jsonAKS 上的非机密 Guest10-non-coco-aks-cbl-mariner-drop-in.jsonCBL-Mariner 主机上的 AKS 非机密 Guest20-oci-1.2.0-drop-in.jsonOCI bundle 版本 1.2.020-oci-1.2.1-drop-in.jsonOCI bundle 版本 1.2.1例如 k3s、rke2、NVIDIA GPU20-oci-1.3.0-drop-in.jsonOCI bundle 版本 1.3.0例如 containerd 2.2.x、CBL-Mariner需要说明的是针对请求/exec 的覆盖例如允许kubectl exec或特定 ttRPC 请求并未作为 drop-in 示例发布你需要自行构建 drop-in或将所需的request_defaults合并到genpolicy-settings.d/中的本地文件里。genpolicy 命令行参数全景以下参数均在 src/tools/genpolicy/src/utils.rs 的CommandLineOptionsclap 定义中实现本文结合文档与源码逐一说明。启用日志输出genpolicy 使用标准 Rust 日志框架通过RUST_LOG环境变量控制$ RUST_LOGinfo genpolicy -y test.yaml$ RUST_LOGdebug genpolicy -y test.yamlRUST_LOGdebug的日志比RUST_LOGinfo更详细。源码中env_logger::init()main.rs负责初始化日志。缓存容器镜像信息-u自动生成的策略中包含用于校验容器镜像完整性的信息。为了计算镜像完整性信息genpolicy 需要下载 YAML 引用的容器镜像。例如输入以下 YAMLapiVersion: v1 kind: Pod metadata: name: policy-test spec: runtimeClassName: kata containers: - name: first-test-container image: quay.io/prometheus/busybox:latest command: - sleep - 120genpolicy 会下载quay.io/prometheus/busybox:latest镜像。镜像大小与网络速度会影响下载耗时。在需要多次执行 genpolicy 的测试场景中可缓存已下载的镜像以避免重复下载。如果某个镜像层已在本地缓存genpolicy 会直接使用本地副本。缓存位于./layers_cache目录源码中由layers_cache.rs模块与ImageLayersCache实现命令行另有--layers-cache-file-path可指定缓存文件默认./layers-cache.json。警告使用缓存的镜像层可能带来不良结果。例如若某个本地缓存的层被修改例如被攻击者篡改自动生成的策略将允许这些被修改的容器镜像在 Guest VM 上执行。缓存文件格式是 genpolicy 内部格式如果缓存文件与当前 genpolicy 版本不兼容工具会删除它并重建缓存。启用缓存$ RUST_LOGinfo genpolicy -u -y test.yaml使用 containerd 拉取与管理镜像-d指定-d可使用现有的 containerd 安装作为镜像管理器。此方式支持更广泛的镜像例如使用v1manifest 的旧镜像。访问 socket 需要sudo权限$ sudo genpolicy -d -y test.yaml默认使用/var/run/containerd/containerd.sock作为 socket 路径源码中default_missing_value指定。也可以指定自定义 socket 路径$ sudo genpolicy -d/my/path/containerd.sock -y test.yaml注意源码显示该参数要求require_equals且此选项仅在 Linux 上受支持相关实现见 src/tools/genpolicy/src/containerd.rs 与registry_containerd.rs。打印策略文本-r除了把 base64 编码写入 YAML 文件外还想把自动生成的策略文本打印到标准输出使用-r$ genpolicy -r -y test.yaml打印 base64 编码的策略-b除了把 base64 编码写入 YAML 文件外还想把它打印出来使用-b$ genpolicy -b -y test.yaml使用自定义设置文件或目录-j默认设置文件为./genpolicy-settings.json。-j参数可传入设置文件或目录传入目录时genpolicy 从该目录加载genpolicy-settings.json并按名称排序应用其中所有genpolicy-settings.d/*.jsondrop-inRFC 6902 JSON Patch$ genpolicy -j my-settings.json -y test.yaml $ genpolicy -j /path/to/settings-dir -y test.yaml自定义输入文件路径-p默认情况下genpolicy 的输入文件 rules.rego 和 genpolicy-settings.json 必须存在于当前目录否则报错。可以通过-j指定不同的文件或目录、-p指定不同的规则文件$ genpolicy -p /tmp/rules.rego -j /tmp/genpolicy-settings.json -y test.yaml $ genpolicy -p /tmp/rules.rego -j /tmp/settings-dir -y test.yaml静默忽略不支持的输入 YAML 字段-s如 Kubernetes 文档所述K8s 的 YAML 字段种类非常多genpolicy 只支持其中一部分主要是常用字段。作者审查了受支持的字段并评估了每个字段对机密容器的影响部分字段未经评估或在输入 YAML 中没有意义。默认情况下遇到不支持的字段时 genpolicy 返回错误。例如输入 YAML 含apiVersion: v1 kind: Pod metadata: creationTimestamp: 2023-09-18T23:08:02Zgenpolicy 会返回错误因为指定固定的创建时间戳对 Pod 输入没什么帮助且作者未评估该字段对创建机密容器 Pod 的潜在影响。使用-s可静默忽略不支持的字段$ genpolicy -s -y test.yaml警告忽略不支持的输入 YAML 字段可能生成不可预测的错误策略。-s只应由 K8s 与机密容器的专家使用且必须先仔细评估忽略这些字段的影响。提示-s在排查已有 Kubernetes Pod 的问题时很有用例如从 Kubernetes 获取现有 Pod 的 YAMLkubectl get pod my-pod -o yaml my-pod.yaml为这个 YAML 文件自动生成策略$ genpolicy -s -y my-pod.yaml指定 ConfigMap 输入 YAML 文件-cgenpolicy 不会给 ConfigMap YAML 文件附加策略但生成其他类型 YAML 的合理策略时可能需要 ConfigMap 信息。例如仅给定以下 Pod 输入文件test.yamlapiVersion: v1 kind: Pod metadata: name: policy-test spec: runtimeClassName: kata containers: - name: first-test-container image: quay.io/prometheus/busybox:latest command: - sleep - 120 env: - name: CONFIG_MAP_VALUE1 valueFrom: configMapKeyRef: key: simple_value1 name: config-map1genpolicy 无法生成用于校验CONFIG_MAP_VALUE1环境变量期望值的策略数据。有两种方式提供所需 ConfigMap 信息。方式一命令行指定 ConfigMap YAML 文件创建test-config.yamlapiVersion: v1 kind: ConfigMap metadata: name: config-map1 data: simple_value1: value1然后用-c指定该文件$ genpolicy -c test-config.yaml -y test.yaml方式二把 ConfigMap 信息合并进输入 YAML 文件将同样的 ConfigMap 信息加到test.yaml中--- apiVersion: v1 kind: ConfigMap metadata: name: config-map1 data: simple_value1: value1 --- apiVersion: v1 kind: Pod metadata: name: policy-test spec: runtimeClassName: kata containers: - name: first-test-container image: quay.io/prometheus/busybox:latest command: - sleep - 120 env: - name: CONFIG_MAP_VALUE1 valueFrom: configMapKeyRef: key: simple_value1 name: config-map1此后不再需要-c参数$ genpolicy -y test.yaml注意源码 utils.rs 显示-c--config-map-file已标记为DEPRECATED推荐使用--config-file可多次传递支持包含 ConfigMap 与 Secret 等配置资源的 YAML 文件旧参数仍被兼容迁移到新的config_files字段中。其他高级参数源码中还定义了以下参数--insecure-registry可多次传递配置使用纯 HTTP 的不安全 registry、--runtime-class-names仅当资源的runtimeClassName是给定 runtime class 名称的前缀时才为其生成策略、--initdata-path指向 initdata TOML 文件的路径、--version打印版本信息并退出。这些参数可以在genpolicy --help输出中查看。自动生成策略的细节默认值、规则与数据详见 自动生成策略细节 与 如何配置 Kata Agent 策略 中的策略内容介绍。策略包名Kata Agent 策略的 Rego 包名必须是agent_policypackage agent_policy规则文件 的第一行就是package agent_policy。默认值default valuesgenpolicy 会把 rules.rego 中的默认值复制到自动生成的策略中。因此使用同一份rules.rego生成的所有策略具有相同的默认值。部分 ttRPC API协议定义见 agent.proto请求总是被自动生成的策略允许它们没有关联规则默认值为true。例如default CreateSandboxRequest : true default DestroySandboxRequest : true另一些请求默认值为false并至少有一条规则根据请求输入参数允许这些请求。例如default CopyFileRequest : false default CreateContainerRequest : false在 rules.rego 中可以完整看到默认值列表例如WaitProcessRequest、StartContainerRequest、SignalProcessRequest、RemoveContainerRequest等默认true而ExecProcessRequest、ReadStreamRequest、WriteStreamRequest、UpdateRoutesRequest、SetPolicyRequest等默认false。另外文件头部还注释说明了GetDiagnosticDataRequest在未于policy_data.request_defaults中启用时不受支持。关于默认值的求值语义当 Kata Shim 向 Kata Agent 发送 ttRPC 请求时策略中与该请求类型同名的规则会被求值只要有一条同名规则返回trueOPA 就返回trueAgent 放行请求若全部返回false则使用策略中该请求的默认值未提供默认值时OPA 返回空响应Agent 按false处理并拒绝请求。建议总是提供默认值便于理解策略文档及 OPA/Agent 日志。规则rulesgenpolicy 把 rules.rego 中的规则复制到自动生成的策略中。使用同一份rules.rego生成的所有策略使用相同的规则。规则通常将请求输入参数与策略数据policy data比较返回true或false以允许或拒绝请求。以CopyFile请求为例规则会遍历policy_data.request_defaults.CopyFileRequest中的正则用policy_data.common.cpath替换正则中的$(cpath)占位符再与输入路径input.path匹配完整规则示例见 策略配置文档 的 rules 一节。数据data与默认值和规则不同策略数据是针对每个输入 YAML 文件特有的。genpolicy 生成策略数据供规则根据请求输入数据允许部分 Kata Agent ttRPC 请求任何意外请求都会被策略拒绝。核心规则详解CopyFileRequest除非被拷贝文件的目标路径与policy_data.request_defaults.CopyFileRequest中至少一条正则匹配否则自动生成的策略拒绝CopyFile请求。默认情况下该字段只有一条正则由 genpolicy 从 genpolicy-settings.json 复制policy_data : { ... request_defaults: { ... CopyFileRequest: [ ^$(cpath)/ ], ... }, ... }工具把$(cpath)的值从同一设置文件复制到策略的policy_data.common.cpathcommon : { ... cpath: /run/kata-containers/shared/containers, ... }因此默认情况下自动生成的策略允许 Host 拷贝/run/kata-containers/shared/containers下的任意文件拒绝其他CopyFile请求。注意实际设置文件中cpath的正则为/run/kata-containers/shared/containers(?:/passthrough)?并额外允许$(sfprefix)前缀^$(cpath)/(watchable/)?$(bundle-id)-[a-z0-9]{16}-。用户可通过自定义设置文件修改policy_data.request_defaults.CopyFileRequest的值来改变此行为。CreateContainerRequest大多数 rules.rego 规则适用于CreateContainer请求原因有二CreateContainer的输入非常复杂——例如 OCI Spec 数据结构见 oci.proto这些复杂输入可能让有缺陷或恶意的 Host 改变用户 K8s Pod 的预期行为。例如Host 可能试图在机密容器 K8s Pod 中启动与用户 YAML 指定不同的容器镜像。因此每个 Pod 使用的策略必须验证所有容器镜像与生成策略时输入 YAML 引用的镜像完全一致。自动生成的策略数据包含输入 YAML 引用的每个容器对应的 OCI Spec 数据结构描述。例如为只启动 busybox shell 的 Pod 生成策略时工具会生成两个 OCI 数据结构——一个用于 K8spause容器另一个用于 busybox shellpolicy_data : { containers: [ { OCI: { Version: 1.1.0-rc.1, Process: { Terminal: false, User: { UID: 65535, GID: 65535, AdditionalGids: [], Username: }, Args: [ /pause ], ... }, ... }, ... }, { OCI: { Version: 1.1.0-rc.1, Process: { Terminal: false, User: { UID: 0, GID: 0, AdditionalGids: [], Username: }, Args: [ /bin/sh ], ... }, ... }, ... } ], ...自动生成的策略规则允许创建与至少一个 OCI 策略数据结构匹配的任意容器。警告自动生成的策略不跟踪 Pod 中已在运行的容器。因此上例中只要两个容器都与用户 shell 容器的策略数据匹配Kata Shim 可以在单个 Pod 中启动两个 shell 容器而非仅一个。OCI Spec 校验以下是自动生成策略中校验CreateContainer输入 OCI Spec 数据结构字段的规则示例策略 OCI 数据与输入CreateContainer数据的Version字段应匹配容器OCI.Root.Readonly字段在策略与输入数据中应取相同值正在创建的容器每个注解应与策略数据中的一个注解匹配。警告即使策略数据的某些注解不在输入 OCI 数据注解中也允许创建容器自动生成的策略只检查输入 OCI中存在的注解是否被策略数据允许验证以下注解的值与策略数据一致io.katacontainers.pkg.oci.bundle_pathio.katacontainers.pkg.oci.container_typeio.kubernetes.cri.container-nameio.kubernetes.cri.container-typeio.kubernetes.cri.sandbox-log-directoryio.kubernetes.cri.sandbox-idio.kubernetes.cri.sandbox-nameio.kubernetes.cri.sandbox-namespacenerdctl/network-namespace输入OCI.Linux.Namespaces信息与策略匹配策略OCI.Linux.MaskedPaths的所有路径也都出现在输入MaskedPaths中。警告自动生成的策略允许输入OCI.Linux.MaskedPaths包含更多路径但如果某路径被策略的oci.Linux.MaskedPaths屏蔽而输入数据未屏蔽同一路径则CreateContainer请求被拒绝策略OCI.Linux.ReadonlyPaths的所有路径都出现在输入ReadonlyPaths或输入MaskedPaths中。警告输入ReadonlyPaths可包含更多路径但若策略将某路径指定为Readonly则输入CreateContainer数据必须将其指定为Readonly或MaskedArgs、Cwd、NoNewPrivileges、Env等OCI.Process输入字段值与策略一致输入OCI.Root.Path与策略数据匹配输入OCI.Mounts被策略允许。Storages 校验Storages是 Kata AgentCreateContainer请求的另一个输入字段。每个容器的Storages策略数据由 genpolicy 基于以下内容生成用户 YAML 引用的容器镜像用户 YAML 中可能存在的volumes与volumeMounts信息genpolicy-settings.json 中的volumes数据。自动生成策略中的Storages数据示例policy_data : { containers: [ ... { OCI: { ... }, storages: [ { driver: blk, driver_options: [], source: , fstype: tar, options: [ $(hash0) ], mount_point: $(layer0), fs_group: null }, { driver: blk, driver_options: [], source: , fstype: tar, options: [ $(hash1) ], mount_point: $(layer1), fs_group: null }, { driver: overlayfs, driver_options: [], source: , fstype: fuse3.kata-overlay, options: [ 2c342a137e693c7898aec36da1047f191dc7c1687e66198adacc439cf4adf379:2570e3a19e1bf20ddda45498a9627f61555d2d6c01479b9b76460b679b27d552, 8568c70c0ccfe0051092e818da769111a59882cd19dd799d3bca5ffa82791080:b643b6217748983830b26ac14a35a3322dd528c00963eaadd91ef55f513dc73f ], mount_point: $(cpath)/$(bundle-id), fs_group: null }, { driver: local, driver_options: [], source: local, fstype: local, options: [ mode0777 ], mount_point: ^$(cpath)/$(sandbox-id)/local/data$, fs_group: null }, { driver: ephemeral, driver_options: [], source: tmpfs, fstype: tmpfs, options: [], mount_point: ^/run/kata-containers/sandbox/ephemeral/data2$, fs_group: null } ], ... } ], ... }此例中相应的CreateContainer请求输入预期包含以下 Kata Containers Storages对应容器镜像 layer 0对应容器镜像 layer 1对应容器镜像的 overlay对应下方 YAML 示例中的data卷对应下方 YAML 示例中的data2卷。apiVersion: v1 kind: Pod metadata: name: persistent spec: ... containers: ... volumeMounts: - mountPath: /busy1 name: data - mountPath: /busy2 name: data2 volumes: - name: data emptyDir: {} - name: data2 emptyDir: medium: Memorygenpolicy 自动生成策略的 overlay 层存储数据结构它提供校验每个容器镜像完整性所需的部分信息有序的 layer ID 集合每个 layer ID 对应的dm-verityroot hash 值。每个容器镜像层由 Kata Shim 以dm-verity保护的块存储设备暴露给 Guest VM。如果CreateContainer输入的 layer ID 与dm-verityroot hash 与策略一致Kata Agent 使用这些 ID 与 root hash 挂载容器镜像层存储设备Guest 内核通过检查每层的dm-verity信息保证容器镜像的完整性。ExecProcessRequest除非满足以下任一条件自动生成的策略拒绝ExecProcess请求请求对应 K8slivenessProbe、readinessProbe或startupProbe的exec探针或请求对应策略中的policy_data.request_defaults.ExecProcessRequest数据。exec 探针给定以下 genpolicy 输入 YAMLapiVersion: v1 kind: Pod metadata: name: exec-test spec: containers: ... - command: - /bin/sh env: - name: POD_IP valueFrom: fieldRef: apiVersion: v1 fieldPath: status.podIP readinessProbe: exec: command: - echo - Ready ${POD_IP}! failureThreshold: 1 periodSeconds: 5 timeoutSeconds: 10工具生成以下ExecProcessRequest策略数据policy_data : { containers: [ ... { OCI: { ... }, storages: [ ... ], exec_commands: [ echo Ready ${POD_IP}!, ] } ] }policy_data.request_defaults.ExecProcessRequest若ExecProcess请求的命令行与policy_data.request_defaults.ExecProcessRequest数据结构中commands和/或regex字段的至少一条条目匹配则该请求被允许。commands与regex条目由 genpolicy 从 genpolicy-settings.json 复制。默认情况下两者均为空集合因此不允许任何ExecProcess请求。想允许某些ExecProcess请求的用户可以给 genpolicy 传入修改过的genpolicy-settings.json副本。警告commands更易用但需要指定被允许的完整命令行regex条目更灵活单条即可匹配多条命令行但对非正则表达式专家更容易误用。policy_data.request_defaults.ExecProcessRequest.commands条目示例policy_data : { ... request_defaults: { ... ExecProcessRequest: { commands: [ /bin/bash, /bin/myapp -p1 -p2 ], regex: [] }, ... } }policy_data.request_defaults.ExecProcessRequest.regex条目示例policy_data : { ... request_defaults: { ... ExecProcessRequest: { commands: [], regex: [ ^/bin/sh -x -c echo hostName \\| nc -v -t -w 2 externalname-service [0-9]$, ^/bin/sh -x -c echo hostName \\| nc -v -t -w 2 [0-9]\\.[0-9]\\.[0-9]\\.[0-9] [0-9]$ ] }, ... } }ReadStreamRequest默认自动生成的策略拒绝ReadStream请求。用户可以通过修改 genpolicy-settings.json 允许 Kata Containers Shim 读取 Guest VM 容器的stdout/stderr流例如policy_data : { ... request_defaults: { ... ReadStreamRequest: true, ... } }WriteStreamRequest默认情况下自动生成的策略拒绝WriteStream请求。用户可以通过修改 genpolicy-settings.json 允许 Kata Containers Shim 向 Guest VM 容器的stdin发送输入例如policy_data : { ... request_defaults: { ... WriteStreamRequest: true, ... } }默认设置文件 genpolicy-settings.json 结构genpolicy-settings.json 是 genpolicy 的核心设置文件主要包含以下部分pause_containerK8s pausesandbox容器的 OCI 模板包括Root.Path/Readonly、Mounts如/dev/shm、/etc/resolv.conf、Annotationssandbox 类型注解及其正则、Process/pause、NoNewPrivileges与Linux的Sysctl、MaskedPaths、ReadonlyPathsother_container普通业务容器的 OCI 模板包括/etc/hosts、/dev/termination-log、/etc/hostname、/etc/resolv.conf、serviceaccount 与 Azure tokens 等挂载点以及容器类型注解volumes各类卷的策略数据模板包括emptyDir、emptyDir_encrypted、emptyDir_plain、emptyDir_memory、configMap、image_volume的 driver/fstype/mount_point 等例如emptyDir_encrypted使用encryption_keyephemeral与create_filesystememptyDir_memory挂载在/run/kata-containers/sandbox/ephemeral/devices设备相关配置例如vfio的设备路径/dev/vfio/devices/vfio、注解键正则^cdi\.k8s\.io/vfio[0-9]$与 NVIDIA GPU 的gpu_anno_value_regex、gpu_gk_device_type、pgpu_resource_keysmount_destinations允许的挂载目标列表sandboxsandbox 级存储例如 shm 的 tmpfs 存储含noexec、nosuid、nodev、mode1777、size67108864选项common公共正则与能力列表包括cpath、spath、root_path、sfprefix、IPv4 正则、default_caps14 项默认能力与privileged_caps44 项特权能力、image_layer_verification默认nonekata_config如oci_version默认1.1.0与enable_configmap_secret_storages默认falsecluster_config如pause_container_image默认mcr.microsoft.com/oss/kubernetes/pause:3.6、guest_pull默认true、emptydir_type默认block-encrypted、cgroup_mount_extras_allowednsdelegate、memory_recursiveprotrequest_defaults各类请求的默认数据包括CreateContainerRequest.allow_env_regex一组环境变量正则如HOSTNAME、K8s Service 环境变量、JOB_COMPLETION_INDEX、AZURE_*、TERMxterm等、UpdateInterfaceRequest、CopyFileRequest、ExecProcessRequest、UpdateRoutesRequest、AddARPNeighborsRequest以及CloseStdinRequest、GetDiagnosticDataRequest、ReadStreamRequest、UpdateEphemeralMountsRequest、WriteStreamRequest等布尔开关默认均为false。这些设置共同决定了自动生成策略的松紧程度是进行策略定制的主要切入点。与 Kata Agent 策略体系的整体衔接genpolicy 生成的策略最终通过 YAML 注解交付给 Kata Agent。在 如何配置 Kata Agent 策略 中可以看到用户也可以把策略文档以 base64 编码后添加到io.katacontainers.config.hypervisor.cc_init_data注解中示例输入 samples/pod-one-container.yaml 就包含这一注解。创建 Pod sandbox 时Kata Shim 会注意到该注解在 Host 上创建 init data 设备并作为块设备挂载到 GuestAgent 从该设备读取 init data 结构若其中包含策略则设置之。genpolicy 正是这条自动化链路的策略生成端与手动编写 Rego 策略相比它可以快速从 Kubernetes 声明式输入推导出覆盖镜像完整性、卷、探针、环境变量等关键维度的策略数据。总结genpolicy 把从 Kubernetes YAML 推断信任边界这一复杂的机密容器问题转化为一条可重复、可验证的自动化流水线输入 YAML → 下载镜像计算完整性信息 → 生成 Rego 策略 → base64 注解回写。本文覆盖了其构建方式、全部命令行参数-y、-j、-p、-c/--config-file、-s、-u、-r、-b、-d等、设置目录与 RFC 6902 drop-in 机制、默认值/规则/数据的策略结构以及CopyFileRequest、CreateContainerRequest、ExecProcessRequest、ReadStreamRequest、WriteStreamRequest等核心规则的细节。建议在生产环境中使用前仔细审查自动生成的策略、谨慎启用镜像层缓存、避免随意使用-s忽略字段并通过自定义genpolicy-settings.json与 drop-in 将策略调整到与实际集群OCI 版本、运行时、平台匹配的粒度。进一步可阅读 genpolicy 高级命令行参数、自动生成策略细节、drop-in 示例 以及完整规则文件 rules.rego。赞分享云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载相关推荐Kata Containers genpolicy 自动生成 Agent Policy 详解结构与校验规则深度剖析Kata Containers genpolicy 自动生成 Agent Policy 详解结构与校验规则深度剖析 Kata Agent Policy 是 K云原生容器运行时dotnet/runtime 如何在 macOS 或 Linux 上构建 Android 版 CoreCLR 并在模拟器运行示例dotnet/runtime 如何在 macOS 或 Linux 上构建 Android 版 CoreCLR 并在模拟器运行示例 如果你在 dotnet/ru云原生容器运行时MongoDB 查询优化$unwind $group 到 DISTINCT_SCAN 改写与多计划竞争Multiplanning实战解析MongoDB 查询优化$unwind $group 到 DISTINCT_SCAN 改写与多计划竞争Multiplanning实战解析 导读 本文以云原生容器运行时上一篇Wazuh Engine 开发工具集实战指南从 API 通信到内存泄漏检测下一篇用 iii-browser-sdk 把浏览器变成一等 WorkerRBAC 网关接入、实时点击流与服务器反向调用实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考