云原生时代下,容器安全的“四个挑战”和“两个关键”

Posted 阿里巴巴云原生

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了云原生时代下,容器安全的“四个挑战”和“两个关键”相关的知识,希望对你有一定的参考价值。

作者 | 匡大虎


云原生时代下,容器安全的“四个挑战”和“两个关键”

云原生进程中的容器安全挑战


云原生的火热带来了企业基础设施和应用架构等技术层面的革新,在云原生的大势所趋下,越来越多的企业选择拥抱云原生,在 CNCF 2020 年度的调研报告中,已经有83% 的组织在生产环境中选择 Kubernetes,容器已经成为应用交付的标准,也是云原生时代计算资源和配套设施的交付单元。显然,容器已经成为应用交付的标准,也是云原生时代计算资源和配套设施的交付单元。

然而,由于在隔离和安全性方面存在的天然缺陷,安全一直是企业进行容器改造化进程中关注的核心问题之一。来到云原生时代,企业又将面临哪些容器安全新挑战?


  • 缺少体系化的容器安全能力建设:传统的企业应用安全模型通常基于内部架构不同的信任域来划分对应的安全边界,在信任域内的东西向服务交互被认为是安全的。而上云后企业应用需要在 IDC 和云上部署和交互,在物理安全边界消失后,如何在零信任的网络安全模型下构建企业级容器安全体系是云服务商需要解决的重要问题。
 
  • 更多的攻击面:基于容器技术的应用部署依赖 Linux 内核 namespaces 和 cgroups 等特性,从攻击者的角度出发,可以利用内核系统漏洞,容器运行时组件和容器应用部署配置等多个维度发起针对性的逃逸和越权攻击。K8s、Docker、Istio 等开源社区近年来也相继爆出不少的高危漏洞,这都给攻击者提供了可乘之机。
 
  • 缺少应用侧全生命周期的安全防护手段:容器技术在为企业应用架构提供了弹性、敏捷和动态可扩展等特性的同时,也改变了应用的部署模式。首先应用自身的生命周期被大幅缩短,一个容器应用的生命周期通常是分钟级;与此同时,随着存储网络和异构资源利用率等基础设施能力上的提升,容器应用的部署密度也越来越高,传统的面向虚机维度的安全防护策略和监控告警手段已经无法适应容器技术的需求。
 
  • 缺少对云上安全责任共担模型的理解:企业应用上云后的安全需要遵循责任共担模型,在企业应用架构云原生话的转型过程中,需要企业应用管理者和安全运维人员理解企业自身和云服务商之前的责任边界。这个过程中也需要云服务商面向企业应用侧输出更全面的容器安全最佳实践并提升安全能力的易用性,降低使用门槛。

云原生时代下,容器安全的“四个挑战”和“两个关键”

构建容器安全体系的基本原则


为了应对上述企业应用在容器化进程中的安全挑战,云服务商和企业应用安全管理运维人员需要携手共建容器应用安全体系:

云原生时代下,容器安全的“四个挑战”和“两个关键”

图 1 - ACK 容器服务安全责任共担模型

1. 云服务供给侧


对于云服务商,首先需要依托于云平台自身的安全能力,构建安全稳定的容器基础设施平台,并且面向容器应用从构建,部署到运行时刻的全生命周期构建对应的安全防护手段。整个安全体系的构建需要遵循如下基本原则:

1)保证容器管控平台基础设施层的默认安全


容器平台基础设施层承载了企业应用的管控服务,是保障业务应用正常运行的关键,容器平台的安全性是云服务商应该格外关注的。

  • 完备的平台安全能力:首先云服务商自身基础设施的安全性是容器平台是否安全的基础,比如 VPC 的安全配置能力,SLB 的访问控制,DDoS 能力和账号系统对云资源的访问控制能力等都是平台侧面向企业应用需要提供的基础安全能力。

 

  • 版本更新和漏洞应急响应机制:虚机 OS 的版本更新和漏洞补丁的安装能力也是保证基础设施安全的基本防护措施,除此之外如 K8s 等容器相关开源社区的风险漏洞,都可能成为恶意攻击者首选的攻击路径,需要厂商提供漏洞的分级响应机制并提供必要的版本升级能力。

 

  • 平台的安全合规性:这也是很多金融企业和政府部门应用上云的硬性前提条件。云服务商需要基于业界通用的安全合规标准,保证服务组件配置的默认安全性,同时面向平台用户和安全审计人员,提供完备的审计机制。


