# Kubernetes 容器编排平台测评

> Kubernetes v1.28~v1.33 容器编排平台三级等保现场测评取证命令单：按 GB/T 22239-2019 安全计算环境控制点组织 kubectl version、get nodes、anonymous-auth、RBAC、audit-policy-file、kubelet 10250/10255、etcd 证书认证与静态加密、etcd 快照与 Velero 备份等只读取证命令，覆盖身份鉴别、访问控制、安全审计、入侵防范、数据完整性与保密性、备份恢复等控制点，附判定要点、高风险提示、示例输出与版本差异核验说明。

---

LLMS index: [llms.txt](/wikis/llms.txt)

---

> 定位：Kubernetes 容器编排平台三级等保现场测评**取证命令单**，按 GB/T 22239-2019 安全计算环境控制点分节组织核查命令、判定要点与取证要求。
> 适用范围：Kubernetes v1.28~v1.33（kubeadm 部署与二进制部署均适用；托管集群/其他发行版组件配置位置不同，须先确认部署形态再套用取证路径）。
> 配套文章：[22、高风险判定指引与加固对照表](../../../reinforce/其他系统或设备/22高风险判定指引与加固对照表/)、[16、安全评估加固记录表3.0](../../../reinforce/其他系统或设备/16安全评估加固记录表3.0/)、[17、网络设备、安全设备、服务器、数据库和应用系统的加固方案](../../../reinforce/其他系统或设备/17网络设备安全设备服务器数据库和应用系统的加固方案/)。
>
> 使用说明：
>
> - 本文所有命令均为**只读取证**命令，不修改配置、不重启服务、不执行删除/驱逐/回滚类操作；确需变更由被测单位运维方在授权下实施。
> - 每个控制点小节按「对应控制点 → 判定要点 → 取证要求 → 核查命令 → 备注 → 预期证据」编排；命令回显本身即证据，须连同命令行一起截图。
> - 控制面组件（kube-apiserver、etcd、scheduler、controller-manager）在 kubeadm 部署下以静态 Pod 方式运行，清单位于控制面节点的 `/etc/kubernetes/manifests/`，既可经 API 读取 `-n kube-system` 的同名 Pod 取证，也可直接查看清单文件；二进制部署则以 systemd unit 与配置文件取证。
> - 命令不存在或输出与示例差异较大时，先确认集群版本与部署形态（kubeadm/二进制/托管/发行版），再换用等效命令或转入配置文件、管理控制台取证，**不得据命令缺失直接判不符合**。
> - 示例输出中的地址、账户、路径、令牌均为演示值，现场须替换为真实取证结果并对涉及个人信息、凭据与内网管理地址的内容脱敏后再入报告。
>
> 不适用标识说明：
>
> - 使用 `【不适用】` 明确标记现场可判定为不适用的控制点。
> - 判定依据采用 GB/T 28448-2019"按测评对象实际功能、是否直接处理数据、是否具备该类安全机制判定"的原则；Kubernetes 为容器编排平台，业务应用的身份鉴别、数据加密等责任多由容器内应用与上层平台承担，需按边界拆分判定。

## 基础信息

> **对应控制点**：非独立控制点（测评对象与资产确认）；部署形态与冗余情况佐证 8.1.2.1 网络架构 e) 关键设备硬件冗余
>
> **判定要点**：集群版本、节点清单与角色、控制面组件运行状态、部署形态（kubeadm/二进制）四项均可取证且与实际架构一致 → 符合；版本或节点清单无法确认、依赖口头说明 → 部分符合。
>
> **取证要求**：版本命令回显截图、节点清单截图、集群信息截图、全命名空间 Pod 清单截图、控制面组件健康状态截图。

**核查命令**：

```bash
kubectl version
kubectl get nodes -o wide
kubectl cluster-info
kubectl get pods -A
kubectl get --raw='/readyz?verbose'
kubectl get componentstatuses
```

- 备注：`kubectl version` 默认输出 Client/Kustomize/Server 三段版本信息，**v1.24~v1.27 需加 `--short`（输出警告：已废弃），v1.28 起 `--short` 标志整体移除且默认输出即为原 `--short` 形态**，不要在现场用错标志。`kubectl get componentstatuses`（`kubectl get cs`）自 v1.19+ 已废弃且数据不可靠，官方替代为健康检查端点 `kubectl get --raw='/readyz?verbose'`（`/healthz` 自 v1.16 起废弃，改用 `/livez`、`/readyz`）。`kubectl get pods -A` 应能看到 `kube-apiserver-<节点名>`、`etcd-<节点名>` 等静态 Pod，从而确认控制面部署形态与节点冗余。
- 预期证据：版本截图（Client/Server 一致或偏差在版本偏差政策允许范围）、节点清单截图（ROLES/VERSION/INTERNAL-IP）、`cluster-info` 截图、Pod 清单截图、`readyz?verbose` 检查项全 ok 截图。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl version
</span></span><span class="line"><span class="cl">Client Version: v1.30.4
</span></span><span class="line"><span class="cl">Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
</span></span><span class="line"><span class="cl">Server Version: v1.30.4
</span></span><span class="line"><span class="cl">kubectl get nodes -o wide
</span></span><span class="line"><span class="cl">NAME          STATUS   ROLES           AGE   VERSION   INTERNAL-IP     OS-IMAGE            CONTAINER-RUNTIME
</span></span><span class="line"><span class="cl">demo-node1    Ready    control-plane   40d   v1.30.4   192.168.10.5    Ubuntu 22.04.4 LTS  containerd://1.7.19
</span></span><span class="line"><span class="cl">demo-node2    Ready    worker          40d   v1.30.4   192.168.10.6    Ubuntu 22.04.4 LTS  containerd://1.7.19
</span></span><span class="line"><span class="cl">demo-node3    Ready    worker          40d   v1.30.4   192.168.10.7    Ubuntu 22.04.4 LTS  containerd://1.7.19
</span></span><span class="line"><span class="cl">kubectl cluster-info
</span></span><span class="line"><span class="cl">Kubernetes control plane is running at https://192.168.10.5:6443
</span></span><span class="line"><span class="cl">CoreDNS is running at https://192.168.10.5:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
</span></span><span class="line"><span class="cl">kubectl get --raw<span class="o">=</span><span class="s1">&#39;/readyz?verbose&#39;</span>
</span></span><span class="line"><span class="cl"><span class="o">[</span>+<span class="o">]</span>ping ok
</span></span><span class="line"><span class="cl"><span class="o">[</span>+<span class="o">]</span>log ok
</span></span><span class="line"><span class="cl"><span class="o">[</span>+<span class="o">]</span>etcd ok
</span></span><span class="line"><span class="cl"><span class="o">[</span>+<span class="o">]</span>poststarthook/start-apiserver-admission-initializer ok
</span></span><span class="line"><span class="cl">healthz check passed
</span></span><span class="line"><span class="cl">（另：kubectl get cs 回显 <span class="s2">&#34;Warning: v1 ComponentStatus is deprecated in v1.19+&#34;</span>，仅作对照留存）
</span></span></code></pre></div>
</details>


## 身份鉴别

> **对应控制点**：GB/T 22239-2019 8.1.4.1 身份鉴别 a)~d)
>
> **判定要点**：API Server 关闭匿名访问（`--anonymous-auth=false`）或匿名仅能访问非敏感公开信息、接入 X.509 客户端证书/Token/OIDC 等鉴别机制且凭据签发受控、ServiceAccount 凭据按需最小化挂载、管理通道走加密 HTTPS → 符合；鉴别机制存在但凭据管理松散（长期静态 token、kubeconfig 散落未管控）→ 部分符合；匿名访问开放且被绑定到特权角色、或 6443 跨安全域可达无任何鉴别补偿 → 不符合（高风险）。
>
> **取证要求**：API Server 启动参数或静态 Pod 清单截图、匿名访问实测回显截图、OIDC/统一认证对接配置截图、ServiceAccount 挂载抽样截图、kubeconfig 文件权限截图。

<div class="alert alert-warning" role="alert"><div class="h4 alert-heading" role="heading">高风险提示</div>


`system:anonymous`/`system:unauthenticated` 被绑定到 `cluster-admin` 或其他特权 ClusterRole（RBAC 绑定清单可见），等同于向无凭据访问者开放集群管理入口，按《高风险判定指引》中"未授权访问"同类口径判高风险；默认绑定仅 `system:public-info-viewer`（只读非敏感公开信息）。kubelet 10250 匿名可读写的高风险口径见入侵防范节。

判定口径详见 [22、高风险判定指引与加固对照表](../../../reinforce/其他系统或设备/22高风险判定指引与加固对照表/)。
</div>


### A. API Server 匿名访问与鉴别机制

**核查命令**：

```bash
grep -n -E "anonymous-auth|authentication-config" /etc/kubernetes/manifests/kube-apiserver.yaml 2>/dev/null
kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml | grep -E "anonymous-auth|authentication-config"
curl -sk https://192.168.10.5:6443/version | head -c 300
kubectl auth can-i --list --as=system:anonymous
```

