必须优先验证api server审计日志是否启用，若无--audit-policy-file和--audit-log-path参数则立即中止检查；其次确认rbac无cluster-admin等过度授权、podsecurity策略已强制enforce为restricted、etcd静态加密已配置，四者缺一不可。
在PHP框架已部署到Kubernetes集群的前提下，快速验证底层K8s安全配置是否满足生产环境基线要求，避免因API Server未启用审计、RBAC过度授权或Pod默认特权导致PHP应用被横向渗透。
检查API Server是否启用审计日志
这一步必须优先确认，否则后续所有操作行为都不可追溯。审计日志是定位PHP应用异常调用（如恶意Pod exec进容器、非预期ConfigMap读取）的唯一依据。
执行命令查看API Server启动参数：kubectl -n kube-system get pod kube-apiserver-$(hostname) -o yaml | grep -A 5 -B 5 "audit-policy-file"
若输出中无--audit-policy-file和--audit-log-path字段，说明审计功能完全关闭→立即停止其他检查，先联系集群管理员补全审计策略文件并重启kube-apiserver。
【audit-policy-file路径必须指向存在的YAML文件，且该文件需包含至少level: RequestResponse规则，否则仅记录Metadata级别日志，无法还原PHP应用发起的敏感API调用】
检查PHP应用所在命名空间的RBAC权限
PHP框架常依赖ServiceAccount调用Kubernetes API（如自动发现ConfigMap、调用Metrics API实现HPA），但过度授权会放大风险。
方法一：快速枚举该命名空间下所有角色绑定kubectl get rolebinding,clusterrolebinding -n <php-namespace> -o wide</php-namespace>
重点筛查是否绑定cluster-admin、admin或自定义ClusterRole中包含*/*资源和get/watch/list/create/update/delete全动词。
方法二：精准定位PHP应用使用的ServiceAccount权限
先查Deployment中指定的ServiceAccount：kubectl get deploy -n <php-namespace> -o jsonpath='{.items[0].spec.template.spec.serviceAccountName}'</php-namespace>
再查该SA绑定的所有Role/ClusterRole：kubectl get rolebinding,clusterrolebinding -n <php-namespace> -o json | jq '.items[] | select(.subjects[].name == "<sa-name>")'</sa-name></php-namespace>
若发现绑定对象含system:node或system:kube-scheduler等高危ClusterRole，【必须立即解绑，此类权限允许PHP代码直接操控节点调度行为】
检查Pod安全策略执行状态
第一步：确认集群是否启用PodSecurity Admission（K8s 1.25+默认启用）kubectl get apiservice v1.admissionregistration.k8s.io -o jsonpath='{.status.conditions[?(@.type=="Available")].status}'
返回True表示已就绪。
第二步：检查PHP命名空间的PodSecurity标签kubectl get namespace <php-namespace> -o jsonpath='{.metadata.annotations["pod-security.kubernetes.io/enforce"]}'</php-namespace>
第三步：若返回restricted，继续验证实际效果
创建测试Pod：kubectl run test-priv-pod --image=nginx:alpine --rm -it --restart=Never --overrides='{"spec":{"securityContext":{"privileged":true}}}' -n <php-namespace></php-namespace>
若命令卡住或报错admission webhook "pod-security-webhook" denied，说明策略生效；若Pod成功运行，则策略未生效或被豁免。
注意：不要在生产命名空间直接运行特权Pod测试，应在隔离测试命名空间复现。
检查etcd数据加密状态
PHP应用的Secret（如数据库密码、JWT密钥）最终以明文形式落盘到etcd，若etcd未启用静态加密，攻击者获取节点磁盘即可批量导出所有凭证。
执行命令检查etcd加密配置：kubectl -n kube-system get pod etcd-$(hostname) -o yaml | grep -A 3 "encryption-provider-config"
若无任何输出，说明etcd未配置加密→必须升级etcd配置并滚动重启etcd节点。此操作需严格按变更窗口执行，且提前备份etcd快照。
【未启用etcd加密的集群，所有Secret类资源均视为明文暴露，PHP框架中的DB_PASSWORD、REDIS_AUTH等字段已实质失效】
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