2)面向容器应用侧提供纵深防御能力


云服务商不仅要在自身管控侧建立完善的安全武装,同时也需要面向业务应用负载,提供适合云原生场景下容器应用的安全防护手段,帮助终端用户在应用生命周期各阶段都能有对应的安全治理方案。由于云原生具有动态弹性的基础设施,分布式的应用架构和创新的应用交付运维方式等特点,这就要求云服务商能够结合自身平台的基础安全能力,将云原生能力特性赋能于传统的安全模型中,构建面向云原生的新安全体系架构。

2. 企业安全侧


对于企业的安全管理和运维人员来说,首先需要理解云上安全的责任共担模型边界,究竟企业自身需要承担起哪些安全责任。云原生微服务架构下企业应用在 IDC 和云上进行部署和交互,传统的网络安全边界已经不复存在,企业应用侧的网络安全架构需要遵循零信任安全模型,基于认证和授权重构访问控制的信任基础。对于企业安全管理人员来说可以参考关注如下方向加固企业应用生命周期中的生产安全:

  • 保证应用制品的供应链安全

云原生的发展使得越来越多的大规模容器应用开始在企业生产环境上部署,也大大丰富了云原生应用制品的多样性,像容器镜像和 helm charts 都是常见的制品格式。对于企业来说制品供应链环节的安全性是企业应用生产安全的源头,一方面需要在应用构建阶段保证制品的安全性;另一方面需要在制品入库,分发和部署时刻建立对应的访问控制,安全扫描、审计和准入校验机制,保证制品源头的安全性。

  • 权限配置和凭证下发遵循权限最小化原则

基于统一的身份标识体系进行认证授权是在零信任安全模型下构建访问控制能力的基础。对于企业安全管理人员来说,需要利用云服务商提供的访问控制能力,结合企业内部的权限账号体系,严格遵循权限最小化原则配置对云上资源和容器侧应用资源的访问控制策略;另外严格控制资源访问凭证的下发,对于可能造成越权攻击行为的已下发凭证要及时吊销。另外要避免容器应用模板配置如特权容器这样的过大权限,确保最小化攻击面。

  • 关注应用数据和应用运行时刻安全

应用的成功部署上线并不意味着安全工作的结束。除了配置完备的资源请求审计外,安全管理运维人员还需要利用厂商提供的运行时刻监控告警和事件通知等机制,保持对容器应用运行时安全的关注,及时发现安全攻击事件和可能的安全隐患。对于企业应用自身依赖的敏感数据(比如数据库密码,应用证书私钥等)需要根据应用数据的安防等级采用对应的密钥加密机制,利用云上的密钥管理方案和落盘加密,机密计算等能力,保证数据在传输和落盘链路上的数据安全性。

  • 及时修复安全漏洞和进行版本更新

无论是虚机系统,容器镜像或是容器平台自身的安全漏洞,都有可能被恶意攻击者利用成为入侵应用内部的跳板,企业安全管理运维人员需要根据云服务商推荐的指导方案进行安全漏洞的修复和版本更新(比如 K8s 集群版本,应用镜像版本等)。此外企业要负责内部员工的安全培训工作,居安思危,提升安全防护意识也是企业安全生产的基础要务。

云原生时代下,容器安全的“四个挑战”和“两个关键”

端到端的云原生容器安全架构


阿里云 ACK 容器服务面向广大的企业级客户,构建了完整的容器安全体系,提供了端到端的应用安全能力。在今年 Forrester IaaS 安全评测中,阿里云容器安全能力与谷歌并列满分,领先其他厂商。下图为阿里云容器服务的安全体系架构图:

云原生时代下,容器安全的“四个挑战”和“两个关键”

图 2 - ACK 容器服务安全体系架构图

首先整个容器安全体系依托于阿里云强大的平台安全能力,包括物理/硬件/虚拟化以及云产品安全能力,构建了夯实的平台安全底座。

