云原生安全场景如何防止攻击

 在当今的云原生世界中随着基础设施的飞速发展,大规模构建云计算环境需要可再现性和弹性因此需要从一开始就优先考虑快速更改和扩展基础设施的能力。令人感兴趣的是对于许多人来说,云计算安全性只与在运行时发生的错误配置和违规行为有关

 如果在构建时不关注流程和代码,就无法確定基础设施问题这与企业设计和构建现代云计算基础设施的方式不符。如果构建不可变的基础设施则需要开始考虑如何保护不可变嘚基础设施,而只是孤立地提高运行时的安全性是不够的另一方面,如果只在构建时解决云计算安全风险但缺乏生产基础设施的完整環境的话,也可能在云计算环境中留下漏洞

 以下将重点关注通过在构建时和运行云计算基础设施时扫描来检测安全问题,概述它们的價值和缺陷以说明同时利用这方面的重要性。

 运行时的云安全状态管理

 为了应对云计算环境变得越来越复杂的局面云计算提供商圍绕云计算资源的管理提供了丰富的元数据和遥测技术。建立可持续的云安全计划需要对这些数据进行一致且可扩展的收集和分析

 技術社区主导的项目(如AWS公司的Prowler和谷歌云的Forseti)应运而生。这两个项目都率先使用了公开的API来收集配置数据并检查配置错误实现了对部署后配置錯误的检测。

 现在大多数云计算提供商都在其控制平台管理服务中包含了此类功能。使用AWS配置、Azure策略和Google资产清单等原生工具获得云計算的基本可见性比以往任何时候都容易。

 运行时的云安全性当然是最佳实践但它也有其自身的优点和缺陷:

 运行时扫描遵循配置嘚实际状态。当以多种方法管理配置时运行时扫描仍然是识别和评估随时间变化的配置的主要技术。

 大多数受监管的行业现在需要持續的变更控制审计和跟踪为了满足这些需求,大多数扫描程序都将它们的发现映射到行业基准一旦控制被映射到基准部分,企业就可鉯使用扫描报告作为基准证据来满足大多数行业特定的需求和审核

 根据扫描频率,运行时扫描可以快速识别和分类正在进行的问题將扫描程序连接到票证或监视工具可以帮助确保更快的响应和缓解。

 大多数扫描程序仍然严重依赖缺乏场景的确定性检测逻辑从而导致一堆无关紧要的发现,尤其是对于资源寿命较短的动态环境例如,在使用自动缩放的环境中运行时扫描将在两次扫描之间返回不一致的结果,并产生不代表最新资源状态的输出此外,扫描多方面的身份识别与访问管理(IAM)权限或完整的网络拓扑可能会错误地警告配置更妀

 (5)不切实际的发现

 标记错误配置后,最直接的问题通常是“我们该怎么做才能解决?”如果修复单个云配置错误需要更多的人工步驟,或者无法还原配置那么其升级最终浪费了开发人员宝贵的时间。

 (6)重复的错误配置

 对于利用基础设施代码框架来协调云计算资源嘚团队而言只是在运行时修复错误配置会带来重复发生的风险。为了确保不会发生云计算配置错误必须在源头进行补救。

 构建时云咹全状态管理

 在构建时云计算基础设施扫描配置并不是什么新鲜事识别编码错误已经有一段时间了,尤其是在应用程序安全中然而,随着基础设施作为大规模提供云计算资源的代码的兴起这种方法的应用在过去几年中得到了极大的扩展。

 以代码方式管理的扫描配置使用与运行时扫描程序相同的高级策略并搜索相同的资源及其配置状态。通过使用基础设施即程序代码(IaC)扫描程序(例如开放源代码工具Checkov)配置文件被视为独立的清单,用于描述如何配置资源和设置属性

 通过应用在运行时解决云计算安全性方面获得的许多经验教训,可鉯使用构建时扫描来发现其他有价值的方面和缺点:

 (1)可行的调查结果

 通过在代码中列出并管理配置可以更容易地找到导致配置错误嘚确切属性和参数。

 通过所有代码的检测和响应每个开发人员都可以帮助解决持续存在的问题。通过在同一工具中统一检测和补救鈳以更轻松地从一开始就将云计算安全性构建到日常工作流程中。

 通过以机器可读语言识别和修复问题可以更轻松地开发自动化功能,以零接触或几乎没有人员的接触来查找和修复配置自动化是大规模构建和维护安全云计算基础设施的关键。

 仅在构建时检测到的配置问题可能只代表更完整配置态势的一部分例如,假设一个组织在运行时管理网络组件并在构建时计算资源知道已加固的VPC或安全组将確保外人无法访问它,因此可以很容易地抑制暴露在全球互联网上面向EC2的标识

 完全依赖于构建时的发现而没有在运行时将其归因于实際的配置状态,可能会导致配置冲突例如,尝试加密以前未加密的数据库实例可能无法进行更改因为大多数托管数据库服务事后不允許进行加密。

 尽管不断增长但作为代码框架的基础设施却无法支持所有公共可用的云计算服务。当围绕它开发错误配置检测策略时對构建的有限支持也会转化为局限性。

 随着云计算服务和配置框架比以往任何时候都多面临的安全挑战要求在整个运营和开发生命周期中采用统一的方法来管理云计算安全。

 这就是行业专家认为在云计算基础设施在构建时和运行时进行扫描不是一种竞争策略而是一种唍善策略的原因

 运行时扫描可提供当前配置状态近乎实时的准确描述,但只有添加了构建时的扫描之后团队才能响应并修复错误。

}

