边缘计算把Kubernetes的能力延伸到了工厂产线、连锁门店、港口码头这些远离机房的地方，但也把集群的安全边界彻底打散了。一台部署在便利店货架后面的边缘节点，攻击者可以拔网线、拆硬盘、伪造网络流量，这些在数据中心里几乎不用担心的问题，在边缘场景成了日常。传统的安全模型假设节点进入内网之后就是可信的，这个假设在边缘环境里完全不成立。零信任（Zero Trust）的核心原则可以概括成一句话：永不信任，始终验证。本文将围绕Kubernetes边缘节点的接入链路，从身份认证、传输加密、授权控制三个层面拆解零信任落地的具体做法。
一、传统边缘接入方式为什么撑不住零信任要求
先看目前最常见的几种边缘节点接入方案。第一种是VPN专线，边缘节点通过WireGuard或IPSec隧道连回数据中心，节点拿到内网IP后直接访问API Server。第二种是IP白名单加防火墙规则，只允许特定网段的节点连接6443端口。第三种是基于引导令牌（Bootstrap Token）的一次性认证，节点首次加入集群后长期持有证书。
这三种方案的问题在于信任建立之后就不再持续验证。VPN账号泄露、白名单网段被伪造源地址绕过、节点私钥被物理拷贝，任何一种情况发生时，集群都没有能力识别出一个已经变质的节点。尤其是引导令牌方式，令牌默认有效期较长，且缺乏设备指纹绑定，拿到令牌的任何机器都能伪装成合法节点加入集群。
零信任模型要求把信任的判定从一次性动作变成持续过程。具体到Kubernetes边缘场景，需要回答三个问题：这个节点的身份能否被密码学验证？这个设备的软件状态是否可信？它被授予的权限是否只够完成本职工作？后面的方案设计都会围绕这三个问题展开。
二、节点身份认证：从静态令牌走向双向mTLS与SPIFFE
Kubernetes API Server默认支持客户端证书认证，Node子系统的证书由集群CA签发。零信任的第一步是收紧证书的签发和轮转流程。kubelet的证书轮转特性（rotateCertificates）可以让节点证书自动更新，配合较短的证书有效期（例如24小时），即使私钥泄露，攻击窗口也被限制在极短时间内。需要在kubelet配置中显式开启：
apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration rotateCertificates: true serverTLSBootstrap: true # 证书轮转失败后 kubelet 退出，避免使用过期证书继续通信 rotateServerCertificates: true
更彻底的做法是引入SPIFFE（Secure Production Identity Framework For Everyone）标准。SPIFFE为每个工作负载或节点分配一个统一的身份标识SVID（SPIFFE Verifiable Identity Document），格式类似spiffe://cluster.local/node/edge-node-01。相比IP地址或主机名，SVID是密码学可验证的，天然适合零信任环境。SPIRE作为SPIFFE的实现，可以部署在边缘侧作为Agent，向中心端的SPIRE Server完成基于节点证明（Node Attestation）的身份注册。
节点证明是关键环节。SPIRE支持多种证明方式，比如基于TPM芯片的硬件证明、基于云厂商实例元数据的证明，以及基于X.509引导证书的证明。对于工厂里的工控机，推荐启用TPM证明，因为TPM密钥无法被软件导出，攻击者即使拆走硬盘也无法克隆节点身份。SPIRE的Agent配置示例如下：
agent {
server_address = "spire-server.trust-zone.svc"
server_port = "8081"
trust_domain = "cluster.local"
data_dir = "/data/spire"
log_level = "INFO"
}
plugins {
NodeAttestor "tpm" {
plugin_data {
# 要求设备持有指定EK证书链签发的TPM
ek_cert_intermediate_ca_path = "/etc/spire/tpm-ca.pem"
}
}
KeyStore "disk" {
plugin_data {
directory = "/data/spire/keys"
}
}
}
完成身份认证后，边缘节点与API Server、与KubeEdge或K3S的云端控制器之间的所有通信都应强制mTLS。mTLS不仅让服务端验证客户端，也让客户端验证服务端，防止中间人伪造云端控制面劫持边缘节点，这一点在边缘节点通过公网回连的场景尤其重要。
三、最小权限授权与准入控制的组合拳
身份可信不等于权限无限。零信任的第二支柱是最小权限原则（Least Privilege）。默认情况下Kubernetes内置的system:node角色权限相当宽泛，边缘节点应该通过NodeRestriction准入插件配合RBAC收紧。开启NodeRestriction后，kubelet只能操作自己名下的Pod和Node对象，无法读取其他节点的Secret或ConfigMap：
# kube-apiserver 启动参数 kube-apiserver \ --enable-admission-plugins=NodeRestriction,NodeAuthorization \ --authorization-mode=Node,RBAC
针对边缘节点还要额外考虑一类风险：节点上的容器镜像来源是否可信。镜像签名验证可以在准入层拦截未签名镜像。部署Kyverno或Sigstore的Policy Controller，强制要求边缘节点调度的镜像必须携带签名注解。同时结合Pod安全准入（Pod Security Admission），禁止边缘节点运行privileged特权容器，因为特权容器等同于把节点root权限交给了Pod。
网络层面，只依赖NetworkPolicy还不够，边缘节点到云端的访问应该经过一层代理网关，按身份动态放行。一个常见架构是在云端部署一个零信任访问代理（可基于开源的Pomerium或自研Envoy过滤器），边缘节点的所有请求先到达代理，代理校验SVID或客户端证书后再转发到目标服务。这样即使边缘内网被横向渗透，攻击者也无法直接触达API Server，因为缺少合法身份。下面是一个基于Envoy的mTLS校验过滤器配置片段：
listener_filters:
- name: envoy.filters.listener.tls_inspector
filter_chains:
- transport_socket:
name: envoy.transport_sockets.tls
typed_config:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
require_client_certificate: true
common_tls_context:
tls_certificates:
- certificate_chain:
filename: "/etc/envoy/certs/server.pem"
private_key:
filename: "/etc/envoy/certs/server-key.pem"
validation_context:
trusted_ca:
filename: "/etc/spire/trust-bundle.pem"
# 只接受 SPIFFE 格式的节点身份
match_typed_subject_alt_names:
- san_type: URI
matcher:
exact: "spiffe://cluster.local/node"
授权策略应该是显式拒绝优先。为边缘节点单独创建一个专属的ClusterRole，只开放Pod状态上报、Node心跳维护、镜像拉取凭证读取这几个必要动作，其余一律不授权。定期用kubectl auth can-i --as=system:node:edge-node-01审计节点的实际权限范围，防止权限随时间膨胀。
四、持续验证与可观测性：零信任不是一次性配置
零信任与传统方案最大的区别在于持续验证。身份和设备状态是动态的，昨天可信的节点今天可能被刷入恶意固件。落地持续验证需要两个机制：一是定期重新证明，SPIRE可以配置WorkloadAttestor定期刷新SVID，同时结合节点的运行时状态做条件判定；二是异常检测，将kubelet上报的指标、审计日志接入SIEM系统，节点通信频率突变、证书轮转失败、非常规时间段的API调用都应该触发告警甚至自动隔离。
自动隔离的实现可以借助Kubernetes的隔离能力。当监控系统判定某边缘节点可疑时，通过API将该节点标记为不可调度（cordon），并应用一个拒绝其所有流量的NetworkPolicy或直接吊销其SVID，SPIRE的条目注册机制支持即时撤销：
# 标记节点不可调度并驱逐工作负载 kubectl cordon edge-node-01 kubectl drain edge-node-01 --ignore-daemonsets --force # 吊销 SPIRE 中的节点身份条目 spire-server entry show -spiffeID spiffe://cluster.local/node/edge-node-01 spire-server entry delete -entryId <entry-id>
可观测性方面，建议为每个边缘节点的接入链路建立完整的审计档案：证书指纹、签发时间、最近一次轮转时间、TPM证明结果、授权策略版本。这些数据不仅是事后追责的依据，也是零信任模型中信任评分的输入源。一些团队会在此基础上引入设备信任评分，评分低于阈值的节点自动降级，只能访问只读接口，需要人工介入后才能恢复完整权限，这种渐进式信任在大量边缘节点的运维中非常实用。
最后要提醒一点常见的踩坑：证书轮转与SPIRE Agent的生命周期要绑定。如果kubelet证书已轮转但SPIRE的SVID未同步刷新，会出现节点身份不一致导致请求被代理拒绝的情况。建议把两者的刷新周期配置为同一数量级，并在节点启动脚本中加入身份自检步骤，确保上线前身份链路完整可用。零信任接入不是某个单一组件能完成的，它是认证、授权、网络代理、持续验证四个环节协同的结果，每一环都要经得起被攻破的假设检验。
Kubernetes零信任边缘计算修改时间：2026-09-14 00:49:06