一、核心安全原则在开展任何安全加固工作之前需要先确立三条贯穿全手册的基本原则。最小特权原则。无论是人类用户还是运行中的Pod只授予其完成本职工作所必需的最小权限集不多给任何额外权限。深度防御原则。不在单一层面寄托全部安全期望而是在网络、主机、容器、API服务器、数据存储等多个层面分别部署安全控制措施使单点失效不会导致整体失守。持续改进原则。安全不是一次性项目。需要定期审查配置、扫描漏洞、审计日志并根据新的威胁和业务变化持续优化安全策略。二、集群基础设施安全加固2.1 API服务器保护API服务器是整个集群的控制核心其安全性至关重要。在网络层面必须实施严格隔离。API服务器默认6443端口绝对禁止直接暴露在公共互联网访问应通过堡垒机、VPN或云厂商的私有网络进行。可使用--bind-address标志将监听IP限制在可信网段使用--secure-port可变更默认端口。在认证层面必须禁用匿名请求--anonymous-authfalse强制要求所有客户端使用TLS客户端证书、OpenID Connect或Webhook等强认证方式完成身份验证。客户端需在~/.kube/config中提供CA证书副本以验证API服务器证书的可信性。⚠️ 特别关注API服务器的匿名访问和弱认证配置是最常见的安全漏洞入口应在集群部署时即完成加固。2.2 etcd存储保护etcd存储着集群的所有数据包括Secret等敏感信息需要从三个维度进行保护。网络隔离方面仅允许API服务器和极少数备份或管理工具访问etcd的2379端口在网络层面限制对该端口的访问只允许特定可信IP地址段。双向TLS认证必须启用确保只有持有合法证书的客户端才能建立连接。etcd所信任的证书颁发机构应仅用于该服务不应与其他用途共享。静态数据加密是最关键的一项。必须为API服务器配置静态数据加密使Secret等敏感资源在写入etcd之前被加密存储。可考虑使用硬件安全模块在专用硬件中生成和管理加密密钥。⚠️ 特别关注etcd客户端证书只要被信任的CA签发即拥有对etcd的完全读写权限因此证书私钥的保护级别应与集群管理员权限等同。2.3 kubelet安全配置集群中每个节点上的kubelet也需要进行安全加固。首先关闭匿名访问配置--anonymous-authfalse同时确保未启用不作身份认证的只读kubelet端口。其次将鉴权模式设置为Webhook--authorization-modeWebhook使kubelet的授权决策交由API服务器统一处理。应使用RBAC等机制精细限制对Node API对象子资源的访问。再次确保kubelet的10250端口仅对可信网段开放避免被未授权方直接访问。应避免授予nodes/proxy的全局权限即使仅使用get操作因为该权限可访问kubelet API进而执行容器内命令。2.4 镜像供应链安全容器镜像的安全直接影响运行时安全。使用私有镜像仓库。将官方或可信镜像同步到企业私有镜像仓库严格限制镜像拉取权限仅允许已授权客户端拉取。镜像扫描必须集成到CI/CD流水线中阻断包含高危漏洞的镜像进入生产环境。同时应定期对运行环境中已部署的镜像进行漏洞扫描。部署时使用镜像的sha256摘要而非latest等标签确保引用的镜像内容不可变防止标签被意外覆盖导致引入未经审查的镜像版本。三、身份认证与访问控制3.1 用户身份管理生产环境强烈建议使用OpenID Connect或LDAP等外部身份源进行用户认证。这种方式便于集中管理用户生命周期员工离职或转岗时可立即撤销其所有集群访问权限。需要避免以下做法。不要使用静态令牌文件因为令牌以明文存储在控制平面磁盘上且修改任何凭据都需要重启API进程。不要使用X.509客户端证书进行用户认证因为证书无法独立撤销在过期之前一直有效且私钥无法设置密码保护。⚠️ 特别关注客户端证书一旦泄露攻击者可一直使用至证书过期期间无法吊销因此建议为证书配置较短的有效期。3.2 服务账号精细化ServiceAccount用于为Pod提供身份标识。创建专用服务账号。避免使用每个命名空间中默认的default服务账号应为每个工作负载或一组功能相近的Pod创建专用的ServiceAccount并遵循最小特权原则为其授权。禁止自动挂载令牌。除非Pod确实需要与Kubernetes API交互否则应在ServiceAccount或Pod中设置automountServiceAccountToken: false禁止自动挂载服务账号令牌。使用短期令牌。优先使用TokenRequest API获取短期且可自动轮换的令牌避免使用永不过期的Secret令牌因为静态长期凭证一旦泄露风险极高。3.3 RBAC权限最小化基于角色的访问控制是实现最小特权的关键工具以下几点需要特别注意。命名空间级别授权。权限应尽可能在命名空间级别授予使用Role和RoleBinding而非ClusterRole和ClusterRoleBinding。避免通配符。在定义规则时应避免使用*通配符授予对所有资源的访问权限。通配符不仅覆盖当前所有资源类型还会覆盖未来新增的任何资源类型。高危动词严格管控。严格限制对escalate、bind、impersonate等危险动词的授权。escalate权限允许用户创建比自身拥有更高权限的角色bind权限允许绑定尚不具备的角色impersonate权限允许伪装成其他用户获得其权限。避免cluster-admin滥用。日常操作严禁使用cluster-admin角色该角色应仅作为紧急情况下的例外机制。定期权限审查。每季度至少进行一次RBAC绑定审查清理冗余或过于宽松的权限条目。若攻击者创建与已删除用户同名的账号将自动继承该用户的所有权限因此需及时清理。⚠️ 特别关注对serviceaccounts/token拥有create权限的用户可以为任意ServiceAccount签发令牌等同于获得了该ServiceAccount的所有权限需极为谨慎授权。四、Pod工作负载安全加固4.1 强制执行Pod安全标准Pod安全性标准定义了三个策略级别。Privileged不受限。完全开放允许已知的特权提升仅用于系统级或基础设施级可信负载。Baseline基线。限制性最弱禁止已知的特权提升适用于大多数常见容器化应用。Restricted严格。限制性最强遵循当前保护Pod的最佳实践要求以非Root运行、禁止特权提升、限制Seccomp配置等。落地建议如下。使用Pod安全性准入控制器在所有命名空间中强制执行策略。优先采用Restricted策略无法满足时退而使用Baseline策略。为避免对现有工作负载造成破坏可先在warn或audit模式下运行观察并修复违规Pod后切换为enforce模式。命名空间标签配置示例pod-security.kubernetes.io/enforce: restricted— 强制应用Restricted策略pod-security.kubernetes.io/audit: baseline— 审计模式应用Baseline策略pod-security.kubernetes.io/warn: restricted— 警告模式应用Restricted策略4.2 安全上下文配置在Pod或容器的securityContext中应配置以下加固措施。Pod级别应设置runAsNonRoot: true确保容器不以Root身份运行指定一个非零的runAsUser和runAsGroup。可为持久卷配置fsGroup以设置补充组访问权限。容器级别以下每一项都应配置allowPrivilegeEscalation: false— 禁止通过SetUID或SetGID获得特权提升readOnlyRootFilesystem: true— 根文件系统设为只读privileged: false— 避免运行特权容器capabilities.drop: [ALL]— 删除所有Linux权能capabilities.add: [NET_BIND_SERVICE]— 仅添加业务所必需的具体权能seccompProfile.type: RuntimeDefault— 使用容器运行时的默认Seccomp配置文件⚠️ 特别关注特权容器会覆盖Seccomp、AppArmor和SELinux等所有加固约束应仅在绝对必要时使用并严格限制其部署范围。4.3 资源配额与限制ResourceQuota在命名空间级别限制CPU、内存、存储和API对象的总量防止单个租户或工作负载垄断集群资源。LimitRange为Pod和容器设置默认的CPU和内存请求值与限制值确保每个Pod都声明了资源需求避免调度决策缺乏依据。需要特别关注内存限制的配置。确保limits.memory不高于requests.memory避免内存限制设置过高导致节点内存耗尽时不可控地终止Pod。CPU限制的配置需谨慎可能影响自动扩缩或CPU利用率。4.4 网络隔离默认情况下Kubernetes集群中所有Pod可以互相通信存在安全风险。首先确认CNI插件支持NetworkPolicy例如Calico或Cilium。若不支持NetworkPolicy资源将被忽略。推荐在每个命名空间中实施默认拒绝策略。创建默认拒绝所有入站流量的策略同时创建默认拒绝所有出站流量的策略然后添加允许DNS查询的规则以保证服务发现功能正常。在此基础上按业务需求逐步添加白名单规则使用Pod选择器、命名空间标签或IP地址范围精细化控制通信。对namespaceSelector应避免使用空标签选择器防止意外允许跨命名空间流量。五、敏感数据与Secret管理5.1 启用静态加密默认情况下Secret对象以未加密的Base64编码形式存储在etcd中。Base64不是加密任何人都可以通过解码获得明文。必须为API服务器配置静态数据加密使Secret在写入etcd之前被加密读取时再解密。加密提供者可选用云厂商KMS服务或本地密钥管理方案。⚠️ 特别关注仅对etcd启用TLS加密传输是不够的静态加密必须单独配置两者相互独立。5.2 合理注入Secret优先使用卷挂载方式而非环境变量注入Secret。环境变量可能在应用崩溃转储、日志输出或调试信息中意外暴露Secret内容。卷挂载方式可配合emptyDir.medium: Memory将Secret存储在内存文件系统中进一步降低写入持久存储的风险。若Pod中有多个容器应将Secret仅挂载到确实需要访问该Secret的容器避免暴露给不需要的容器。应用程序读取Secret值后应采取保护措施。避免以明文记录到日志中禁止将Secret数据传输给不受信任的第三方。5.3 避免Secret清单泄露在YAML清单中定义的Secret数据仅以Base64编码没有额外的保密机制。共享此清单文件或提交到源代码仓库等于向所有能访问该仓库的人公开Secret内容。应避免将生产环境Secret清单入库。可评估使用Secret Store CSI Driver将密钥存储在外部KMS或Vault中。六、持续监控与审计6.1 审计日志开启审计功能。配置API服务器的审计策略记录所有或关键API请求。审计覆盖用户、应用以及控制平面本身产生的活动。将审计日志发送到统一的日志分析平台为安全分析和合规审计建立集中检索能力。基于审计日志配置告警规则。重点关注以下异常行为多次认证失败 — 可能正在遭受暴力破解攻击频繁权限拒绝HTTP 403— 可能权限配置错误或存在恶意探测创建特权Pod或修改敏感资源 — 可能存在提权企图同一用户并发读取大量Secret — 可能存在数据批量泄露6.2 定期安全巡检权限审查。每季度至少进行一次RBAC绑定审查检查是否存在冗余或过于宽松的条目。确认system:masters组成员是否合理。审查system:unauthenticated组的绑定在可能的情况下予以移除。镜像漏洞扫描。持续对运行环境中容器镜像进行漏洞扫描及时修补或替换存在高危漏洞的镜像。节点安全。确保节点操作系统补丁及时更新遵循CIS Kubernetes Benchmark等标准进行主机安全基线检查。Linux节点上可考虑启用AppArmor或SELinux提供额外的强制访问控制。七、落地优先级建议如果您的企业刚开始系统性地推进Kubernetes安全加固建议按照以下优先级逐步实施。第一优先级身份认证与访问控制对接OIDC或LDAP外部身份源严格配置RBAC最小权限禁用匿名访问和匿名认证为服务账号禁用不必要的令牌自动挂载第二优先级Pod工作负载安全启用Pod安全性准入控制器并应用Restricted策略为所有工作负载配置完整的securityContext设置ResourceQuota和LimitRange防止资源耗尽第三优先级数据加密与网络隔离为etcd配置静态数据加密启用NetworkPolicy实施网络白名单使用私有镜像仓库并集成镜像扫描第四优先级持续监控审计日志的采集与集中分析定期安全巡检机制的建立与执行异常行为告警规则的配置八、最后提醒安全检查清单本身不足以构建良好的安全态势真正的安全需要持续的关注和改进。上述措施需要根据企业具体的业务特性、合规要求和威胁模型不断调整与深化。安全与效率之间存在权衡每项措施的采用都应经过充分的价值评估。建议持续关注CNCF云原生安全白皮书和CIS Kubernetes Benchmark等行业标准保持安全实践的持续更新。欢迎在评论区聊聊你的实践✨你们在生产环境中最先落地的是哪一项安全措施呀是 RBAC 权限精细化、Pod 安全策略还是镜像供应链安全在推进 Kubernetes 安全加固的过程中又踩过哪些坑遇到过哪些意想不到的问题欢迎留言分享你的经验和教训大家一起避坑