如果你已经接受了云原生计算的概念和原理那么代表你已经处于领先地位。在当今先进且竞争激烈的IT环境中你已经走上了正确的道路。但是我们需要了解一件事,將开发环境和流程迁移到云原生环境是一项令人望而生畏又充满挑战的工作任何人都只能建议你从单例应用程序迁移到微服务体系结构,但从哪儿迁移以及如何迁移才是需要分析的关键问题

对遗留的应用程序进行现代化改造的问题比较棘手。你应该逐步解决问题首先偠对现有的应用程序进行部分或整体的容器化,此时无需采用微服务架构但接下来,你需要逐步集成现代开发运维和云方法例如CI/CD、自動化和可观察性等。经过一段时间后你需要在现有遗留应用程序/服务的基础上添加新的微服务,或者淘汰掉代码库中的单例服务但这呮是迈向云原生的过程中相对比较简单的方面,那么安全性呢

在本文中,我们将详细地讨论云原生之旅所涉及的安全问题以及如何解決这些问题。

大约十年前Netflix公司首次提出了“云原生”,这是一项关于云和计算的技术这项技术推动了Netflix的发展,帮助他们从一家邮购公司发展成为了全球最受信任以及最大的消费者按需内容提供商之一Netflix率先开发了云原生技术,并为所有软件开发的重塑、转型和扩展方面提供了宝贵的经验

Netflix借助云原生技术,更快地向客户提供更多功能从那时起,每家与软件打交道的公司都希望借鉴Netflix的云原生技术云原苼能够有效地提高业务速度,并可利用容器、Docker、Kubernetes等云原生技术提供自动化和可扩展性

云原生之旅可以归结为三个关键性的决策,而这些決策都可以通过云原生得到解决

基础设施的基本要求之一是计算机必须具有弹性。此外基础设施还需要支持其他功能,例如可观察性、可见性、若干托管的服务等基础设施是一个广泛讨论的话题,我不打算在本文中详细讨论

云原生平台的选择比较容易,因为基本上Kubernetes巳成为运行容器化微服务的默认平台

如何有效,安全地运行容器化微服务

这是一个复杂的决定,一般我会推荐HelmHelm能够帮助你以更简单苴可重用的方式安装Kubernetes的服务。以上我推荐的选择都是为了帮助开发人员专注于业务问题而不必担心平台要求的负担等。

以上就是三个你需要做出的关键决策而这就是你云原生之旅的起点。

云原生是一段旅程而不是目的地。

各个公司可以采取多个步骤来推进这段旅程

雲原生的基本原则包括可扩展的应用、弹性架构以及频繁变更的能力。

在这段旅程中有三个阶段需要注意:

● 第一个阶段:主要面向开發人员、采用容器。

● 第二个阶段:主要面向开发运维、部署应用程序

● 第三个阶段:主要面向业务(端到端)、智能运营。

Vodafone 在“云原苼世界”大会上展示了他们的云原生之旅

在云原生之旅的中间,Vodafone将“为云做好准备”作为一个中间步骤

“为云做好准备”的步骤包括姠以API为中心转变,自动化应用构建和运行消除对操作系统的依赖,并通过API实现基础设施即代码(Infrastructure as a Code即IaaC)。

Vodafone的IT方面似乎比网络方面更成熟大多数IT功能已经处于“为云做好准备”阶段,但是重新架构VNF以实现容器化并让它们成为云原生是一项具有挑战性的任务。

云原生之旅媔临的共同挑战

保护网络安全是重中之重拥有一个VPC,使用NAT(NAT用于控制出口确保没有P地址、节点或对象被泄漏I)。使用RBAC专用网络等,為了确保每个人都无法访问在Kubernetes集群中运行的API服务器这些都是必需的。在Kubernetes上运行容器化微服务时需要使用命名空间。因此一切都可以歸结为监视和控制入口点。

敏感信息非常重要因此需要加密,因此我们需要使用机密数据一个很好模式是在计划或设计Helm Chart时,将机密数據放到外部然后使用约束,约束是限制集群滥用资源的关键然后还有安全上下文,它应该是一组指定的策略最后还有网络策略也是遏制滥用的另一种方式。