- 备注：kube-apiserver 参考页标注 `--anonymous-auth` 默认 `true`（匿名请求用户名 `system:anonymous`、组 `system:unauthenticated`），kubeadm 默认配置**未显式关闭**匿名访问，现场须逐项记录实际参数。匿名开启时，无凭据 `curl` 可获取 `/version` 等非敏感公开信息（默认绑定 `system:public-info-viewer`），再以 `kubectl auth can-i --list --as=system:anonymous` 实测匿名真实权限；关闭时回显 401 Unauthorized，属阴性证据。较新版本支持以 `--authentication-config` 指定 AuthenticationConfiguration 配置文件（与该文件配置匿名验证器时 `--anonymous-auth` 互斥），两种配置路径的证据都须留存。
- 预期证据：启动参数/静态 Pod 清单截图、无凭据访问实测回显截图（含 401 或版本 JSON 两种情形）、匿名权限清单截图。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml <span class="p">|</span> grep anonymous-auth
</span></span><span class="line"><span class="cl">    - --anonymous-auth<span class="o">=</span><span class="nb">false</span>
</span></span><span class="line"><span class="cl">curl -sk https://192.168.10.5:6443/version <span class="p">|</span> head -c <span class="m">300</span>
</span></span><span class="line"><span class="cl"><span class="o">{</span><span class="s2">&#34;kind&#34;</span>:<span class="s2">&#34;Status&#34;</span>,<span class="s2">&#34;apiVersion&#34;</span>:<span class="s2">&#34;v1&#34;</span>,<span class="s2">&#34;metadata&#34;</span>:<span class="o">{}</span>,<span class="s2">&#34;status&#34;</span>:<span class="s2">&#34;Failure&#34;</span>,<span class="s2">&#34;message&#34;</span>:<span class="s2">&#34;Unauthorized&#34;</span>,<span class="s2">&#34;reason&#34;</span>:<span class="s2">&#34;Unauthorized&#34;</span>,<span class="s2">&#34;code&#34;</span>:401<span class="o">}</span>
</span></span><span class="line"><span class="cl">（匿名访问已关闭：无凭据请求回显 401，属预期阴性证据）
</span></span><span class="line"><span class="cl">kubectl auth can-i --list --as<span class="o">=</span>system:anonymous（另一现场开启匿名时的抽样，节选）
</span></span><span class="line"><span class="cl">Resources                                       Non-Resource URLs   Resource Names   Verbs
</span></span><span class="line"><span class="cl">                                                <span class="o">[</span>/version<span class="o">]</span>          <span class="o">[]</span>               <span class="o">[</span>get<span class="o">]</span>
</span></span><span class="line"><span class="cl">                                                <span class="o">[</span>/healthz...<span class="o">]</span>       <span class="o">[]</span>               <span class="o">[</span>get<span class="o">]</span>
</span></span><span class="line"><span class="cl">（匿名仅命中 system:public-info-viewer 的公开只读端点，未见资源类权限）
</span></span></code></pre></div>
</details>


### B. 统一身份源与联合认证（OIDC/LDAP）

**核查命令**：

```bash
kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml | grep -E "oidc-"
grep -n "oidc-" /etc/kubernetes/manifests/kube-apiserver.yaml 2>/dev/null
kubectl auth whoami 2>/dev/null
```

- 备注：官方认证文档列明的 OIDC 参数为 `--oidc-issuer-url`、`--oidc-client-id`、`--oidc-username-claim`、`--oidc-groups-claim` 及 `--oidc-ca-file`、`--oidc-required-claim`、`--oidc-username-prefix` 等，签发方仅接受 HTTPS；未对接 OIDC 时鉴别通常由客户端证书（`--client-ca-file`，证书 CN 即用户名、O 即用户组）与 ServiceAccount Token 承载，可补统一认证平台/堡垒机的对接截图。LDAP 一般经 OIDC 桥接或 webhook token 认证接入，须由平台侧提供对接材料。`kubectl auth whoami`（较新版本 kubectl 支持）用于确认当前凭据映射到的用户与组，不支持时改用带凭据请求的认证结果取证。
- 预期证据：OIDC 参数截图、统一认证平台对接材料、用户名与组映射说明、访谈记录。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml <span class="p">|</span> grep <span class="s2">&#34;oidc-&#34;</span>
</span></span><span class="line"><span class="cl">    - --oidc-issuer-url<span class="o">=</span>https://sso.demo.local/realms/demo
</span></span><span class="line"><span class="cl">    - --oidc-client-id<span class="o">=</span>kubernetes
</span></span><span class="line"><span class="cl">    - --oidc-username-claim<span class="o">=</span>email
</span></span><span class="line"><span class="cl">    - --oidc-groups-claim<span class="o">=</span>groups
</span></span><span class="line"><span class="cl">    - --oidc-ca-file<span class="o">=</span>/etc/kubernetes/pki/sso-ca.crt
</span></span><span class="line"><span class="cl">（人员用户经单位统一认证平台 SSO 签发 JWT 接入，证书 CN 账户仅保留给节点与系统组件）
</span></span></code></pre></div>
</details>


### C. ServiceAccount 与 Pod 凭据挂载

**核查命令**：

```bash
kubectl get serviceaccounts -A
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.spec.automountServiceAccountToken}{"\n"}{end}' | sort | uniq -c | sort -rn | head -n 15
kubectl -n demo-namespace get serviceaccount default -o yaml
kubectl -n demo-namespace get pod demo-app-7f9c6b5d4-x2v8p -o jsonpath='{.spec.containers[*].volumeMounts[*].mountPath}{"\n"}'
```

- 备注：Pod 级/SA 级 `automountServiceAccountToken: false` 可关闭凭据自动挂载（官方服务账户文档原文），业务 Pod 不调用 API 时应关闭，`jsonpath` 输出为空即未显式设置（按默认挂载处理，须记录）。凭据形态按版本核查：**v1.24 起 ServiceAccount 不再自动生成长期 legacy token Secret**，v1.22+ 默认经 TokenRequest API 签发短生命周期令牌并以 projected volume 挂载（自动轮转）；仍存在长期 token Secret 或手工 kubeconfig 的，逐一登记并核验用途与权限（见剩余信息保护）。
- 【不适用】Kubernetes 平台本体无内置本地口令账户体系（kubeadm 部署无用户口令），"口令复杂度/登录失败锁定/会话超时"对平台本体可判定为部分不适用，鉴别控制转由客户端证书签发管理、OIDC/统一认证平台与堡垒机承载。依据：GB/T 28448-2019 身份鉴别控制点应与对象实际鉴别方式相匹配。
- 预期证据：ServiceAccount 清单截图、挂载抽样截图、默认 SA 配置截图、TokenRequest/旧 token 存量说明。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl get pods -A -o <span class="nv">jsonpath</span><span class="o">=</span>...（节选）
</span></span><span class="line"><span class="cl">  <span class="m">212</span>  &lt;空&gt;/自动挂载
</span></span><span class="line"><span class="cl">   <span class="m">38</span>  <span class="nb">false</span>
</span></span><span class="line"><span class="cl">   <span class="m">12</span>  <span class="nb">true</span>
</span></span><span class="line"><span class="cl">kubectl -n demo-namespace get pod demo-app-7f9c6b5d4-x2v8p -o <span class="nv">jsonpath</span><span class="o">=</span>...
</span></span><span class="line"><span class="cl">/var/run/secrets/kubernetes.io/serviceaccount
</span></span><span class="line"><span class="cl">（业务命名空间 <span class="m">38</span> 个 Pod 已显式关闭自动挂载；kube-system 系统 Pod 属正常挂载）
</span></span></code></pre></div>
</details>


### D. kubeconfig 与组件证书形态

**核查命令**：

```bash
ls -l ~/.kube/config /etc/kubernetes/admin.conf 2>/dev/null
kubectl config view | grep -E "client-certificate|token|server" | head -n 10
ls -l /var/lib/kubelet/pki 2>/dev/null
grep -n -E "rotateCertificates" /var/lib/kubelet/config.yaml 2>/dev/null
```

- 备注：kubeconfig 凭据形态分 `client-certificate(-data)` 与 `token` 两类，`kubectl config view` 默认对证书/凭据数据脱敏显示，适合取证不泄露凭据；`admin.conf`、`/var/lib/kubelet/pki` 下证书与私钥文件权限应为 600 且仅 root 可读。kubelet 客户端证书轮换由 KubeletConfiguration 的 `rotateCertificates` 控制（配置参考页标注默认 `false`，须核对现场实际取值——kubeadm 启用引导后由 CSR 审批流程支撑），证书有效期与轮换记录可佐证"鉴别信息及时更换"。
- 预期证据：kubeconfig 权限截图、脱敏后的凭据形态截图、kubelet pki 目录截图、证书轮换配置截图。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">ls -l /etc/kubernetes/admin.conf
</span></span><span class="line"><span class="cl">-rw------- <span class="m">1</span> root root <span class="m">5652</span> Aug <span class="m">24</span> 09:12 /etc/kubernetes/admin.conf
</span></span><span class="line"><span class="cl">kubectl config view（节选）
</span></span><span class="line"><span class="cl">- name: kubernetes-admin
</span></span><span class="line"><span class="cl">  user:
</span></span><span class="line"><span class="cl">    client-certificate-data: DATA+OMITTED
</span></span><span class="line"><span class="cl">    client-key-data: DATA+OMITTED
</span></span><span class="line"><span class="cl">ls -l /var/lib/kubelet/pki
</span></span><span class="line"><span class="cl">-rw------- <span class="m">1</span> root root <span class="m">1289</span> kubelet-client-current.pem
</span></span><span class="line"><span class="cl">-rw-r--r-- <span class="m">1</span> root root <span class="m">1237</span> kubelet.crt
</span></span><span class="line"><span class="cl">（kubeconfig 权限 600，凭据在取证输出中自动脱敏）
</span></span></code></pre></div>
</details>


## 访问控制

> **对应控制点**：GB/T 22239-2019 8.1.4.2 访问控制 a)~f)
>
> **判定要点**：启用 RBAC 授权（`--authorization-mode` 含 RBAC）、账户/角色与权限最小化、`cluster-admin` 绑定受控、匿名与未认证主体无特权绑定、启用 Pod Security Admission 等准入控制收敛工作负载权限、特权 Pod（hostPID/hostNetwork/hostPath/privileged）有业务理由且可追溯 → 符合；有 RBAC 但存在宽泛授权或特权 Pod 无说明 → 部分符合；`cluster-admin` 授权给普通用户/业务账户、匿名特权绑定、管理端口对全网开放 → 不符合（高风险）。
>
> **取证要求**：ClusterRoleBinding/RoleBinding 清单截图、`cluster-admin` 绑定主体截图、匿名绑定核查截图、准入插件与命名空间 PSA 标签截图、特权 Pod 抽样截图与业务说明。

<div class="alert alert-warning" role="alert"><div class="h4 alert-heading" role="heading">高风险提示</div>


`cluster-admin`（官方定义"允许对任意资源执行任意操作的超管角色"）授权给普通用户或业务 ServiceAccount、`system:anonymous`/`system:unauthenticated` 出现在特权角色绑定中、业务 Pod 大量以 `privileged: true` 运行且无说明，均按《高风险判定指引》中"未授权访问/越权"同类口径判高风险；默认仅 `system:public-info-viewer` 绑定至未认证组。

