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 备份等只读取证命令，覆盖身份鉴别、访问控制、安全审计、入侵防范、数据完整性与保密性、备份恢复等控制点，附判定要点、高风险提示、示例输出与版本差异核验说明。
Categories:

  13 分钟阅读  

定位：Kubernetes 容器编排平台三级等保现场测评取证命令单，按 GB/T 22239-2019 安全计算环境控制点分节组织核查命令、判定要点与取证要求。 适用范围：Kubernetes v1.28~v1.33（kubeadm 部署与二进制部署均适用；托管集群/其他发行版组件配置位置不同，须先确认部署形态再套用取证路径）。 配套文章：22、高风险判定指引与加固对照表、16、安全评估加固记录表3.0、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 清单截图、控制面组件健康状态截图。

核查命令：

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 截图。
示例输出（节选）
kubectl version
Client Version: v1.30.4
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.30.4
kubectl get nodes -o wide
NAME          STATUS   ROLES           AGE   VERSION   INTERNAL-IP     OS-IMAGE            CONTAINER-RUNTIME
demo-node1    Ready    control-plane   40d   v1.30.4   192.168.10.5    Ubuntu 22.04.4 LTS  containerd://1.7.19
demo-node2    Ready    worker          40d   v1.30.4   192.168.10.6    Ubuntu 22.04.4 LTS  containerd://1.7.19
demo-node3    Ready    worker          40d   v1.30.4   192.168.10.7    Ubuntu 22.04.4 LTS  containerd://1.7.19
kubectl cluster-info
Kubernetes control plane is running at https://192.168.10.5:6443
CoreDNS is running at https://192.168.10.5:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
kubectl get --raw='/readyz?verbose'
[+]ping ok
[+]log ok
[+]etcd ok
[+]poststarthook/start-apiserver-admission-initializer ok
healthz check passed
（另：kubectl get cs 回显 "Warning: v1 ComponentStatus is deprecated in v1.19+"，仅作对照留存）

身份鉴别

对应控制点：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 文件权限截图。

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

核查命令：

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 两种情形）、匿名权限清单截图。
示例输出（节选）
kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml | grep anonymous-auth
    - --anonymous-auth=false
curl -sk https://192.168.10.5:6443/version | head -c 300
{"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Unauthorized","reason":"Unauthorized","code":401}
（匿名访问已关闭：无凭据请求回显 401，属预期阴性证据）
kubectl auth can-i --list --as=system:anonymous（另一现场开启匿名时的抽样，节选）
Resources                                       Non-Resource URLs   Resource Names   Verbs
                                                [/version]          []               [get]
                                                [/healthz...]       []               [get]
（匿名仅命中 system:public-info-viewer 的公开只读端点，未见资源类权限）

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

核查命令：

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 参数截图、统一认证平台对接材料、用户名与组映射说明、访谈记录。
示例输出（节选）
kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml | grep "oidc-"
    - --oidc-issuer-url=https://sso.demo.local/realms/demo
    - --oidc-client-id=kubernetes
    - --oidc-username-claim=email
    - --oidc-groups-claim=groups
    - --oidc-ca-file=/etc/kubernetes/pki/sso-ca.crt
（人员用户经单位统一认证平台 SSO 签发 JWT 接入，证书 CN 账户仅保留给节点与系统组件）

C. ServiceAccount 与 Pod 凭据挂载

核查命令：

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 存量说明。
示例输出（节选）
kubectl get pods -A -o jsonpath=...（节选）
  212  <空>/自动挂载
   38  false
   12  true
kubectl -n demo-namespace get pod demo-app-7f9c6b5d4-x2v8p -o jsonpath=...
/var/run/secrets/kubernetes.io/serviceaccount
（业务命名空间 38 个 Pod 已显式关闭自动挂载；kube-system 系统 Pod 属正常挂载）

D. kubeconfig 与组件证书形态