在云平台安全层之上是容器基础设施安全层,容器基础设施承载了企业容器应用的管控能力,其默认安全性是应用能够稳定运行的重要基础。首先面向集群 host 节点 OS 镜像本身阿里云操作系统团队做了很多安全加固相关工作, 不仅是阿里云官方操作系统镜像,也是 ACK 的首选默认系统镜像。Alibaba Cloud Linux 2 在 2019 年 8 月 16 日正式通过了 CIS 组织的全部认证流程并发布对应的。ACK 正在支持对基于 Alibaba Cloud Linux 操作系统的集群进行 CIS 安全加固来满足简单、快捷、稳定、安全的使用需求。除 CIS 合规外,2021 年 1 月,ACK 已经正式支持对基于 Alibaba Cloud Linux 操作系统的集群进行


在容器管控侧,阿里云容器服务基于 CIS Kubernetes 等业界安全标准基线对容器管控面组件配置进行默认的安全加固,同时遵循权限最小化原则收敛管控面系统组件和集群节点的默认权限,最小化攻击面。三月,阿里云容器服务提交的 CIS Kubernetes benchmark for ACK 正式通过 CIS 社区组织的认证审核,成为国内首家发布 CIS Kubernetes 国际的云服务商


统一的身份标识体系和访问控制策略模型是在零信任安全模型下构建安全架构的核心,ACK 管控侧和阿里云 RAM 账号系统打通,提供了基于统一身份模型和集群证书访问凭证的自动化运维体系,同时面对用户凭证泄露的风险,创新的提出了用户凭证吊销的方案,帮助企业安全管理人员及时吊销可能泄露的集群访问凭证,避免越权访问攻击事件。

针对密钥管理、访问控制、日志审计这些企业应用交互访问链路上关键的安全要素,ACK 容器服务也提供了对应的平台侧安全能力:

  • 访问控制:ACK 基于 K8s RBAC 策略模型提供集群内应用资源的 ,在保证非主账号或集群创建者默认无权限的安全前提下,集群管理员可以通过控制台或 OpenAPI 的方式对指定的子账号或 RAM 角色进行集群和账号维度的批量 RBAC 授权,ACK 面向企业常见授权场景,提供了四种预置的权限模板,进一步降低了用户对 RBAC 及 K8s 资源模型的学习成本。对于应用容器中通常依赖的集群访问凭证 serviceaccount,ACK 集群支持开启针对 serviceaccount 的 ,支持对 sa token 配置绑定 audience 身份,并且支持过期时间的设置,进一步提升了应用对管控面 apiserver 的访问控制能力。
 
  • 密钥管理:针对企业客户对数据安全自主性和合规性的要求,ACK Pro 集群支持对 K8s Secret 的,同时支持使用 BYOK 的,保证企业核心数据安心上云;同时 ACK 集群支持将用户托管在阿里云 KMS 凭据管家中的敏感信息到应用集群中,用户在 K8s 应用中直接挂载凭据同步的指定 secret 实例即可,进一步避免了对应用敏感信息的硬编码问题。

 
  • 日志审计:ACK 除了支持 K8s 集群 ,controlplane  等基本的管控面日志采集外,还支持对 的日志审计和基于 NPD 插件的 。以上日志审计能力均对接了阿里云 SLS 日志服务,通过 SLS 服务提供的快速检索、日志分析和丰富的 dashboard 展示能力,大大降低了对容器应用开发运维和安全审计的难度。
 
面向容器应用层在供应链和运行时刻的安全挑战,阿里云从容器应用的构建、部署到运行全生命周期,提供全方位覆盖的安全能力:

云原生时代下,容器安全的“四个挑战”和“两个关键”

图 3 - ACK 容器服务应用全生命周期安全能力

  • 应用构建阶段

据 Prevasio 对于托管在 Docker Hub 上 400 万个容器镜像的,有 51% 的镜像存在高危漏洞;另外有 6432 个镜像被检测出包含恶意木马或挖矿程序,而光这 6432 个恶意镜像就已经被累计下载了 3 亿次。


如何应对这些潜伏于镜像制品中的安全挑战,一方面要求企业应用开发者在构建应用镜像时使用可信的基础镜像,规范化镜像构建流程, 保证镜像最小化;另一方面阿里云 ACR 容器镜像服务针对镜像构建流程中的安全风险,提供了仓库权限的访问控制,操作审计和镜像安全扫描等基础能力。其中镜像安全扫描是用户能够主动发现安全漏洞的基础手段,提供了不同版本的镜像漏洞库,在支持镜像深度扫描的同时具备漏洞库的实时更新能力,满足企业安全合规需求。在阿里云容器镜像服务企业版中还可以通过实例,将安全扫描和分发流程自由组合并内置到自动化任务中并且自动拦截包含漏洞的镜像,确保分发到仓库中镜像的安全性。