判定口径详见 [22、高风险判定指引与加固对照表](../../../reinforce/其他系统或设备/22高风险判定指引与加固对照表/)。
</div>


### A. RBAC 绑定审计

**核查命令**：

```bash
kubectl get clusterrolebindings -o wide
kubectl get rolebindings -A -o wide
kubectl get clusterrolebinding cluster-admin -o jsonpath='{range .subjects[*]}{.kind}{"\t"}{.name}{"\t"}{.namespace}{"\n"}{end}'
kubectl get clusterrolebindings -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.subjects[*].name}{"\n"}{end}' | grep -E "system:anonymous|system:unauthenticated"
kubectl get rolebindings -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.subjects[*].name}{"\n"}{end}' | grep -E "system:anonymous|system:unauthenticated"
kubectl auth can-i --list --as=system:anonymous
```

- 备注：重点核对三类绑定：① `cluster-admin` 的主体清单（官方 RBAC 文档原文：ClusterRoleBinding 方式授予"集群与所有命名空间内所有资源的完全控制"），逐个登记是否为节点/系统组件必需；② `system:anonymous`、`system:unauthenticated` 的全部绑定；③ 默认 ClusterRole 是否被修改（`kubectl get clusterroles -o yaml` 抽样比对，被改动的默认角色会放大既有绑定权限）。grep 无输出属阴性证据，须截图留存。授权管理应配合堡垒机与变更工单佐证"按最小权限分配并留痕"。
- 预期证据：两类绑定清单全量截图、`cluster-admin` 主体截图、匿名/未认证绑定核查截图（含无输出阴性证据）、宽泛授权整改记录。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl get clusterrolebinding cluster-admin -o <span class="nv">jsonpath</span><span class="o">=</span>...
</span></span><span class="line"><span class="cl">Group    system:masters
</span></span><span class="line"><span class="cl">（cluster-admin 仅绑定 system:masters 组，人员账户不直接持有）
</span></span><span class="line"><span class="cl">kubectl get clusterrolebindings -o <span class="nv">jsonpath</span><span class="o">=</span>... <span class="p">|</span> grep -E <span class="s2">&#34;system:anonymous|system:unauthenticated&#34;</span>
</span></span><span class="line"><span class="cl">（无输出：匿名与未认证主体未绑定任何 ClusterRole）
</span></span><span class="line"><span class="cl">kubectl get clusterrolebindings -o wide（节选）
</span></span><span class="line"><span class="cl">NAME                        ROLE                  AGE   USERS   GROUPS                     SERVICEACCOUNTS
</span></span><span class="line"><span class="cl">system:public-info-viewer   ClusterRole/...       40d           <span class="o">[</span>system:authenticated system:unauthenticated<span class="o">]</span>
</span></span><span class="line"><span class="cl">（默认绑定与官方文档一致：未认证组仅可读非敏感公开信息）
</span></span></code></pre></div>
</details>


### B. 准入控制与 Pod 安全标准

**核查命令**：

```bash
kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml | grep -E "enable-admission-plugins|disable-admission-plugins"
kubectl get namespaces --show-labels
kubectl get namespace demo-namespace --show-labels
```

- 备注：`PodSecurity` 属 kube-apiserver 默认启用的准入插件（参考页默认插件清单原文），Pod Security Admission 自 v1.25 起稳定（GA）；策略按命名空间标签 `pod-security.kubernetes.io/<mode>: <level>` 生效，mode 为 enforce/audit/warn，level 为 privileged/baseline/restricted，默认 level 为 privileged（即不限制），**必须在命名空间显式打标签才实际收敛**，现场逐个记录业务命名空间标签取值。kubeadm 部署的 kubelet 受 `NodeRestriction` 准入插件限制（只允许修改自身节点相关资源），核查其出现在启动参数或默认清单中。
- 预期证据：准入插件参数截图、命名空间标签截图（含未打标命名空间的整改说明）、PSA 策略与 Pod 安全标准对照说明。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl get namespace demo-namespace --show-labels
</span></span><span class="line"><span class="cl">demo-namespace   Active   12d   kubernetes.io/metadata.name<span class="o">=</span>demo-namespace,pod-security.kubernetes.io/enforce<span class="o">=</span>baseline,pod-security.kubernetes.io/warn<span class="o">=</span>restricted
</span></span><span class="line"><span class="cl">（业务命名空间 <span class="nv">enforce</span><span class="o">=</span>baseline、warn<span class="o">=</span>restricted；对照：默认 privileged 级别不产生任何限制）
</span></span><span class="line"><span class="cl">kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml <span class="p">|</span> grep admission
</span></span><span class="line"><span class="cl">    - --enable-admission-plugins<span class="o">=</span>NodeRestriction,AlwaysPullImages
</span></span><span class="line"><span class="cl">（默认插件已含 PodSecurity，此处为额外启用的插件）
</span></span></code></pre></div>
</details>


### C. 特权 Pod 与敏感挂载核查

**核查命令**：

```bash
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.spec.hostNetwork}{"\t"}{.spec.hostPID}{"\t"}{.spec.hostIPC}{"\n"}{end}' | sort
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.spec.containers[*].securityContext.privileged}{"\n"}{end}'
kubectl get pods -A -o jsonpath='{range .items[*]}{range .spec.volumes[*]}{.hostPath.path}{"\n"}{end}{end}' | sort -u | grep -v "^$"
```

- 备注：第一条命令逐 Pod 列出 hostNetwork/hostPID/hostIPC（输出为空即未设置，默认 false），第二条列出各容器 `privileged` 取值序列（出现 true 的 Pod 逐一深查），第三条汇总全集群 hostPath 挂载路径（重点：`/`、`/etc`、`/var/run/docker.sock`、`/var/run/containerd/containerd.sock`、`/root`）。kube-system 内 CNI、kube-proxy 等系统组件使用特权属常见形态，须区分"系统必需"与"业务滥用"；业务命名空间出现特权容器即要求业务方提供书面理由并对照 PSA 基线。
- 预期证据：三段 jsonpath 输出截图、特权 Pod 清单与业务说明、hostPath 挂载清单截图、整改记录。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl get pods -A -o <span class="nv">jsonpath</span><span class="o">=</span>...（hostNetwork/hostPID/hostIPC，节选）
</span></span><span class="line"><span class="cl">kube-system/kube-proxy                          <span class="nb">true</span>   <span class="nb">false</span>  <span class="nb">false</span>
</span></span><span class="line"><span class="cl">kube-system/calico-node                         <span class="nb">true</span>   <span class="nb">true</span>   <span class="nb">false</span>
</span></span><span class="line"><span class="cl">demo-namespace/demo-app-7f9c6b5d4-x2v8p         <span class="nb">false</span>  <span class="nb">false</span>  <span class="nb">false</span>
</span></span><span class="line"><span class="cl">kubectl get pods -A -o <span class="nv">jsonpath</span><span class="o">=</span>...（privileged，节选）
</span></span><span class="line"><span class="cl">kube-system/calico-node        <span class="nb">true</span>
</span></span><span class="line"><span class="cl">demo-namespace/demo-web-67c9   <span class="nb">false</span>
</span></span><span class="line"><span class="cl">（特权容器仅集中在 kube-system 网络组件，业务命名空间未见 hostPID/hostNetwork/privileged）
</span></span></code></pre></div>
</details>


## 安全审计

> **对应控制点**：GB/T 22239-2019 8.1.4.3 安全审计 a)~d)
>
> **判定要点**：kube-apiserver 配置 `--audit-policy-file` 与 `--audit-log-*` 日志后端、审计策略覆盖用户与关键读写操作（级别 None/Metadata/Request/RequestResponse 组合合理）、日志本地轮转并外送集中平台、留存不少于 6 个月、普通运维账户无法删改审计记录 → 符合；已启用但覆盖不全或留存不足 6 个月 → 部分符合；完全未启用 API 审计且无主机/网络侧补偿、操作无法追溯 → 不符合（高风险）。
>
> **取证要求**：审计策略文件内容截图、审计日志后端参数截图、审计事件样例截图（含时间/用户/动词/资源/结果/来源 IP）、日志平台外送与 6 个月留存证据、节点侧日志截图。

<div class="alert alert-warning" role="alert"><div class="h4 alert-heading" role="heading">高风险提示</div>


未配置 `--audit-policy-file`（官方文档原文：省略该参数则不记录任何审计事件）且无主机/网络侧审计补偿，API Server 上的创建、删除、提权等管理操作完全无法追溯，按《高风险判定指引》审计类口径判高风险；`--audit-log-maxage` 小于 180 天且未外送集中平台，留存不满足 6 个月要求，一并记录。

判定口径详见 [22、高风险判定指引与加固对照表](../../../reinforce/其他系统或设备/22高风险判定指引与加固对照表/)。
</div>


### A. 审计策略与日志后端配置

**核查命令**：

```bash
kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml | grep -E "audit-policy-file|audit-log-path|audit-log-maxage|audit-log-maxbackup|audit-log-maxsize"
grep -n -E "apiVersion|kind: Policy|level|omitStages|rules" /etc/kubernetes/audit-policy.yaml 2>/dev/null | head -n 20
ls -l /etc/kubernetes/audit-policy.yaml 2>/dev/null
```