核查命令：

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 目录截图、证书轮换配置截图。
示例输出（节选）
ls -l /etc/kubernetes/admin.conf
-rw------- 1 root root 5652 Aug 24 09:12 /etc/kubernetes/admin.conf
kubectl config view（节选）
- name: kubernetes-admin
  user:
    client-certificate-data: DATA+OMITTED
    client-key-data: DATA+OMITTED
ls -l /var/lib/kubelet/pki
-rw------- 1 root root 1289 kubelet-client-current.pem
-rw-r--r-- 1 root root 1237 kubelet.crt
（kubeconfig 权限 600，凭据在取证输出中自动脱敏）

访问控制

对应控制点：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 抽样截图与业务说明。

A. RBAC 绑定审计

核查命令：

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 主体截图、匿名/未认证绑定核查截图（含无输出阴性证据）、宽泛授权整改记录。
示例输出（节选）
kubectl get clusterrolebinding cluster-admin -o jsonpath=...
Group    system:masters
（cluster-admin 仅绑定 system:masters 组，人员账户不直接持有）
kubectl get clusterrolebindings -o jsonpath=... | grep -E "system:anonymous|system:unauthenticated"
（无输出：匿名与未认证主体未绑定任何 ClusterRole）
kubectl get clusterrolebindings -o wide（节选）
NAME                        ROLE                  AGE   USERS   GROUPS                     SERVICEACCOUNTS
system:public-info-viewer   ClusterRole/...       40d           [system:authenticated system:unauthenticated]
（默认绑定与官方文档一致：未认证组仅可读非敏感公开信息）

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

核查命令：

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 安全标准对照说明。
示例输出（节选）
kubectl get namespace demo-namespace --show-labels
demo-namespace   Active   12d   kubernetes.io/metadata.name=demo-namespace,pod-security.kubernetes.io/enforce=baseline,pod-security.kubernetes.io/warn=restricted
（业务命名空间 enforce=baseline、warn=restricted；对照：默认 privileged 级别不产生任何限制）
kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml | grep admission
    - --enable-admission-plugins=NodeRestriction,AlwaysPullImages
（默认插件已含 PodSecurity，此处为额外启用的插件）

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

核查命令：

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 挂载清单截图、整改记录。
示例输出（节选）
kubectl get pods -A -o jsonpath=...（hostNetwork/hostPID/hostIPC，节选）
kube-system/kube-proxy                          true   false  false
kube-system/calico-node                         true   true   false
demo-namespace/demo-app-7f9c6b5d4-x2v8p         false  false  false
kubectl get pods -A -o jsonpath=...（privileged，节选）
kube-system/calico-node        true
demo-namespace/demo-web-67c9   false
（特权容器仅集中在 kube-system 网络组件，业务命名空间未见 hostPID/hostNetwork/privileged）

安全审计

对应控制点：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 个月留存证据、节点侧日志截图。

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

核查命令：

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 审计参数截图、策略文件全文截图、参数与策略一致性说明。
示例输出（节选）
kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml | grep audit
    - --audit-policy-file=/etc/kubernetes/audit-policy.yaml
    - --audit-log-path=/var/log/kubernetes/audit/audit.log
    - --audit-log-maxage=180
    - --audit-log-maxbackup=10
    - --audit-log-maxsize=100
grep -E "apiVersion|kind|level" /etc/kubernetes/audit-policy.yaml | head -n 6
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - "RequestReceived"
  - level: Metadata   # 兜底规则：全部请求记元数据
（secrets 等敏感资源取 Metadata 级别，鉴权失败与删除类取 Request 级别）

B. 审计事件样例

核查命令：

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 卷挂载截图、事件与操作时间对应说明。
示例输出（节选）
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"5f2a...","stage":"ResponseComplete",
 "requestURI":"/api/v1/namespaces/demo-namespace/secrets","verb":"create",
 "user":{"username":"demo-admin","groups":["demo-team","system:authenticated"]},
 "sourceIPs":["192.168.30.21"],"objectRef":{"resource":"secrets","namespace":"demo-namespace","name":"demo-db-credential"},
 "responseStatus":{"metadata":{},"code":201},"requestReceivedTimestamp":"2026-08-28T03:12:05.001Z",
 "stageTimestamp":"2026-08-28T03:12:05.018Z"}
