容器安全最佳实践
容器安全最佳实践
Section titled “容器安全最佳实践”容器安全的重要性
Section titled “容器安全的重要性”随着云原生技术的快速发展,容器和 Kubernetes 已成为企业 IT 架构的核心组成部分。容器化带来了敏捷、弹性和高效的优势,但也引入了新的安全挑战。根据行业报告,截止 2025 年,超过 85% 的企业运行容器化应用,但同时,超过 75% 的安全事件源于配置不当、镜像漏洞和权限滥用等问题。因此,如何通过合理的配置来保障 K8s 安全和业务安全,变得至关重要。
K8s 安全面临的挑战
Section titled “K8s 安全面临的挑战”作为云原生时代的基础设施,与传统的云产品安全和主机安全相比,K8s 由于其架构的复杂性和高度开放等特性,在安全层面带来了一系列独特的差异和挑战。
1. 安全边界的变化与模糊
Section titled “1. 安全边界的变化与模糊”主机安全边界 vs K8s 集群安全边界
Section titled “主机安全边界 vs K8s 集群安全边界”- 传统的主机安全以物理/虚拟机为边界,K8s 则以集群、Node、Pod、容器为边界,安全边界不再是单一的主机,而是多层次、多维度的,安全管控更加复杂。
- 从资源隔离和安全隔离的层面上讲,Pod 和容器之间的隔离性弱于虚拟机,不同业务的 Pod 可能调度到同一台节点上,导致越权后攻击面增大。
K8s 控制面和数据面的边界模糊
Section titled “K8s 控制面和数据面的边界模糊”- 在部署层面上,K8s 的控制面和数据面并未完全区分开,除了 Master 外,集群中仍有大量的控制器、CNI、CSI 等系统控制面组件,以 Deployment 或 DaemonSet 的方式部署在集群中,和业务 Pod 混部,一旦由于业务 Pod 的漏洞导致越权访问,很可能通过这类系统组件进行进一步提权,导致权限放大。
- 在 API 层面上,传统服务的控制面 API 一般不对数据面暴露,但 K8s 的控制面 API 是对数据面暴露访问的,在集群内可直接访问,一旦由于权限配置不当,很可能导致攻击者越权接管整个集群,很大程度上增加了 K8s 的安全风险。
2. 权限和访问控制的复杂性
Section titled “2. 权限和访问控制的复杂性”双层权限体系带来的复杂性:云平台 + K8s 内部 RBAC
Section titled “双层权限体系带来的复杂性:云平台 + K8s 内部 RBAC”传统云产品的权限管理通常只需关注单一层级的访问控制(如 CAM 角色或资源组),而 K8s 的权限体系是双层的:
- 云基础设施层:例如 TKE 相关的云 API 权限、服务角色权限、CVM 权限、VPC 和安全组等云资源操作权限。
- K8s 集群内部层:通过 K8s RBAC(基于角色的访问控制)管理对 Pod、Service、Deployment 等资源的操作权限
管理员需要同时管理云平台权限(如”谁能创建 TKE 集群”)和 K8s 内部权限(如”谁能删除 Namespace”),两者可能因配置冲突导致安全漏洞。若云平台权限过松(如允许普通用户修改 EKS 集群配置),可能直接绕过 K8s RBAC 的保护。
不同角色、不同位置、不同场景带来的权限体系复杂性
Section titled “不同角色、不同位置、不同场景带来的权限体系复杂性”- 集群内程序(机器)访问 K8s —— 系统组件场景
- 集群外程序(机器)访问 K8s —— DevOps 场景
- 集群外人员操作 K8s —— 主动运维场景
- 集群内程序(机器)访问云上 API 场景
管理员需要根据不同场景,来选择最合适的认证授权方式,才能最大限度的保证集群的安全性。
3. 动态性和弹性带来的风险
Section titled “3. 动态性和弹性带来的风险”动态 IP 使得传统的基于 IP 的授权不再有效
Section titled “动态 IP 使得传统的基于 IP 的授权不再有效”传统的云主机和云产品一般生命周期较长,因此 IP 较为固定,通常采用安全组来基于静态 IP 配置安全策略。而在 K8s 场景下,Pod 生命周期相对较短,IP 不再固定,这种模式不再适用。
大规模场景下动态安全策略带来的性能问题
Section titled “大规模场景下动态安全策略带来的性能问题”K8s 的 NetworkPolicy 一般会通过 label 来匹配对象,通过 iptables 来实施安全策略的下发,在大规模场景下,随着 Pod 和 iptables 的增多,在控制面和数据面都可能会带来严重的性能问题。控制面会随着规则的增多导致策略下发和生效慢,严重时会导致网络不通或策略不生效,数据面则随着规则的增多导致转发性能受影响。
4. 生态开放性和供应链风险
Section titled “4. 生态开放性和供应链风险”- K8s 以其高度开放的特性和高度可扩展性著称,有大量的开源组件基于 K8s 构建,然而这些开源组件的质量层次不齐,可能在业务不知情的情况下带来安全风险。
第三方镜像的安全性和镜像仓库的安全性也至关重要
Section titled “第三方镜像的安全性和镜像仓库的安全性也至关重要”- 一旦业务使用的第三方镜像携带严重的 CVE 漏洞,则很可能被攻击者利用从而产生越权。
- 一旦业务的镜像仓库由于凭证泄露等方式被入侵,则攻击者很可能会通过供应链投毒的方式,覆盖业务镜像,从而达到攻击的目的。
5. 多层次和多维度的安全防护需求
Section titled “5. 多层次和多维度的安全防护需求”传统主机安全主要关注主机、网络、存储等基础设施层的安全。而 K8s 安全不仅需要覆盖基础设施,而且需要覆盖容器运行时、控制面安全、多租户安全、供应链安全、平台安全、数据安全等多个层面,防护面更广。
如何保障 K8s 安全
Section titled “如何保障 K8s 安全”上一个章节我们主要介绍了 K8s 安全的复杂性,以及相比于传统云产品安全所带来的独特挑战。对于集群管理员来说,最常见的问题就是由于配置不当从而造成安全风险。K8s 和云厂商本身提供了一系列的能力来应对上述安全风险和挑战,用户只有充分的了解这些能力和它们要解决的问题,才能更好的保障 K8s 集群的安全。
TKE 围绕上述核心挑战,结合了现网大规模客户的实际使用场景和运营经验,从以下几个层面,总结了一系列的最佳实践,来帮助用户提升 K8s 集群的安全性:
!!! tip “快速开始” 如果你希望快速了解如何强化 TKE 集群的安全性,推荐先阅读 强化集群安全性,该文档提供了全面的安全检查清单和配置示例。
1. 身份认证和访问管理
Section titled “1. 身份认证和访问管理”身份认证和访问管理主要围绕用户实际使用场景出发,介绍如何将腾讯云的账号和访问管理体系(CAM)与 K8s 的认证和访问管理体系(RBAC)相结合,实现凭证动态化,权限最小化。
详细可参考:TKE 身份认证和访问管理最佳实践
2. 网络安全
Section titled “2. 网络安全”网络安全主要围绕如何通过 VPC、子网、K8s Namespace、NetworkPolicy、安全组、ACL、通信加密等手段,实现不同业务、环境、租户之间的网络隔离,降低横向移动风险。通过 TKE 提供的 eNP 和 SGP 等能力,可以在满足灵活性的情况下,实现最低的性能损耗。
3. Pod 和运行时安全
Section titled “3. Pod 和运行时安全”Pod 和运行时安全主要围绕如何通过部署隔离、权限隔离和容器运行时隔离,来对抗 K8s 模糊的安全边界,增强不同业务之间的隔离性。如启用 Pod 安全策略(如 PodSecurityPolicy、Pod Security Admission)、安全上下文(SecurityContext)、非特权运行、安全容器(如 gVisor)等机制,限制容器的特权操作和主机资源访问。
4. 制品和镜像安全
Section titled “4. 制品和镜像安全”制品和镜像安全主要围绕镜像源可信化、镜像漏洞扫描、镜像签名与内容信任、最小化基础镜像等层面,结合 TCR 及容器安全提供的各种检测能力,来提升制品安全性。
5. 数据安全
Section titled “5. 数据安全”数据安全主要围绕敏感数据加密、密钥与凭证管理、备份与恢复等层面,来保障业务数据的安全性,避免数据泄露和丢失。
6. 策略安全
Section titled “6. 策略安全”策略安全主要围绕如何通过 TKE 提供的 OPA 等能力,建设客户自己的安全基线。通过策略安全机制,集群管理员可以对资源创建、变更、运行等各个环节进行统一、自动化的安全管控,防止因人为疏忽或恶意操作带来的安全风险。
7. 持续监控与响应
Section titled “7. 持续监控与响应”除了预防和拦截之外,安全事件的及时发现、响应和溯源也至关重要。通过容器安全提供的安全扫描、入侵检测等持续防护措施,可以帮助业务及时发现隐患,结合 TKE 的日志审计能力,可以更好的帮助业务定位攻击来源和影响范围。
K8s 安全是一个系统性工程,涉及权限、网络、运行时、供应链、数据、多租户、监控等多个层面。TKE 作为企业级 K8s 平台,结合腾讯云的安全能力和最佳实践,为用户提供了全方位的安全防护能力。建议用户在实际生产环境中,结合自身业务特点,充分利用 TKE 及云原生安全工具,持续完善安全体系,最大程度保障业务的稳定与安全。