- 备注：审计策略文件为 `apiVersion: audit.k8s.io/v1`、`kind: Policy` 结构，规则按顺序首条匹配生效，级别四档：`None`（不记录）、`Metadata`（仅元数据：用户/时间/资源/动词等，不含请求与响应体）、`Request`（元数据+请求体）、`RequestResponse`（元数据+请求体+响应体）；策略文件必须包含 rules，可用 `omitStages: ["RequestReceived"]` 精简记录阶段。日志后端参数缺一不可：未设 `--audit-log-path` 则日志后端整体停用。现行参考页标注默认值 `--audit-log-maxage: 366`、`--audit-log-maxbackup: 100`、`--audit-log-maxsize: 100`（MB 轮转），不同小版本默认值可能不同，**须以现场实际参数为准**，且满足"不少于 6 个月"应取 maxage≥180。
- 预期证据：API Server 审计参数截图、策略文件全文截图、参数与策略一致性说明。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml <span class="p">|</span> grep audit
</span></span><span class="line"><span class="cl">    - --audit-policy-file<span class="o">=</span>/etc/kubernetes/audit-policy.yaml
</span></span><span class="line"><span class="cl">    - --audit-log-path<span class="o">=</span>/var/log/kubernetes/audit/audit.log
</span></span><span class="line"><span class="cl">    - --audit-log-maxage<span class="o">=</span><span class="m">180</span>
</span></span><span class="line"><span class="cl">    - --audit-log-maxbackup<span class="o">=</span><span class="m">10</span>
</span></span><span class="line"><span class="cl">    - --audit-log-maxsize<span class="o">=</span><span class="m">100</span>
</span></span><span class="line"><span class="cl">grep -E <span class="s2">&#34;apiVersion|kind|level&#34;</span> /etc/kubernetes/audit-policy.yaml <span class="p">|</span> head -n <span class="m">6</span>
</span></span><span class="line"><span class="cl">apiVersion: audit.k8s.io/v1
</span></span><span class="line"><span class="cl">kind: Policy
</span></span><span class="line"><span class="cl">omitStages:
</span></span><span class="line"><span class="cl">  - <span class="s2">&#34;RequestReceived&#34;</span>
</span></span><span class="line"><span class="cl">  - level: Metadata   <span class="c1"># 兜底规则：全部请求记元数据</span>
</span></span><span class="line"><span class="cl">（secrets 等敏感资源取 Metadata 级别，鉴权失败与删除类取 Request 级别）
</span></span></code></pre></div>
</details>


### B. 审计事件样例

**核查命令**：

```bash
tail -n 2 /var/log/kubernetes/audit/audit.log 2>/dev/null
kubectl -n kube-system get pod kube-apiserver-demo-node1 -o jsonpath='{.spec.volumes[*].hostPath.path}{"\n"}'
```

- 备注：抽取最近两条审计事件核对字段完整性：`stage`（RequestReceived/ResponseStarted/ResponseComplete/Panic）、`user.username`、`sourceIPs`、`verb`、`objectRef`（资源/命名空间/名称）、`responseStatus.code`；同时核对 API Server 静态 Pod 的 hostPath 卷是否把审计日志目录挂入容器（否则日志写在容器内随 Pod 重建丢失）。取证截图须对用户名、来源 IP、对象名称脱敏。
- 预期证据：审计事件样例截图（字段齐全）、hostPath 卷挂载截图、事件与操作时间对应说明。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-json" data-lang="json"><span class="line"><span class="cl"><span class="p">{</span><span class="nt">&#34;kind&#34;</span><span class="p">:</span><span class="s2">&#34;Event&#34;</span><span class="p">,</span><span class="nt">&#34;apiVersion&#34;</span><span class="p">:</span><span class="s2">&#34;audit.k8s.io/v1&#34;</span><span class="p">,</span><span class="nt">&#34;level&#34;</span><span class="p">:</span><span class="s2">&#34;Metadata&#34;</span><span class="p">,</span><span class="nt">&#34;auditID&#34;</span><span class="p">:</span><span class="s2">&#34;5f2a...&#34;</span><span class="p">,</span><span class="nt">&#34;stage&#34;</span><span class="p">:</span><span class="s2">&#34;ResponseComplete&#34;</span><span class="p">,</span>
</span></span><span class="line"><span class="cl"> <span class="nt">&#34;requestURI&#34;</span><span class="p">:</span><span class="s2">&#34;/api/v1/namespaces/demo-namespace/secrets&#34;</span><span class="p">,</span><span class="nt">&#34;verb&#34;</span><span class="p">:</span><span class="s2">&#34;create&#34;</span><span class="p">,</span>
</span></span><span class="line"><span class="cl"> <span class="nt">&#34;user&#34;</span><span class="p">:{</span><span class="nt">&#34;username&#34;</span><span class="p">:</span><span class="s2">&#34;demo-admin&#34;</span><span class="p">,</span><span class="nt">&#34;groups&#34;</span><span class="p">:[</span><span class="s2">&#34;demo-team&#34;</span><span class="p">,</span><span class="s2">&#34;system:authenticated&#34;</span><span class="p">]},</span>
</span></span><span class="line"><span class="cl"> <span class="nt">&#34;sourceIPs&#34;</span><span class="p">:[</span><span class="s2">&#34;192.168.30.21&#34;</span><span class="p">],</span><span class="nt">&#34;objectRef&#34;</span><span class="p">:{</span><span class="nt">&#34;resource&#34;</span><span class="p">:</span><span class="s2">&#34;secrets&#34;</span><span class="p">,</span><span class="nt">&#34;namespace&#34;</span><span class="p">:</span><span class="s2">&#34;demo-namespace&#34;</span><span class="p">,</span><span class="nt">&#34;name&#34;</span><span class="p">:</span><span class="s2">&#34;demo-db-credential&#34;</span><span class="p">},</span>
</span></span><span class="line"><span class="cl"> <span class="nt">&#34;responseStatus&#34;</span><span class="p">:{</span><span class="nt">&#34;metadata&#34;</span><span class="p">:{},</span><span class="nt">&#34;code&#34;</span><span class="p">:</span><span class="mi">201</span><span class="p">},</span><span class="nt">&#34;requestReceivedTimestamp&#34;</span><span class="p">:</span><span class="s2">&#34;2026-08-28T03:12:05.001Z&#34;</span><span class="p">,</span>
</span></span><span class="line"><span class="cl"> <span class="nt">&#34;stageTimestamp&#34;</span><span class="p">:</span><span class="s2">&#34;2026-08-28T03:12:05.018Z&#34;</span><span class="p">}</span>
</span></span><span class="line"><span class="cl"><span class="err">（用户、动词、对象、来源</span> <span class="err">IP、结果五要素齐全，事件经采集器上送日志平台）</span>
</span></span></code></pre></div>
</details>


### C. 集中化与节点侧日志

**核查命令**：

```bash
kubectl logs -n kube-system kube-apiserver-demo-node1 --tail=20
journalctl -u kubelet --no-pager | tail -n 30
grep -R -i "audit" /etc/rsyslog.conf /etc/rsyslog.d 2>/dev/null | head -n 5
```

- 备注：`kubectl logs` 读取容器标准输出（kube-apiserver 进程日志，含启动参数与告警），`journalctl` 读取节点 kubelet 日志（节点操作、Pod 启停），两者与 API 审计日志互补构成完整审计链；确认三者是否经 rsyslog/采集器上送集中日志平台（SIEM），平台侧检索 6 个月前记录作为留存证据。kubeadm 部署下 kube-apiserver 容器日志亦落盘于节点容器运行时目录，现场按实际运行时取证。
- 预期证据：容器日志截图、kubelet 日志截图、rsyslog/日志平台外送配置截图、平台侧 6 个月前记录检索截图。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">journalctl -u kubelet --no-pager <span class="p">|</span> tail（节选）
</span></span><span class="line"><span class="cl">Aug <span class="m">28</span> 03:00:02 demo-node1 kubelet<span class="o">[</span>2150<span class="o">]</span>: I0828 ... <span class="s2">&#34;Pod status updated&#34;</span> <span class="nv">pod</span><span class="o">=</span><span class="s2">&#34;demo-namespace/demo-app-7f9c6b5d4-x2v8p&#34;</span> <span class="nv">status</span><span class="o">=</span>Running
</span></span><span class="line"><span class="cl">Aug <span class="m">28</span> 09:41:17 demo-node1 kubelet<span class="o">[</span>2150<span class="o">]</span>: E0828 ... <span class="s2">&#34;Failed to pull image&#34;</span> <span class="nv">pod</span><span class="o">=</span><span class="s2">&#34;demo-namespace/demo-web-67c9&#34;</span> <span class="nv">err</span><span class="o">=</span><span class="s2">&#34;pull access denied&#34;</span>
</span></span><span class="line"><span class="cl">（节点侧日志经 journald 持久化并由采集器上送日志平台，平台留存 <span class="m">365</span> 天）
</span></span></code></pre></div>
</details>


## 入侵防范

> **对应控制点**：GB/T 22239-2019 8.1.4.4 入侵防范 a)~h)、8.1.4.5 恶意代码防范
>
> **判定要点**：管理面 6443/2379 仅管理网可达、kubelet 10250 关闭匿名且走 Webhook 授权、10255 只读端口关闭、控制面版本在官方支持窗口内且漏洞修补有记录、镜像来源可信并有扫描、宿主机具备恶意代码防护 → 符合；部分项缺失但有等效补偿（防火墙限源、镜像准入、EDR）且证据齐全 → 部分符合；kubelet/etcd 匿名暴露、版本已 EOL 且存在公开利用漏洞 → 不符合（高风险）。
>
> **取证要求**：端口监听截图、kubelet 配置截图、etcd 证书认证配置截图、版本清单与支持窗口对照截图、漏洞扫描与整改记录、防火墙/安全组策略截图、宿主机防恶意代码软件截图。

<div class="alert alert-warning" role="alert"><div class="h4 alert-heading" role="heading">高风险提示</div>


kubelet 10250 匿名可访问 `/pods` 等敏感接口（泄露 Pod 规格与环境变量）或 10255 只读端口对外开放，判高风险；etcd 2379 未启用客户端证书认证且跨安全域可达，判高风险——官方文档原文"访问 etcd 等价于集群 root 权限"；控制面版本已超出官方支持窗口（仅维护最近三个小版本）且存在未修补公开利用漏洞，判不符合并出具整改。

判定口径详见 [22、高风险判定指引与加固对照表](../../../reinforce/其他系统或设备/22高风险判定指引与加固对照表/)。
</div>


### A. kubelet 端口与匿名访问

**核查命令**：

```bash
ss -lntp | grep -E "10250|10255"
grep -n -E "authentication:|anonymous|readOnlyPort|authorization" /var/lib/kubelet/config.yaml 2>/dev/null
curl -sk https://192.168.10.6:10250/pods | head -c 200
curl -sk http://192.168.10.6:10255/pods | head -c 200
```