（用户、动词、对象、来源 IP、结果五要素齐全，事件经采集器上送日志平台）

C. 集中化与节点侧日志

核查命令：

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 个月前记录检索截图。
示例输出（节选）
journalctl -u kubelet --no-pager | tail（节选）
Aug 28 03:00:02 demo-node1 kubelet[2150]: I0828 ... "Pod status updated" pod="demo-namespace/demo-app-7f9c6b5d4-x2v8p" status=Running
Aug 28 09:41:17 demo-node1 kubelet[2150]: E0828 ... "Failed to pull image" pod="demo-namespace/demo-web-67c9" err="pull access denied"
（节点侧日志经 journald 持久化并由采集器上送日志平台，平台留存 365 天）

入侵防范

对应控制点：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 证书认证配置截图、版本清单与支持窗口对照截图、漏洞扫描与整改记录、防火墙/安全组策略截图、宿主机防恶意代码软件截图。

A. kubelet 端口与匿名访问

核查命令：

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 配置截图、两条匿名访问实测回显截图、认证/授权配置截图。
示例输出（节选）
ss -lntp | grep -E "10250|10255"
LISTEN 0 1024 192.168.10.6:10250 users:(("kubelet",pid=2150,fd=7))
（10255 无监听）
grep -A 3 "authentication" /var/lib/kubelet/config.yaml
authentication:
  anonymous:
    enabled: false
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt
curl -sk https://192.168.10.6:10250/pods | head -c 200
Unauthorized
（匿名访问关闭，10255 只读端口未开放，授权模式 Webhook）

B. etcd 暴露面与证书认证

核查命令：

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 连接成功回显截图、无证书直连失败回显截图、网络隔离说明。
示例输出（节选）
ss -lntp | grep 2379
LISTEN 0 128 192.168.10.5:2379 users:(("etcd",pid=1876,fd=9))
grep -E "client-cert-auth|listen-client-urls" /etc/kubernetes/manifests/etcd.yaml
    - --listen-client-urls=https://127.0.0.1:2379,https://192.168.10.5:2379
    - --client-cert-auth=true
    - --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
ETCDCTL_API=3 etcdctl ... member list（节选）
4a1b..., started, demo-node1, https://192.168.10.5:2380, https://192.168.10.5:2379, false
（仅监听本机与管理网地址，客户端证书双向认证生效）

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

核查命令：

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 版本偏差在官方版本偏差政策允许范围内。
  • 预期证据：版本清单截图、官方支持窗口对照截图、漏洞扫描报告、升级工单/变更记录。
示例输出（节选）
kubectl version（节选）
Server Version: v1.30.4
kubectl get nodes -o jsonpath=...
demo-node1  v1.30.4
demo-node2  v1.30.4
demo-node3  v1.30.4
（v1.30 在官方维护的最近三个小版本窗口内，季度漏洞扫描与补丁记录在案）

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

核查命令：

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、镜像签名校验）作为补偿，业务镜像的恶意代码责任结合镜像扫描报告判定。
  • 预期证据：端口监听与端口表对照截图、防火墙/安全组策略截图、防恶意代码软件与病毒库截图、镜像扫描报告。
示例输出（节选）
ss -lntp | grep -E "6443|2379"（节选）
LISTEN 0 128 192.168.10.5:6443 users:(("kube-apiserver",pid=1702,fd=7))
LISTEN 0 128 192.168.10.5:2379 users:(("etcd",pid=1876,fd=9))
iptables -L INPUT -n -v（节选）
1  ACCEPT tcp -- * * 192.168.30.0/24  192.168.10.5  tcp dpt:6443
2  DROP  tcp -- * * 0.0.0.0/0       192.168.10.5  tcp dpt:6443
（6443 仅业务/运维网段可达，宿主机部署 EDR 且病毒库当日更新）