在镜像构建环节,除了及时发现镜像漏洞,如何在保证镜像在分发和部署时刻不被恶意篡改也是重要的安全防护手段,这就需要镜像的完整性校验。在阿里云容器服务企业版实例中,企业安全管理人员可以用指定的 KMS 密钥自动加签推送到仓库中的镜像。


  • 应用部署时刻

K8s 原生的 admission 准入机制为应用部署时刻提供了天然的校验机制。

滥用特权容器,敏感目录挂载,以 root 用户启动容器,这些常见的应用模板配置都很可能成为容器逃逸攻击的跳板。K8s 原生的 PSP 模型通过策略定义的方式约束应用容器运行时刻的安全行为。ACK 容器服务提供面向集群的功能,帮助企业安全运维人员根据不同的安全需求定制化 PSP 策略实例,同时绑定到指定的 ServiceAccount 上,对 PSP 特性的一键式开关也面向用户屏蔽了其复杂的配置门槛。此外,ACK 容器服务还支持 gatekeeper 组件的安装管理,用户可以基于 OPA 策略引擎更为丰富的场景下定制安全策略。


针对应用镜像在部署时刻的安全校验需求,谷歌在 18 年率先提出了 的产品化解决方案。ACK 容器服务也在去年初正式落地了应用部署时刻的镜像签名和验签能力。通过安装定制化的 kritis 组件,企业安全运维人员可以通过定制化的验签策略保证应用部署镜像的安全性,防止被篡改的恶意镜像部署到企业生产环境中。


云原生时代下,容器安全的“四个挑战”和“两个关键”

图 4 -  一致性安全策略管理

  • 应用运行时刻

企业应用的稳定运行离不开运行时刻的安全防护手段。ACK 容器服务和云安全中心团队合作,面向容器内部入侵,容器逃逸,病毒和恶意程序,异常网络连接等常见的运行时刻攻击行为进行 ,同时云安全中心还提供了针对告警事件的溯源和攻击分析能力。与此同时,ACK 容器服务基于业界安全基线和最佳实践,面向集群内运行应用提供了一键化的免费 能力,通过巡检任务及时暴露运行中容器应用在健康检查/资源限制/网络安全参数/安全参数等配置上不符合基线要求的危险配置,并提示用户修复建议,避免可能发生的攻击。

对于安全隔离程度要求较高的企业客户可以选择使用,安全沙箱容器基于轻量虚拟化技术实现,应用运行在独立的内核中,具备更好的安全隔离能力,适用于不可信应用隔离、故障隔离、性能隔离、多用户间负载隔离等多种场景。


对于金融支付,区块链等对数据计算过程中的完全性,完整性和机密性有强安全诉求的场景,可以选择部署使用,其中机密计算基于 Intel SGX 技术,支持将重要的数据和代码防止在一个特殊的可信执行加密环境(Trusted Execution Environment,TEE)中,而不会暴露给系统其他部分。其他应用、Bios、OS、Kernel、管理员、运维人员、云服务商、甚至除了 CPU 以外的其他硬件均无法访问机密计算平台数据,极大减少敏感数据的泄露风险。


云原生时代下,容器安全的“四个挑战”和“两个关键”

图 5 - 容器应用安全配置巡检

图 6 - 容器应用运行时刻安全监控

安全是企业上云的首要关切


安全是企业上云的首要关切。随着云原生对计算基础设施和企业应用架构的重定义,容器作为云的新界面,也将紧跟云原生的发展大潮,向更加安全、可信的方向发展。未来,阿里云容器服务将始终以“让企业放心上云,安心用云”为目标,在容器安全领域保持世界级的竞争力,在不断夯实自身基础设施安全的基础上,为客户的应用安全保驾护航。

参考资料



以上是关于云原生时代下,容器安全的“四个挑战”和“两个关键”的主要内容,如果未能解决你的问题,请参考以下文章

云原生时代,如何“玩转”容器安全?

云原生时代,开发者如何构筑容器安全?

快进键启动,一文带你了解云原生时代容器安全

云原生时代,如何确保容器的全生命周期安全?

云原生场景下的容器网络隔离技术

云原生在京东丨云原生时代下的监控:如何基于云原生进行指标采集?