- 备注：KubeletConfiguration 参考页标注 `authentication.anonymous.enabled` 配置默认 `false`（而 kubelet 命令行标志 `--anonymous-auth` 默认 `true`，两种口径的演进须以节点实际配置文件为准）；`authorization.mode` 默认 `Webhook`（回查 API Server 做 SubjectAccessReview），出现 `AlwaysAllow` 即记录整改。`readOnlyPort`（10255，无认证/授权的只读服务）在配置参考页默认 `0` 即关闭、命令行参考页默认 10255 且已标记废弃（应改由配置文件设置），官方端口与协议参考页现已不再列出 10255；两条 `curl` 分别为 10250（HTTPS）与 10255（HTTP）的匿名实测，回显 Pod JSON 即匿名读取成立，401/连接拒绝属预期阴性证据。
- 预期证据：端口监听截图（10255 无监听为阴性证据）、kubelet 配置截图、两条匿名访问实测回显截图、认证/授权配置截图。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">ss -lntp <span class="p">|</span> grep -E <span class="s2">&#34;10250|10255&#34;</span>
</span></span><span class="line"><span class="cl">LISTEN <span class="m">0</span> <span class="m">1024</span> 192.168.10.6:10250 users:<span class="o">((</span><span class="s2">&#34;kubelet&#34;</span>,pid<span class="o">=</span>2150,fd<span class="o">=</span>7<span class="o">))</span>
</span></span><span class="line"><span class="cl">（10255 无监听）
</span></span><span class="line"><span class="cl">grep -A <span class="m">3</span> <span class="s2">&#34;authentication&#34;</span> /var/lib/kubelet/config.yaml
</span></span><span class="line"><span class="cl">authentication:
</span></span><span class="line"><span class="cl">  anonymous:
</span></span><span class="line"><span class="cl">    enabled: <span class="nb">false</span>
</span></span><span class="line"><span class="cl">  x509:
</span></span><span class="line"><span class="cl">    clientCAFile: /etc/kubernetes/pki/ca.crt
</span></span><span class="line"><span class="cl">curl -sk https://192.168.10.6:10250/pods <span class="p">|</span> head -c <span class="m">200</span>
</span></span><span class="line"><span class="cl">Unauthorized
</span></span><span class="line"><span class="cl">（匿名访问关闭，10255 只读端口未开放，授权模式 Webhook）
</span></span></code></pre></div>
</details>


### B. etcd 暴露面与证书认证

**核查命令**：

```bash
ss -lntp | grep 2379
grep -n -E "client-cert-auth|trusted-ca-file|listen-client-urls|cert-file|key-file|peer" /etc/kubernetes/manifests/etcd.yaml 2>/dev/null
ETCDCTL_API=3 etcdctl --endpoints=127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key member list
```

- 备注：官方文档原文 "Access to etcd is equivalent to root permission in the cluster"，应仅允许 API Server 访问。核查项：`--listen-client-urls` 仅绑定本机与管理网地址、`--client-cert-auth=true` 配合 `--trusted-ca-file` 启用客户端证书校验、对端通信启用 `--peer-cert-file/--peer-key-file`（kubeadm 部署另含 `--peer-client-cert-auth=true`）；etcdctl 经 `-cacert/-cert/-key` 三参数连接成功即双向证书认证生效，无证书直连应失败。etcd 集群建议独立部署或与控制面同机时严格收敛监听，2380 为节点间 peer 端口。
- 预期证据：监听截图、etcd 清单证书参数截图、带证书 etcdctl 连接成功回显截图、无证书直连失败回显截图、网络隔离说明。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">ss -lntp <span class="p">|</span> grep <span class="m">2379</span>
</span></span><span class="line"><span class="cl">LISTEN <span class="m">0</span> <span class="m">128</span> 192.168.10.5:2379 users:<span class="o">((</span><span class="s2">&#34;etcd&#34;</span>,pid<span class="o">=</span>1876,fd<span class="o">=</span>9<span class="o">))</span>
</span></span><span class="line"><span class="cl">grep -E <span class="s2">&#34;client-cert-auth|listen-client-urls&#34;</span> /etc/kubernetes/manifests/etcd.yaml
</span></span><span class="line"><span class="cl">    - --listen-client-urls<span class="o">=</span>https://127.0.0.1:2379,https://192.168.10.5:2379
</span></span><span class="line"><span class="cl">    - --client-cert-auth<span class="o">=</span><span class="nb">true</span>
</span></span><span class="line"><span class="cl">    - --trusted-ca-file<span class="o">=</span>/etc/kubernetes/pki/etcd/ca.crt
</span></span><span class="line"><span class="cl"><span class="nv">ETCDCTL_API</span><span class="o">=</span><span class="m">3</span> etcdctl ... member list（节选）
</span></span><span class="line"><span class="cl">4a1b..., started, demo-node1, https://192.168.10.5:2380, https://192.168.10.5:2379, <span class="nb">false</span>
</span></span><span class="line"><span class="cl">（仅监听本机与管理网地址，客户端证书双向认证生效）
</span></span></code></pre></div>
</details>


### C. 版本与漏洞管理（含 EOL）

**核查命令**：

```bash
kubectl version
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kubeletVersion}{"\n"}{end}'
kubeadm version 2>/dev/null
kubeadm upgrade plan 2>/dev/null | head -n 20
```

- 备注：官方发布政策原文"维护最近三个小版本的发布分支"（1.19 起每个小版本约 1 年补丁支持），超出窗口的版本不再接收安全更新，须结合漏洞扫描报告与升级/缓解记录判定；`kubeadm upgrade plan` 为只读命令，回显当前版本与可升级目标，可作为升级管理的佐证。逐节点核对 kubelet 与 apiserver 版本偏差在官方版本偏差政策允许范围内。
- 预期证据：版本清单截图、官方支持窗口对照截图、漏洞扫描报告、升级工单/变更记录。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl version（节选）
</span></span><span class="line"><span class="cl">Server Version: v1.30.4
</span></span><span class="line"><span class="cl">kubectl get nodes -o <span class="nv">jsonpath</span><span class="o">=</span>...
</span></span><span class="line"><span class="cl">demo-node1  v1.30.4
</span></span><span class="line"><span class="cl">demo-node2  v1.30.4
</span></span><span class="line"><span class="cl">demo-node3  v1.30.4
</span></span><span class="line"><span class="cl">（v1.30 在官方维护的最近三个小版本窗口内，季度漏洞扫描与补丁记录在案）
</span></span></code></pre></div>
</details>


### D. 暴露面收敛与恶意代码防范

**核查命令**：

```bash
ss -lntp | grep -E "6443|10250|10255|2379|10257|10259"
iptables -L INPUT -n -v --line-numbers 2>/dev/null | head -n 20
firewall-cmd --list-all 2>/dev/null
```

- 备注：对照官方端口与协议参考页（6443 kube-apiserver、2379-2380 etcd、10250 kubelet、10257 controller-manager、10259 scheduler），管理面端口应仅管理网/工作节点网段可达，云上同步核查安全组。恶意代码防范分两层：宿主机防恶意代码软件/EDR 的安装、病毒库更新与拦截记录（截图取证）；容器层以镜像来源受控与扫描、准入策略（如 AlwaysPullImages、镜像签名校验）作为补偿，业务镜像的恶意代码责任结合镜像扫描报告判定。
- 预期证据：端口监听与端口表对照截图、防火墙/安全组策略截图、防恶意代码软件与病毒库截图、镜像扫描报告。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">ss -lntp <span class="p">|</span> grep -E <span class="s2">&#34;6443|2379&#34;</span>（节选）
</span></span><span class="line"><span class="cl">LISTEN <span class="m">0</span> <span class="m">128</span> 192.168.10.5:6443 users:<span class="o">((</span><span class="s2">&#34;kube-apiserver&#34;</span>,pid<span class="o">=</span>1702,fd<span class="o">=</span>7<span class="o">))</span>
</span></span><span class="line"><span class="cl">LISTEN <span class="m">0</span> <span class="m">128</span> 192.168.10.5:2379 users:<span class="o">((</span><span class="s2">&#34;etcd&#34;</span>,pid<span class="o">=</span>1876,fd<span class="o">=</span>9<span class="o">))</span>
</span></span><span class="line"><span class="cl">iptables -L INPUT -n -v（节选）
</span></span><span class="line"><span class="cl"><span class="m">1</span>  ACCEPT tcp -- * * 192.168.30.0/24  192.168.10.5  tcp dpt:6443
</span></span><span class="line"><span class="cl"><span class="m">2</span>  DROP  tcp -- * * 0.0.0.0/0       192.168.10.5  tcp dpt:6443
</span></span><span class="line"><span class="cl">（6443 仅业务/运维网段可达，宿主机部署 EDR 且病毒库当日更新）
</span></span></code></pre></div>
</details>


## 数据完整性

> **对应控制点**：GB/T 22239-2019 8.1.4.7 数据完整性 a)b)
>
> **判定要点**：API Server 与 etcd 之间启用 TLS（`--etcd-cafile/--etcd-certfile/--etcd-keyfile` 齐备且 etcd 侧客户端证书认证开启）、镜像按 digest 固定或具备镜像完整性校验/签名准入机制 → 符合；仅部分链路具备校验或镜像未固定且无准入补偿 → 部分符合；无任何完整性保护手段 → 不符合。
>
> **取证要求**：API Server 与 etcd 双侧 TLS 参数截图、etcdctl 证书连接回显截图、镜像清单与 digest/签名策略截图、镜像仓库校验机制说明。

### A. API Server 与 etcd 传输加密

**核查命令**：

```bash
kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml | grep -E "etcd-servers|etcd-cafile|etcd-certfile|etcd-keyfile"
grep -n -E "client-cert-auth|trusted-ca-file|peer-cert-file|peer-key-file" /etc/kubernetes/manifests/etcd.yaml 2>/dev/null
```

- 备注：API Server 侧三个 `--etcd-*` 参数与 etcd 侧 `--client-cert-auth`/`--trusted-ca-file` 必须成对出现，`--etcd-servers` 应为 HTTPS 地址；证书链（CA、服务端、客户端）与密钥文件权限（600）一并核对。kubeadm 部署默认即启用该链路，取证重在确认未被改动且证书在有效期内。
- 预期证据：双侧 TLS 参数截图、证书有效期截图（openssl x509 -noout -enddate 可选）、架构说明。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml <span class="p">|</span> grep etcd-
</span></span><span class="line"><span class="cl">    - --etcd-servers<span class="o">=</span>https://127.0.0.1:2379,https://192.168.10.5:2379
</span></span><span class="line"><span class="cl">    - --etcd-cafile<span class="o">=</span>/etc/kubernetes/pki/etcd/ca.crt
</span></span><span class="line"><span class="cl">    - --etcd-certfile<span class="o">=</span>/etc/kubernetes/pki/etcd/server.crt
</span></span><span class="line"><span class="cl">    - --etcd-keyfile<span class="o">=</span>/etc/kubernetes/pki/etcd/server.key
</span></span><span class="line"><span class="cl">（etcd 地址为 HTTPS 且 CA/证书/私钥三件套齐备，与 etcd 侧 client-cert-auth 对应）
</span></span></code></pre></div>
</details>


### B. 镜像完整性与准入校验

**核查命令**：

```bash
kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | tr " " "\n" | sort -u | head -n 20
kubectl -n demo-namespace get deploy demo-app -o jsonpath='{.spec.template.spec.containers[*].image}{"\n"}'
```

- 备注：抽样记录业务负载镜像的引用形态：`仓库:标签` 或 `仓库@sha256:摘要`。以 digest 引用可固定镜像内容，属最强的完整性固定方式；以标签引用时，结合私有仓库的只读策略、镜像签名校验（Cosign 等）或准入策略（如 AlwaysPullImages 准入插件、Kyverno/OPA 策略）作为补偿措施，现场以镜像仓库材料与准入配置截图佐证。镜像拉取地址应为单位内部仓库或可信外部源。
- 预期证据：镜像清单抽样截图、digest/签名策略截图、私有仓库材料、准入配置截图。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl get pods -A -o <span class="nv">jsonpath</span><span class="o">=</span>...（节选）
</span></span><span class="line"><span class="cl">registry.demo.local/demo/app@sha256:9c7f1e2b...
</span></span><span class="line"><span class="cl">registry.demo.local/demo/web:v2.3.1
</span></span><span class="line"><span class="cl">（核心业务镜像以 digest 固定，其余镜像经内部仓库准入拉取；仓库启用签名校验并保留扫描报告）
</span></span></code></pre></div>
</details>


## 数据保密性

> **对应控制点**：GB/T 22239-2019 8.1.4.8 数据保密性 a)b)
>
> **判定要点**：etcd 启用静态加密（`--encryption-provider-config`，加密 provider 为 secretbox/kms v2 等现行推荐且非 identity）、Secret 以加密形态落盘（抽样核验 `k8s:enc:` 前缀）、管理链路 TLS 最低版本不低于 1.2 → 符合；仅传输加密未启用静态加密 → 部分符合；Secret 明文落盘或明文传输鉴别信息 → 不符合（高风险）。
>
> **取证要求**：加密配置文件截图、API Server 参数截图、etcd 侧密文抽样截图、Secret 抽样截图（脱敏）、TLS 最低版本参数截图。

<div class="alert alert-warning" role="alert"><div class="h4 alert-heading" role="heading">高风险提示</div>


未配置 `--encryption-provider-config` 或 provider 首位为 `identity`（官方文档标注为默认明文形态），集群凭据、数据库口令等以明文落盘 etcd，而 etcd 访问权等价集群 root，按《高风险判定指引》鉴别信息明文存储同类口径判高风险。

判定口径详见 [22、高风险判定指引与加固对照表](../../../reinforce/其他系统或设备/22高风险判定指引与加固对照表/)。
</div>


### A. etcd 静态加密配置

**核查命令**：

```bash
kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml | grep -E "encryption-provider-config|encryption-provider-config-automatic-reload"
grep -n -E "apiVersion|kind|resources|providers|secretbox|aescbc|kms|identity" /etc/kubernetes/encryption-config.yaml 2>/dev/null
```

- 备注：官方加密文档列明的 provider：`identity`（明文，默认）、`aescbc`（因 CBC 填充预言攻击**不建议**）、`aesgcm`（须自动轮换密钥）、`kms v1`（v1.28 起废弃）、`kms v2`（v1.29 起稳定，密钥托管于集群外时推荐）、`secretbox`（XSalsa20+Poly1305，强度高且更快，**为现行推荐的无 KMS 场景选择**）。配置文件为 `apiVersion: apiserver.config.k8s.io/v1`、`kind: EncryptionConfiguration`；provider 顺序首个生效，首位不得为 identity（可作迁移期回退置于末位，迁移完成后移除）。数据仅在写入时加密，存量 Secret 须重写后才落加密形态。
- 预期证据：API Server 参数截图、EncryptionConfiguration 全文截图（密钥脱敏）、provider 选型与官方推荐对照说明。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml <span class="p">|</span> grep encryption
</span></span><span class="line"><span class="cl">    - --encryption-provider-config<span class="o">=</span>/etc/kubernetes/encryption-config.yaml
</span></span><span class="line"><span class="cl">    - --encryption-provider-config-automatic-reload<span class="o">=</span><span class="nb">true</span>
</span></span><span class="line"><span class="cl">grep -E <span class="s2">&#34;apiVersion|kind|providers|secretbox&#34;</span> /etc/kubernetes/encryption-config.yaml
</span></span><span class="line"><span class="cl">apiVersion: apiserver.config.k8s.io/v1
</span></span><span class="line"><span class="cl">kind: EncryptionConfiguration
</span></span><span class="line"><span class="cl">    providers:
</span></span><span class="line"><span class="cl">      - secretbox:
</span></span><span class="line"><span class="cl">（secretbox 为首位 provider，密钥文件权限 <span class="m">600</span> 且仅 root 可读）
</span></span></code></pre></div>
</details>


### B. Secret 落盘形态与 TLS 最低版本

**核查命令**：

```bash
kubectl get secrets -A --no-headers | head -n 10
kubectl -n demo-namespace get secret demo-db-credential -o jsonpath='{.type}{"\t"}{.data}{"\n"}'
ETCDCTL_API=3 etcdctl --endpoints=127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key get /registry/secrets/demo-namespace/demo-db-credential --print-value-only | head -c 60
grep -n -E "tls-min-version" /etc/kubernetes/manifests/kube-apiserver.yaml 2>/dev/null
```

- 备注：`kubectl` 侧 Secret 的 `.data` 值为 Base64 编码（**编码不等于加密**，可读性由 RBAC 控制），抽样截图须脱敏；etcd 侧按对象键 `/registry/secrets/<命名空间>/<名称>` 读取原始值，密文前缀 `k8s:enc:<provider>:...`（如 `k8s:enc:secretbox:v1:key1:`）即为静态加密生效的直接证据，明文 JSON 则证实未加密。`--tls-min-version` 建议取 `VersionTLS12` 及以上（可选值 VersionTLS10/11/12/13，未显式设置时为空、走 Go 默认策略，须记录现场取值）。
- 预期证据：Secret 清单与类型抽样截图（脱敏）、etcd 密文前缀截图、TLS 最低版本参数截图。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl -n demo-namespace get secret demo-db-credential -o <span class="nv">jsonpath</span><span class="o">=</span><span class="s1">&#39;{.type}&#39;</span>
</span></span><span class="line"><span class="cl">Opaque
</span></span><span class="line"><span class="cl"><span class="nv">ETCDCTL_API</span><span class="o">=</span><span class="m">3</span> etcdctl ... get /registry/secrets/demo-namespace/demo-db-credential --print-value-only <span class="p">|</span> head -c <span class="m">60</span>
</span></span><span class="line"><span class="cl">k8s:enc:secretbox:v1:key1:&lt;二进制密文…&gt;
</span></span><span class="line"><span class="cl">grep tls-min-version /etc/kubernetes/manifests/kube-apiserver.yaml
</span></span><span class="line"><span class="cl">    - --tls-min-version<span class="o">=</span>VersionTLS12
</span></span><span class="line"><span class="cl">（etcd 落盘为 secretbox 密文，API Server 最低 TLS 1.2，kubectl 侧内容经 RBAC 控制访问）
</span></span></code></pre></div>
</details>


## 备份恢复

> **对应控制点**：GB/T 22239-2019 8.1.4.9 数据备份恢复 a)c)
>
> **判定要点**：etcd 具备定期快照且快照文件可校验（snapshot status 通过）、编排与持久卷数据具备备份机制（Velero 等）或快照（VolumeSnapshot）、恢复经演练并有记录、控制面多节点冗余 → 符合；有备份无演练、或仅冗余无快照 → 部分符合；无任何备份与冗余措施 → 不符合（高风险）。
>
> **取证要求**：快照文件清单与状态校验回显截图、备份策略/计划任务截图、Velero/快照资源清单截图、恢复演练记录、控制面节点冗余说明。

### A. etcd 快照核验

**核查命令**：

```bash
ls -l /var/backups/etcd/ 2>/dev/null
etcdutl snapshot status /var/backups/etcd/snapshot-demo-20260828.db -w table
ETCDCTL_API=3 etcdctl snapshot status /var/backups/etcd/snapshot-demo-20260828.db --write-out=table 2>/dev/null
crontab -l 2>/dev/null | grep -i etcd
```

- 备注：**etcd v3.5 起官方将快照工具迁移至 `etcdutl`**（恢复文档以 `etcdutl snapshot status <文件> -w table` 为准，`-w table` 为 `--write-out=table` 缩写；旧版本仍为 `ETCDCTL_API=3 etcdctl snapshot status <文件> --write-out=table`，且 etcdctl 的 snapshot status 已被标记废弃），现场按 etcd 实际版本选用，两条命令任选其一核验**既有快照文件**，回显 HASH/REVISION/TOTAL KEYS/TOTAL SIZE 即文件完整可读；`snapshot save`、`snapshot restore` 属写入/变更操作，仅由运维方在授权下演练，测评人员不执行。快照目录应与 etcd 数据目录分离并纳入异地/离线备份。
- 预期证据：快照文件清单截图、snapshot status 校验回显截图、定时任务/备份平台策略截图、恢复演练记录。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">ls -l /var/backups/etcd/
</span></span><span class="line"><span class="cl">-rw------- <span class="m">1</span> root root 47M Aug <span class="m">28</span> 03:05 snapshot-demo-20260828.db
</span></span><span class="line"><span class="cl">-rw------- <span class="m">1</span> root root 45M Aug <span class="m">27</span> 03:05 snapshot-demo-20260827.db
</span></span><span class="line"><span class="cl">etcdutl snapshot status /var/backups/etcd/snapshot-demo-20260828.db -w table
</span></span><span class="line"><span class="cl">+----------+----------+------------+------------+
</span></span><span class="line"><span class="cl"><span class="p">|</span>   HASH   <span class="p">|</span> REVISION <span class="p">|</span> TOTAL KEYS <span class="p">|</span> TOTAL SIZE <span class="p">|</span>
</span></span><span class="line"><span class="cl">+----------+----------+------------+------------+
</span></span><span class="line"><span class="cl"><span class="p">|</span> fe1e2c86 <span class="p">|</span>   <span class="m">452817</span> <span class="p">|</span>      <span class="m">15234</span> <span class="p">|</span>       <span class="m">45</span> MB <span class="p">|</span>
</span></span><span class="line"><span class="cl">+----------+----------+------------+------------+
</span></span><span class="line"><span class="cl">crontab -l <span class="p">|</span> grep -i etcd
</span></span><span class="line"><span class="cl"><span class="m">5</span> <span class="m">3</span> * * * /usr/local/bin/etcd-backup.sh（每日快照并同步异地存储，保留 <span class="m">30</span> 份）
</span></span></code></pre></div>
</details>


### B. 编排与持久化数据备份

**核查命令**：

```bash
kubectl get volumesnapshots -A
kubectl get volumesnapshotclasses
velero backup get
velero backup describe demo-full-20260828 --details 2>/dev/null | head -n 30
```

- 备注：VolumeSnapshot/VolumeSnapshotContent/VolumeSnapshotClass 为 `snapshot.storage.k8s.io/v1` API 组下的 CRD（须集群已安装快照控制器与 CSI 驱动方可查询）；Velero 场景以 `velero backup get` 核对备份清单（名称/状态/时间/过期）、`velero backup describe <名称> --details` 核对资源包含与卷快照明细，均为只读命令（具体子命令以 `velero backup --help` 现场为准）。备份对象应覆盖控制面配置（kubeadm 证书、清单文件）与业务持久卷数据；恢复能力以演练记录佐证。
- 预期证据：VolumeSnapshot 清单截图、Velero 备份清单与明细截图、备份策略与周期截图、恢复演练记录、控制面配置备份说明。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl get volumesnapshots -A（节选）
</span></span><span class="line"><span class="cl">NAMESPACE        NAME                        READYTOUSE   SOURCEPVC        RESTORESIZE
</span></span><span class="line"><span class="cl">demo-namespace   demo-app-snap-20260828      <span class="nb">true</span>         demo-app-data    20Gi
</span></span><span class="line"><span class="cl">velero backup get（节选）
</span></span><span class="line"><span class="cl">NAME                    STATUS       ERRORS   WARNINGS   CREATED                     EXPIRES
</span></span><span class="line"><span class="cl">demo-full-20260828      Completed    <span class="m">0</span>        <span class="m">0</span>          2026-08-28 03:00:05 +0800   26d
</span></span><span class="line"><span class="cl">demo-full-20260827      Completed    <span class="m">0</span>        <span class="m">0</span>          2026-08-27 03:00:05 +0800   27d
</span></span><span class="line"><span class="cl">（Velero 每日全量备份至对象存储，卷快照由 CSI 驱动产生，半年一次恢复演练）
</span></span></code></pre></div>
</details>


## 剩余信息保护

> **对应控制点**：GB/T 22239-2019 8.1.4.10 剩余信息保护 a)b)
>
> **判定要点**：已删除资源的存储空间被平台回收（终态 Pod、孤儿 PV/PVC、废弃 Secret 有清理机制）、失效凭据（旧 token、离员用户 kubeconfig、过期证书）得到清理、节点磁盘上敏感文件权限受控 → 符合；有清理但无制度与记录、存量长期凭据未处置 → 部分符合；废弃 Secret/manifest 中明文凭据长期残留 → 不符合。
>
> **取证要求**：终态与异常 Pod 清单截图、PVC/PV 清单截图、ServiceAccount token Secret 存量截图、离员账户凭据清理记录、磁盘残留排查截图、清理制度文件。