数据完整性

对应控制点：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 传输加密

核查命令：

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 可选）、架构说明。
示例输出（节选）
kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml | grep etcd-
    - --etcd-servers=https://127.0.0.1:2379,https://192.168.10.5:2379
    - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
    - --etcd-certfile=/etc/kubernetes/pki/etcd/server.crt
    - --etcd-keyfile=/etc/kubernetes/pki/etcd/server.key
（etcd 地址为 HTTPS 且 CA/证书/私钥三件套齐备，与 etcd 侧 client-cert-auth 对应）

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

核查命令：

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/签名策略截图、私有仓库材料、准入配置截图。
示例输出（节选）
kubectl get pods -A -o jsonpath=...（节选）
registry.demo.local/demo/app@sha256:9c7f1e2b...
registry.demo.local/demo/web:v2.3.1
（核心业务镜像以 digest 固定，其余镜像经内部仓库准入拉取；仓库启用签名校验并保留扫描报告）

数据保密性

对应控制点：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 最低版本参数截图。

A. etcd 静态加密配置

核查命令：

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 选型与官方推荐对照说明。
示例输出（节选）
kubectl -n kube-system get pod kube-apiserver-demo-node1 -o yaml | grep encryption
    - --encryption-provider-config=/etc/kubernetes/encryption-config.yaml
    - --encryption-provider-config-automatic-reload=true
grep -E "apiVersion|kind|providers|secretbox" /etc/kubernetes/encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
    providers:
      - secretbox:
（secretbox 为首位 provider，密钥文件权限 600 且仅 root 可读）

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

核查命令：

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 最低版本参数截图。
示例输出（节选）
kubectl -n demo-namespace get secret demo-db-credential -o jsonpath='{.type}'
Opaque
ETCDCTL_API=3 etcdctl ... get /registry/secrets/demo-namespace/demo-db-credential --print-value-only | head -c 60
k8s:enc:secretbox:v1:key1:<二进制密文…>
grep tls-min-version /etc/kubernetes/manifests/kube-apiserver.yaml
    - --tls-min-version=VersionTLS12
（etcd 落盘为 secretbox 密文，API Server 最低 TLS 1.2，kubectl 侧内容经 RBAC 控制访问）

备份恢复

对应控制点：GB/T 22239-2019 8.1.4.9 数据备份恢复 a)c)

判定要点：etcd 具备定期快照且快照文件可校验（snapshot status 通过）、编排与持久卷数据具备备份机制（Velero 等）或快照（VolumeSnapshot）、恢复经演练并有记录、控制面多节点冗余 → 符合；有备份无演练、或仅冗余无快照 → 部分符合；无任何备份与冗余措施 → 不符合（高风险）。

取证要求：快照文件清单与状态校验回显截图、备份策略/计划任务截图、Velero/快照资源清单截图、恢复演练记录、控制面节点冗余说明。

A. etcd 快照核验

核查命令：

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 校验回显截图、定时任务/备份平台策略截图、恢复演练记录。
示例输出（节选）
ls -l /var/backups/etcd/
-rw------- 1 root root 47M Aug 28 03:05 snapshot-demo-20260828.db
-rw------- 1 root root 45M Aug 27 03:05 snapshot-demo-20260827.db
etcdutl snapshot status /var/backups/etcd/snapshot-demo-20260828.db -w table
+----------+----------+------------+------------+
|   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| fe1e2c86 |   452817 |      15234 |       45 MB |
+----------+----------+------------+------------+
crontab -l | grep -i etcd
5 3 * * * /usr/local/bin/etcd-backup.sh（每日快照并同步异地存储，保留 30 份）

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