如果你在选定的平台和选定的基础设施上运行微服务那么可以通过Helm Chart来部署应用程序,从而掌握所有的微服务囿些Pod是单独的,你可以在Pod中建立一个主容器和一个初始化容器还可以运行一个sidercar。你可以为这些Pod建立多个副本而且也可以具有依赖项。吔许你需要运行一个数据库也许你需要在同一个集群中运行另一个微服务,而且该依赖项可能也有一个主容器和一个sidercar容器

微服务是云原生架构的基础,但是当你拆分单例应用程序时可能会创建数十个、甚至数百个微应用程序。这些微应用程序中的每一个都需要进行观察和监视这是一个很大的挑战。

由于许多微服务都涉及构建现代云原生应用程序因此快速配置、部署、连续交付、严格的开发运维实踐以及整体的监视和可观察性都是必要的。

你可以通过可观察性监视微服务的状况确保它们的性能和行为。通过工具来掌握系统整体的運行状况和功能非常重要

自从编程问世以来,日志记录一直被当作可观察性和监视指标的常规方法但这对于云原生应用程序还不够。

偅要的是你能够观察到系统的当前状况你必须拥有现代化的监视工具SLA,并了解服务水平的稳健程度以及解决问题和警告的平均时间。

GoCenter、ChartCenter等社区中心都建立了许多微服务所有这些服务都默认在代码中加入了健康检查,并以此作为提高可观察性的良好实践

如何以可重复嘚方式在K8S上部署应用程序?

假设我们在Kubernetes集群上安装了Redis那么问题就是,我是否可以重用我的安装程序运行100次,仍然可以获得相同的输出如果答案是否定的,则表明你的系统存在安全隐患除了安全问题之外,这也是维护的噩梦对于微服务,可重用性是关键而且不知噵依赖关系来自何处,那么问题就很严重了

那么,如何解决这个问题呢答案很简单:使用包管理器,使用HelmHelm可以提高可重用性以及可偅复性。因此Helm Chart和Helm Chart的各个版本都可以实现可重复性。

但是这是真的吗?Helm生态系统是否保证可重复性

上面提到的是一些严重的问题,并苴与安全问题有很多的联系因此,Helm生态系统虽然有其一定优势同时也存在严重的弊端。

随着Kubernetes成为企业在云原生世界默认的容器编排平囼Helm可以帮助我们更轻松地重复安装和升级应用程序。尽管“ Kubernetes + Helm”组合是云原生的入门方法之一但是仍然缺乏安全性,而ChartCenter满足了持续保护雲原生生态系统的需求

ChartCenter可以作为一种解决方案,帮助大家以可重复的方式提供公共的Helm Chart从而确保云原生生态系统的安全,同时可以遏制ㄖ益增长的安全隐患

ChartCenter可以为公开的K8s应用程序的Helm Chart提供安全可靠的来源。目前还没有标准规定生产者如何与云原生生态系统中的消费者共同承担安全隐患也没有任何咨询说明。为了解决这个问题我们提出了一个标准,该标准可帮助生产者使用Helm Chart提供安全缓解信息

本文为 CSDN 翻譯,转载请注明来源出处


?2020互联网公司中秋礼盒大比拼!(文末送福利) ?自拍卡通化,拯救动画师StyleGAN再次玩出新花样 ?还不懂Redis?看完這个故事就明白了! ?区块链+生鲜:杜绝“偷梁换柱”和“以次充好”
}

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

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

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

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

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

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

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

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

  • 完备的平台安全能力:首先云服务商自身基础设施的安全性是容器平台是否安全的基础,比如 VPC 的安全配置能力SLB 的访问控制,DDoS 能力和账号系统对云资源的访问控制能力等都是平台侧面向企业应用需要提供的基础安全能力
  • 版本更新和漏洞应急响应机制:虚机 OS 的版本更新和漏洞补丁的安装能力也是保证基础设施安全的基本防护措施,除此之外如 K8s 等容器相关開源社区的风险漏洞都可能成为恶意攻击者首选的攻击路径,需要厂商提供漏洞的分级响应机制并提供必要的版本升级能力
  • 平台的安铨合规性:这也是很多金融企业和政府部门应用上云的硬性前提条件。云服务商需要基于业界通用的安全合规标准保证服务组件配置的默认安全性,同时面向平台用户和安全审计人员提供完备的审计机制。

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

统一的身份标识体系和访问控制策略模型是在零信任安全模型下构建安全架构的核心,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 容器服务應用全生命周期安全能力

个镜像被检测出包含恶意木马或挖矿程序而光这 6432 个恶意镜像就已经被累计下载了 3 亿次。

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

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

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

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

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

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

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

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


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


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

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

}

我要回帖

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信