### A. 终态资源与存储残留

**核查命令**：

```bash
kubectl get pods -A --field-selector=status.phase=Succeeded 2>/dev/null | head -n 10
kubectl get pods -A --field-selector=status.phase=Failed 2>/dev/null | head -n 10
kubectl get pvc -A
kubectl get pv | grep -iE "released|failed" 
```

- 备注：`Succeeded/Failed` 终态 Pod 由 kubelet 的垃圾回收策略（基于 terminated-pod-gc-threshold 等）清理，长期堆积应记录并要求设置回收策略；PVC 删除后 PV 转入 `Released` 而回收策略为 Retain 时数据仍占盘，须按制度处置；绑定失败（Pending/Failed）的卷同样登记。Etcd 中已删除对象的空间由 etcd 压缩/碎片整理机制回收（运维侧定期执行），取证以资源清单与制度说明佐证。
- 预期证据：终态 Pod 清单截图、PVC/PV 状态截图、垃圾回收与压缩策略说明、清理记录。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl get pvc -A（节选）
</span></span><span class="line"><span class="cl">NAMESPACE        NAME                STATUS   VOLUME                                     CAPACITY
</span></span><span class="line"><span class="cl">demo-namespace   demo-app-data       Bound    pvc-3f2a1b6c-...                           20Gi
</span></span><span class="line"><span class="cl">demo-namespace   demo-test-old       Bound    pvc-8c1d9e2a-...                           5Gi
</span></span><span class="line"><span class="cl">kubectl get pv <span class="p">|</span> grep -i released
</span></span><span class="line"><span class="cl">pvc-1a2b...  10Gi  RWO  Retain   Released  demo-namespace/demo-removed
</span></span><span class="line"><span class="cl">（1 个 Released 卷按 Retain 保留，纳入季度清理计划）
</span></span></code></pre></div>
</details>