核查命令：

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 备份清单与明细截图、备份策略与周期截图、恢复演练记录、控制面配置备份说明。
示例输出（节选）
kubectl get volumesnapshots -A（节选）
NAMESPACE        NAME                        READYTOUSE   SOURCEPVC        RESTORESIZE
demo-namespace   demo-app-snap-20260828      true         demo-app-data    20Gi
velero backup get（节选）
NAME                    STATUS       ERRORS   WARNINGS   CREATED                     EXPIRES
demo-full-20260828      Completed    0        0          2026-08-28 03:00:05 +0800   26d
demo-full-20260827      Completed    0        0          2026-08-27 03:00:05 +0800   27d
（Velero 每日全量备份至对象存储，卷快照由 CSI 驱动产生，半年一次恢复演练）

剩余信息保护

对应控制点：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. 终态资源与存储残留

核查命令：

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 状态截图、垃圾回收与压缩策略说明、清理记录。
示例输出（节选）
kubectl get pvc -A（节选）
NAMESPACE        NAME                STATUS   VOLUME                                     CAPACITY
demo-namespace   demo-app-data       Bound    pvc-3f2a1b6c-...                           20Gi
demo-namespace   demo-test-old       Bound    pvc-8c1d9e2a-...                           5Gi
kubectl get pv | grep -i released
pvc-1a2b...  10Gi  RWO  Retain   Released  demo-namespace/demo-removed
（1 个 Released 卷按 Retain 保留，纳入季度清理计划）

B. 失效凭据与令牌清理

核查命令：

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 权限截图、清理制度与工单。
示例输出（节选）
kubectl get secrets -A | grep -i "service-account-token"
demo-namespace   legacy-deploy-token   kubernetes.io/service-account-token   3   39d
（存量 1 个手工创建的长期 token Secret：业务确认仍需使用，已收窄 RBAC 权限并纳入季度复核；其余均为 v1.24 后签发的短生命周期令牌）

个人信息保护

对应控制点：GB/T 22239-2019 8.1.4.11 个人信息保护 a)b)

判定要点：平台元数据与审计日志仅承载运维必需的用户名/UID/来源 IP 等字段且访问受 RBAC 控制、审计策略对敏感资源取 Metadata 级别避免记录业务数据体、日志外送前有脱敏与导出审批 → 符合；有访问控制但字段未最小化或导出无管控 → 部分符合；审计/配置/镜像中明文记录身份证号、手机号、令牌等且无访问控制 → 不符合（高风险）。

取证要求：审计策略级别配置截图、审计日志样例（脱敏）、日志平台访问与导出审批记录、元数据抽样截图、不涉及个人信息时的数据流说明。

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

核查命令：

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 个人信息保护控制点以实际处理个人信息为前提。
  • 预期证据：审计策略级别截图、脱敏日志样例截图、日志平台权限与导出审批记录、访谈记录。
示例输出（节选）
tail -n 1 /var/log/kubernetes/audit/audit.log（节选，已脱敏）
"verb":"get","user":{"username":"demo-admin",...},"sourceIPs":["192.168.30.21"],
"objectRef":{"resource":"secrets","namespace":"demo-namespace","name":"***"}
（secrets 类请求按策略记录 Metadata 级别，未包含请求/响应体；日志平台对 username 与 IP 做展示脱敏，导出需工单审批）

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

核查命令：

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、标签、注解等元数据中是否混入姓名、手机号、邮箱等个人信息或明文凭据（开发调试残留是常见形态）；镜像与环境变量中的个人信息残留结合镜像扫描报告与应用方说明判定。平台层未见此类承载、个人信息全部在容器内应用处理时，按不适用口径处理并留证。
  • 预期证据：元数据抽样截图（脱敏）、镜像扫描报告、应用方说明、整改记录。
示例输出（节选）
kubectl -n demo-namespace get configmap demo-app-config -o jsonpath='{.data}' | head -c 300
{"log.level":"info","feature.flags":"a,b","admin.contact":"***@demo.local"}
（抽样未见身份证号、手机号等个人信息；联系邮箱为运维公共邮箱，属平台元数据合理字段）

参考依据

关联文章