### B. 失效凭据与令牌清理

**核查命令**：

```bash
kubectl get secrets -A | grep -i "service-account-token"
kubectl get serviceaccounts -A
ls -l ~/.kube /etc/kubernetes/*.conf 2>/dev/null
find / -maxdepth 4 -name "kubeconfig*" -o -maxdepth 4 -name "*.conf" -path "*kube*" 2>/dev/null | head -n 10
```

- 备注：**v1.24 起不再为每个 ServiceAccount 自动生成长期 legacy token Secret**（相关特性门控在 v1.27 升级为 GA 后移除），v1.28~v1.33 集群中出现 `kubernetes.io/service-account-token` 类型 Secret 即为手工创建或历史升级残留，逐个核验用途与有效性（凭据是否已失效但未删除）；离员人员的 kubeconfig、过期客户端证书应有回收记录。kubeconfig 与私钥文件权限 600、归属 root。
- 预期证据：token Secret 存量截图、离员账户凭据回收记录、kubeconfig 权限截图、清理制度与工单。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl get secrets -A <span class="p">|</span> grep -i <span class="s2">&#34;service-account-token&#34;</span>
</span></span><span class="line"><span class="cl">demo-namespace   legacy-deploy-token   kubernetes.io/service-account-token   <span class="m">3</span>   39d
</span></span><span class="line"><span class="cl">（存量 <span class="m">1</span> 个手工创建的长期 token Secret：业务确认仍需使用，已收窄 RBAC 权限并纳入季度复核；其余均为 v1.24 后签发的短生命周期令牌）
</span></span></code></pre></div>
</details>


## 个人信息保护

> **对应控制点**：GB/T 22239-2019 8.1.4.11 个人信息保护 a)b)
>
> **判定要点**：平台元数据与审计日志仅承载运维必需的用户名/UID/来源 IP 等字段且访问受 RBAC 控制、审计策略对敏感资源取 Metadata 级别避免记录业务数据体、日志外送前有脱敏与导出审批 → 符合；有访问控制但字段未最小化或导出无管控 → 部分符合；审计/配置/镜像中明文记录身份证号、手机号、令牌等且无访问控制 → 不符合（高风险）。
>
> **取证要求**：审计策略级别配置截图、审计日志样例（脱敏）、日志平台访问与导出审批记录、元数据抽样截图、不涉及个人信息时的数据流说明。

### A. 审计日志中的用户数据与脱敏

**核查命令**：

```bash
tail -n 2 /var/log/kubernetes/audit/audit.log 2>/dev/null
grep -n -E "level: RequestResponse" /etc/kubernetes/audit-policy.yaml 2>/dev/null | head -n 5
```

- 备注：API 审计日志天然记录操作者用户名、UID、来源 IP 与请求 URI，属运维审计必需字段；`RequestResponse` 级别会把请求/响应体（Secret 内容、业务数据）整段写入日志，**敏感资源规则应取 Metadata 级别并配合 omitStages 字段最小化**，现场核对策略级别与日志样例一致。日志平台侧的访问权限、脱敏规则与导出审批记录一并取证；Kubernetes 平台层通常不直接处理业务个人信息，个人信息保护责任主要在容器内应用，审计日志中的个人信息以用户名/来源 IP 为主。
- 【不适用】若测评对象仅限定为 Kubernetes 平台层，业务个人信息全部由容器内应用处理且平台元数据不含个人信息，则该点对平台层可判定为不适用（留存审计日志字段清单与数据流说明作依据）。依据：GB/T 28448-2019 个人信息保护控制点以实际处理个人信息为前提。
- 预期证据：审计策略级别截图、脱敏日志样例截图、日志平台权限与导出审批记录、访谈记录。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">tail -n <span class="m">1</span> /var/log/kubernetes/audit/audit.log（节选，已脱敏）
</span></span><span class="line"><span class="cl"><span class="s2">&#34;verb&#34;</span>:<span class="s2">&#34;get&#34;</span>,<span class="s2">&#34;user&#34;</span>:<span class="o">{</span><span class="s2">&#34;username&#34;</span>:<span class="s2">&#34;demo-admin&#34;</span>,...<span class="o">}</span>,<span class="s2">&#34;sourceIPs&#34;</span>:<span class="o">[</span><span class="s2">&#34;192.168.30.21&#34;</span><span class="o">]</span>,
</span></span><span class="line"><span class="cl"><span class="s2">&#34;objectRef&#34;</span>:<span class="o">{</span><span class="s2">&#34;resource&#34;</span>:<span class="s2">&#34;secrets&#34;</span>,<span class="s2">&#34;namespace&#34;</span>:<span class="s2">&#34;demo-namespace&#34;</span>,<span class="s2">&#34;name&#34;</span>:<span class="s2">&#34;***&#34;</span><span class="o">}</span>
</span></span><span class="line"><span class="cl">（secrets 类请求按策略记录 Metadata 级别，未包含请求/响应体；日志平台对 username 与 IP 做展示脱敏，导出需工单审批）
</span></span></code></pre></div>
</details>


### B. 元数据与镜像中的个人信息残留

**核查命令**：

```bash
kubectl get configmaps -A --no-headers | head -n 10
kubectl -n demo-namespace get configmap demo-app-config -o jsonpath='{.data}' 2>/dev/null | head -c 300
```

- 备注：抽样核查 ConfigMap、标签、注解等元数据中是否混入姓名、手机号、邮箱等个人信息或明文凭据（开发调试残留是常见形态）；镜像与环境变量中的个人信息残留结合镜像扫描报告与应用方说明判定。平台层未见此类承载、个人信息全部在容器内应用处理时，按不适用口径处理并留证。
- 预期证据：元数据抽样截图（脱敏）、镜像扫描报告、应用方说明、整改记录。


<details class="td-details"><summary>示例输出（节选）</summary><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">kubectl -n demo-namespace get configmap demo-app-config -o <span class="nv">jsonpath</span><span class="o">=</span><span class="s1">&#39;{.data}&#39;</span> <span class="p">|</span> head -c <span class="m">300</span>
</span></span><span class="line"><span class="cl"><span class="o">{</span><span class="s2">&#34;log.level&#34;</span>:<span class="s2">&#34;info&#34;</span>,<span class="s2">&#34;feature.flags&#34;</span>:<span class="s2">&#34;a,b&#34;</span>,<span class="s2">&#34;admin.contact&#34;</span>:<span class="s2">&#34;***@demo.local&#34;</span><span class="o">}</span>
</span></span><span class="line"><span class="cl">（抽样未见身份证号、手机号等个人信息；联系邮箱为运维公共邮箱，属平台元数据合理字段）
</span></span></code></pre></div>
</details>


## 参考依据

- GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》（8.1.4 安全计算环境）：[http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=BAFB47E8874764186BDB7865E8344DAF](http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=BAFB47E8874764186BDB7865E8344DAF)
- GB/T 28448-2019《信息安全技术 网络安全等级保护测评要求》（单元测评的测评实施与结果判定：符合/部分符合/不符合/不适用）：[http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=7E736CDF4502B6FF1258DD250AA3EC8C](http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=7E736CDF4502B6FF1258DD250AA3EC8C)
- GB/T 25070-2019《信息安全技术 网络安全等级保护安全设计技术要求》，可在全国标准信息公共服务平台检索：[http://openstd.samr.gov.cn/bzgk/gb/](http://openstd.samr.gov.cn/bzgk/gb/)
- Kubernetes 官方 kube-apiserver 命令行参考（`--anonymous-auth`、`--audit-policy-file`、`--audit-log-*`、`--etcd-*`、`--encryption-provider-config`、`--oidc-*`、`--tls-min-version`、默认准入插件清单）：[https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/)
- Kubernetes 官方 kubelet 命令行参考与 KubeletConfiguration v1beta1 参考（`--anonymous-auth`、`--read-only-port`、`authentication.anonymous.enabled`、`authorization.mode`、`rotateCertificates`）：[https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)、[https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/)
- Kubernetes 官方审计文档（审计策略结构与 None/Metadata/Request/RequestResponse 级别、日志后端参数、omitStages）：[https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/)
- Kubernetes API 健康检查端点文档（`/healthz` 自 v1.16 废弃、`kubectl get --raw='/readyz?verbose'`）：[https://kubernetes.io/docs/reference/using-api/health-checks/](https://kubernetes.io/docs/reference/using-api/health-checks/)
- Kubernetes 认证/授权/RBAC 官方文档（匿名请求 `system:anonymous`/`system:unauthenticated`、`--anonymous-auth=false`、OIDC 参数、`cluster-admin` 定义、默认角色绑定）：[https://kubernetes.io/docs/reference/access-authn-authz/authentication/](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)、[https://kubernetes.io/docs/reference/access-authn-authz/authorization/](https://kubernetes.io/docs/reference/access-authn-authz/authorization/)、[https://kubernetes.io/docs/reference/access-authn-authz/rbac/](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
- Kubernetes Pod Security Admission 概念文档（v1.25 起稳定、enforce/audit/warn 三模式与 privileged/baseline/restricted 三级、命名空间标签）：[https://kubernetes.io/docs/concepts/security/pod-security-admission/](https://kubernetes.io/docs/concepts/security/pod-security-admission/)
- Kubernetes etcd 静态加密任务文档（provider 一览、aescbc 不建议、kms v2 自 v1.29 稳定、`--encryption-provider-config`、`k8s:enc:` 前缀核验）：[https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)
- Kubernetes ServiceAccount 概念文档（v1.24 起不再自动生成 legacy token、TokenRequest API、`automountServiceAccountToken`）：[https://kubernetes.io/docs/concepts/security/service-accounts/](https://kubernetes.io/docs/concepts/security/service-accounts/)
- Kubernetes 端口与协议参考（6443/2379-2380/10250/10257/10259）与 etcd 集群运维文档（`--client-cert-auth`、`--etcd-certfile` 三件套、"访问 etcd 等价集群 root"）：[https://kubernetes.io/docs/reference/networking/ports-and-protocols/](https://kubernetes.io/docs/reference/networking/ports-and-protocols/)、[https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/)
- Kubernetes 静态 Pod 任务文档（`staticPodPath`、`/etc/kubernetes/manifests`）与 kubectl 快速参考：[https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/)、[https://kubernetes.io/docs/reference/kubectl/quick-reference/](https://kubernetes.io/docs/reference/kubectl/quick-reference/)
- Kubernetes 发布与版本支持政策（维护最近三个小版本、1.19 起约 1 年补丁支持）：[https://kubernetes.io/releases/](https://kubernetes.io/releases/)
- etcd 官方灾难恢复文档（`etcdutl snapshot status`、v3.5 起快照工具迁移）：[https://etcd.io/docs/v3.5/op-guide/recovery/](https://etcd.io/docs/v3.5/op-guide/recovery/)
- Velero 官方文档（备份、恢复与快照）：[https://velero.io/docs/](https://velero.io/docs/)
- CIS Kubernetes Benchmark（社区共识的 Kubernetes 安全配置基线，需注册下载）：[https://www.cisecurity.org/benchmark/kubernetes/](https://www.cisecurity.org/benchmark/kubernetes/)
- 《网络安全等级保护测评高风险判定指引》（中关村信息安全测评联盟团体标准），站内对照表：[22、高风险判定指引与加固对照表](../../../reinforce/其他系统或设备/22高风险判定指引与加固对照表/)
- 命令核验说明：本文命令已于 2026-09 对照 kubernetes.io 官方文档（kube-apiserver/kubelet 命令行参考、KubeletConfiguration v1beta1、审计、健康检查端点、认证/授权/RBAC、Pod Security Admission、etcd 静态加密与运维、ServiceAccount、静态 Pod、端口与协议、发布政策）及 etcd.io 灾难恢复文档逐条核验。版本差异注意点：`kubectl version --short` 于 v1.28 整体移除（默认输出改为原 short 形态，1.24~1.27 使用时回显废弃警告）；`kubectl get componentstatuses` 自 v1.19+ 废弃，替代为 `/readyz?verbose` 健康检查端点（`/healthz` 自 v1.16 废弃）；kube-apiserver `--anonymous-auth` 现行默认 `true`，kubelet 命令行标志同默认而 KubeletConfiguration 文档默认为 `enabled: false`，且新版引入 `--authentication-config` 配置文件路径，现场以实际参数与匿名实测为准；10255 只读端口已标记废弃且官方端口参考页不再列出，KubeletConfiguration 默认 `readOnlyPort: 0`（关闭），关闭写法为 0；审计策略为 `audit.k8s.io/v1` schema 且 rules 必填，现行参考页 `--audit-log-maxage` 默认 366；etcd 静态加密现行推荐 `secretbox`（aescbc 因填充预言攻击不建议，kms v1 自 v1.28 废弃、kms v2 自 v1.29 稳定）；etcd v3.5 起快照状态核验迁移至 `etcdutl snapshot status`，旧版为 `etcdctl snapshot status --write-out=table`；ServiceAccount legacy token 自 v1.24 起不再自动生成（特性门控 v1.27 GA 后移除）；Pod Security Admission 自 v1.25 起稳定且默认级别为 privileged（须命名空间显式打标才生效）；官方仅维护最近三个小版本，超出窗口即不再接收安全补丁。

## 关联文章

- 容器与中间件：[Docker 容器运行平台测评](../docker/)、[Memcached 缓存服务测评](../memcached/)、[Redis 缓存数据库测评](../redis/)、[Apache ZooKeeper 协调服务测评](../zookeeper/)
- 板块目录：[中间件与容器](/wikis/docs/gradeprotection/%E4%B8%AD%E9%97%B4%E4%BB%B6%E4%B8%8E%E5%AE%B9%E5%99%A8/)
- 配套加固：[17、网络设备、安全设备、服务器、数据库和应用系统的加固方案](../../../reinforce/其他系统或设备/17网络设备安全设备服务器数据库和应用系统的加固方案/)
- 取证记录：[16、安全评估加固记录表3.0](../../../reinforce/其他系统或设备/16安全评估加固记录表3.0/)
- 高风险口径：[22、高风险判定指引与加固对照表](../../../reinforce/其他系统或设备/22高风险判定指引与加固对照表/)
