全解容器的威胁检测

译者 | 涂承烨

审校 | 孙淑娟

保护容器化云原生应用程序威胁的要点

引言：随着容器应用的指数级增长，对于团队来说，确保适当的安全和威胁管理基础设施和实践变得比以往任何时候都重要。本Refcard对容器化环境的威胁检测进行了全面的研究，跨越了几个重点领域，如常见的云安全架构和Kubernetes加固指南。Refcard的核心是容器威胁检测的基础，包括资源限制、静态图像漏洞扫描、配置验证等概念。

1 简介

如今，容器化解决方案已成为云原生应用程序开发的事实标准。Docker、containerd、CRI-O和Kubernetes等工具在容器操作系统领域处于领先地位。数以百万计的开发和架构团队选择基于容器的解决方案来帮助构建他们的产品，杰出的云提供商提供了大量基于Kubernetes、Docker和其他容器编排平台的服务。

​随着容器采用的增加，安全和威胁管理比以往任何时候都更加关键。根据​​云原生计算基金会(CNCF)​​和国家安全局(NSA)/CISA指南：

• 发现大多数安全问题和威胁是因为​​56%的开发人员目前甚至没有扫描他们的容器！​​​
• 高德纳公司（Gartner）预计，到2023年，​​超过70%的公司将运行容器化应用程序。​​
• ​​红帽公司（Red Hat）2022年的一份报告显示​​，至少59%的Kubernetes安全问题与错误配置有关。

本Refcard将讨论容器化环境的关键安全和威胁检​测主题，包括：

• 介绍Docker、containerd和CRI-O等知名的容器编排平台及其相应的安全挑战
• 云原生安全性和合规性标准概述
• 威胁检测工具选择标准简介
• 容器威胁检测的要点，包括OWASP和Kubernetes安全指南
• 基于Azure、AWS和谷歌云的安全云架构示例

2 云原生安全方法概述

容器的云原生安全表现为四层安全边界（也称为4Cs）。这四层由代码、容器、集群和云组成。请参阅下面图1所示的4Cs。

图1:云原生安全的4Cs（云、集群、容器、代码）

代码

如图1所示，代码是最里面的一层，因为不仅要在代码中加强安全性，而且还要在云、集群和容器层中加强安全性。然而，代码不应该包含漏洞的后门，例如：

• 所有通信都应该通过TLS或mTLS进行
• 扫描依赖项并为代码提供静态分析
• 限制对所有常见端口的访问

容器

容器及其容器环境是云原生安全解决方案的基本组成部分。现在，应用程序不仅基于Docker，还基于containerd，CRI-O和其他类似的平台。有几种常见的安全规则可以应用于容器平台：

• 扫描容器的漏洞，并使用安全扫描工具
• 使用最小特权原则
• 容器运行时隔离用户
• 禁用root权限
• 引入资源限制

集群

容器编排器对安全性至关重要，因为它们管理所有应用程序容器和服务。Kubernetes是一个广泛使用的容器编制平台，它的漏洞受到一长串安全准则的约束，具体如下：

• ​RBAC和身份验证策略
• ​​应用程序机密（Secrets）管理​​
• ​​网络策略​​
• ​​TLS接入​​
• ​​Pod安全标准​​

云和基础设施

所有知名的云提供商都有安全指南和资源来保护应用程序集群。例如，Azure拥有强大的平台，如​​Sentinel​​和​​Defender For Cloud​​，它们为基础设施内的威胁检测提供逻辑。AWS的安全中心（Security Hub）是一种云安全管理服务，为AWS中的资源提供自动化安全验证。所有安全验证和检查都基于​​AWS基础安全最佳实践标准​​。

最后，谷歌云将安全威胁检测作为安全指挥中心的一部分。安全指挥中心是一个集中式的漏洞和威胁报告服务。它不仅包含威胁检测，还包含漏洞扫描选项。

图2：谷歌云安全命令中心

此外，开源和第三方云安全工具是可以考虑的强大选项，特别是在处理多云或混合云环境时。除了云安全，还要关注基础设施。如果使用Kubernetes，那么需要关注这些关键方面，比如：

• 访问Kube控制面板、节点或公共网络，特别是集群网络
• 为您的Kubernetes云提供商设置权限策略
• 采用​​最小特权原则​​
• 限制对etcd集群的访问，并通过TLS提供加密

当我们在下一节中了解云和基础设施安全时，会介绍更多的内容。

3 常用云安全架构

云基础设施是云原生应用程序的基本组成部分。在本节中，让我们探索一些提供全栈安全和威胁检测选项的主要云提供商。

AWS安全中心

​​AWS安全中心​​（AWS Security Hub）​是一个安全服务，它包含聚合、优先级排序和管理来自不同AWS服务的警报的选项。AWS安全中心可用于：

• Amazon S3桶
• 包含敏感数据的S3桶
• Amazon机器镜像(AMIs)
• AWS服务帐户
• Amazon EC2实例

此外，AWS安全中心通过自动化遥测修复和自定义操作(如电子邮件、短信甚至票务系统)来帮助实现自动化。AWS的最大优势是其对AWS区域内所有AWS账户的统一视图。

让我们通过AWS安全中心的检测系统来了解一个简单的AWS体系结构：

图3：AWS安全中心检测系统

上面的体系结构展示了AWS Security Hub（AWS安全中心）与Cloud Watch的集成。Cloud Watch规则触发事件，然后与Lambda函数集成。因此，一个特定的函数将处理AWS安全中心的事件。

AWS安全中心的创建和配置可以通过以下Terraform模块轻松实现自动化：

module "security_hub" {
    source        = "clouddrove/security-hub/aws"
    version       = "1.0.1"
    name          = "security-hub"
    security_hub_enabled = true

    #member account add
    enable_member_account = true
    member_account_id     = "123344847783"
    member_mail_id        = "example@mail.com"

    #standards 
    enabled_standards = [
    "standards/aws-foundational-security-best-practices/v/1.0.0",
    "ruleset/cis-aws-foundations-benchmark/v/1.2.0"
    ]
    #products
    enabled_products = [
    "product/aws/guardduty",
    "product/aws/inspector",
    "product/aws/macie"
    ]
    }

通过此模块，开发人员可以配置他们的成员帐户，实现规则集（如AWS - foundations -security-best-practices），并启用AWS产品。

用于容器的Azure Defender

​​用于容器的Azure Defender ​​是一个复杂的云原生安全服务。它包含容器监视、容器注册指导服务和AKS集群安全工具集。Azure Defender包含AKS安全加固功能。它允许将Defender代理直接设置到工作节点和控制面板，以便可以运行安全和威胁检测。

Azure Defender有一个关于威胁和安全漏洞的大型数据库。因此，Azure Defender将UI仪表板集成到Azure Portal中。在仪表板中，可以监视集群安全问题并纠正安全检查。要查看它，请访问​​Azure Defender文档。​​

当使用Azure Defender保护容器时，需使用代理的自动配置功能。为此，请在​​自动配置窗口​​中启用日志分析和漏洞评估扩展。

参考下面图4中Azure Defender的云部署架构。它通过基于​​eBPF​​技术的Defender配置文件进行部署。

图4：用于AKS集群的Azure Defender

该架构包括以下组件：

• DeamonSet（azuredefender-collector-ds-*, azuredefender-publisher-ds-*）是一组容器，用于收集集群环境的安全事件和遥测信息
• 部署（azuredefender-publisher-ds-*）应用程序，将收集到的数据发布到Defender的后端

使用Bicep模板为容器部署Defender：

targetScope = 'subscription'

var enableSecurityCenterFor = [
  'KubernetesService'
]

resource securityCenterPricing 'Microsoft.Security/pricings@2018-06-01' = [for name in enableSecurityCenterFor: {
  name: name
  properties: {
    pricingTier: 'Standard'
  }
}]

如上所示，Defender仍然被命名为安全中心。该模板非常简单，包含enableSecurityCenterFor部分。此部分包含将为其启用Defender的服务和securityCenterPricing部分。本节是Defender资源定义。

谷歌云AppArmor

最后但并非最不重要的是​​AppArmor​​-一个基于Linux内核安全性的安全模块。它基于安全配置文件限制在操作系统中运行的进程。通过安全配置文件，可以限制网络通信和活动、文件和存储。

对于Docker容器，可以使用默认的安全配置文件，并使用以下命令运行默认的Docker配置文件：

docker run --rm -it debian:jessie bash -i

发生读取时，这段代码将会限制对/proc/sysrq-trigger的访问。

使用下面的示例代码创建自己的安全配置文件：

cat > /etc/apparmor.d/no_raw_net <<EOF
#include <tunables/global>

profile no-ping flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>

  network inet tcp,
  network inet udp,
  network inet icmp, 

  deny network raw,
  deny network packet,
  file,
  mount,
}
EOF

此代码块限制对原始网络和分组网络的访问，但允许访问tcp、udp和icmp协议。

了解Azure、AWS和谷歌云提供的服务和功能很重要，因为它们允许我们构建高效、安全的容器化架构。

4 关于容器安全和威胁检测

所有的容器引擎都基于容器运行时引擎(CREs)。Docker是使用最广泛的CREs之一。然而，就安全性和Kubernetes-ready解决方案而言，Docker可能并不总是一个好的选择。还有其他选择，如容器或CRI-O。让我们快速看看这些选项。

容器（Containerd）

由于Docker是一个集成的工具，包含CLI、存储管理、复杂的网络、权限逻辑等，这些工具为Kubernetes中的漏洞攻击创造了巨大的开销和攻击面。考虑到这些问题，Docker将容器运行时提取到一个名为​​containerd​​的独立项目中。Containerd比Docker小得多，提供了用于管理图像传输逻辑的低级存储。containerd是CNCF的一部分。

CRI-O

​​CRI- O​​比containerd更深入，提供原生和轻量级的CRI。CRI-O不包含运行在Kubernetes中的任何额外的层。Kubelet直接与CRI-O运行时对话，以提取图像。请参见下面图5中的Docker层、容器层和CRI-O层：

图5：Docker层、容器层和CRI-O层

Docker、容器和CRI-O的安全方面

当涉及Docker、容器和CRI-O时，许多针对容器化环境的攻击和威胁都是基于相同的场景。例如：

• 提高CPU、RAM和磁盘使用率以攻击相邻容器
• 使用容器的root权限来公开主机网络，从而应用特权标志
• 在镜像或Kubernetes配置中硬编码机密（Secrets）
• ​​Linux内核漏洞​​
• 使用恶意或虚假的镜像，包含所谓的中间人攻击

由于Docker是具有多层的整体架构，因此容易受到上述所有场景的影响。例如：

•  ​​CVE-2020-8554​​-此漏洞允许攻击者通过创建ClusterIPs服务来访问集群。
• ​​Siloscape​​-Windows容器中的恶意软件。Silocape为整个Kubernetes集群创建了一个后门，包括敏感数据和CPU、GPU、存储资源。
• ​​CVE-2018-15664​​-以root权限访问Docker系统。

容器（Containerd）是一个更轻量级引擎。它不包含来自Docker的很多层。但是，它具有诸如audit_write、mknod、net_raw和sys_chroot等Linux特性。容器（Containerd）为主机网络容器提供了一个通往攻击面的后门，如​​中毒镜像​​或​​容器逃逸​​。

CRI-O不包含Docker这样的层，因为开发团队排除了所有不必要的提供了后门的Linux特性。然而，CRI-O也包含一些可能导致cgroup​​内存不足（OOM）​​情况的漏洞，这将导致容器和​​镜像没有TLS连接​​。

记住：威胁可以在​​CVE报告​​中查看。

5 容器威胁检测的要点

团队可以通过以下核心概念减轻或完全消除威胁和安全漏洞。

Docker网络

Docker的网络是Docker基础设施的一个复杂部分，了解它是如何工作的至关重要。了解​​Docker网络驱动程序​​是什么很重要，例如：

• ​​网桥（Bridge）​​
• ​​主机（Host）​​
• ​​覆盖网络/叠加网络（Overlay）​​（译者注：overlay(又叫叠加网络、覆盖网络)简单理解就是把一个逻辑网络建立在一个实体网络之上。其在大体框架上对基础网络不进行大规模修改就能实现应用在网络上的承载，并能与其他网络业务分离，通过控制协议对边缘的网络设备进行网络构建和扩展是SD-WAN以及数据中心等解决方案使用的核心组网技术。）

默认情况下，一个容器网络栈不能访问另一个容器。但是，如果将网桥或主机配置为接受来自任何其他容器或外部网络的流量，则可能为攻击创建一个潜在的安全后门。你也可以在​​Docker Daemon​​中使用set flag - icc=false来禁用容器间通信。

设定资源限制

为Docker容器设置​​内存和CPU限制​​非常重要，因为Docker是一个默认情况下不提供此选项的容器。这是一种防止DoS攻击的有效方法。例如，可以设置内存限制，以防止容器消耗所有内存。这同样适用于CPU限制。此外，还有一个选项可以在Kubernetes级别上设置资源限制-这将在下面的Kubernetes加固指南一节中详细介绍。

避免容器镜像中的敏感数据

这一原则对于将所有敏感数据移出容器非常重要。你可以使用不同的选项来管理你的机密信息和其他敏感数据：

• ​​Docker secrets​​允许你在镜像外部存储机密。
• 如果你在Kubernetes中运行Docker容器，请使用​​机密（Secrets）​​存储您的密码、证书或任何其他敏感数据。
• 对敏感数据使用特定于云的存储-例如，​​Azure密钥库​​或​​AWS机密管理器​​。

漏洞和威胁检测工具

漏洞扫描工具是检测可能包含安全缺陷的镜像的重要组成部分。此外,你也可以适当选择工具集成到CI / CD的过程。第三方供应商和一些常见的开源工具提供了这种功能。这些开源工具的一些例子可以在“关于容器安全和威胁检测”一节中找到。

容器注册

为了保护镜像，创建一个额外的安全层，并使用来自受保护的注册表的镜像。下面是一些开源注册平台的例子：

​​Harbor​​-一个具有集成漏洞扫描功能的开源注册表，它基于应用于Docker构件的安全策略上。

​​Quay ​​-一个扫描镜像漏洞的开源镜像注册表。在RedHat的支持下，Quay还提供了一个独立的镜像存储库，允许你在组织内部安装和使用它。下面，我们将深入研究它如何扫描容器中的漏洞。

最小特权原则

这个原则意味着你不应该使用管理员（admin）用户来操作容器。相反，你应该创建具有管理员权限且只能操作此特定容器的用户。群组那里还可以再添加用户。请阅读​​Docker引擎安全文档​​。下面是如何创建用户和组的示例：

RUN groupadd -r postgres && useradd --no-log-init -r -g postgres postgres
USER postgres

此外，在创建用户和组的同时，请确保使用官方验证和签名的镜像。要查找和检查镜像，使用Docker信任检查。请在下面的“容器的威胁检测工具选择标准”一节中查找更多选项和工具。

Linux安全模块

为了加强安全性，请使用默认的Linux安全配置文件，不要禁用默认配置文件。对于Docker，你可以使用​​AppArmor​​或​​Seccomp​​。Kubernetes中的安全上下文规则也可以用allowPrivilegeEscalation来设置，该选项拥有控制容器的权限。此外，readOnlyRootFilesystem标志将容器根文件系统设置为只读模式。

静态镜像漏洞扫描

现在，我们已经知道了威胁检测工具是如何协同工作的，以及我们可以使用的策略，让我们定义一下静态图像漏洞扫描、机密扫描和配置验证的含义。静态安全漏洞扫描基于OCI (​​Open Container Initiative​​)格式。它根据众所周知的威胁和漏洞信息源对镜像进行验证和索引，如​​CVE Tracker​​、​​Red Hat安全数据​​和​​Debian安全漏洞跟踪器​​。

静态安全漏洞扫描机制可用于扫描多个源，如：

• 容器的镜像
• 文件系统和存储
• Kubernetes集群

静态镜像漏洞扫描还可以扫描错误配置、机密、软件依赖关系，并生成软件材料清单(​​Software Bill of Materials​​, SBOM)。SBOM是应用程序中开源、第三方工具和组件的组合，其中包含所有组件的许可信息。该信息对于快速识别安全风险非常重要。

下面，我们列出了一系列开源工具，涵盖了上面解释的逻辑。这只是可以使用的众多工具中的一小部分：

• ​​Clair ​​-一个安全漏洞扫描工具，具有用于开发集成目的的API。它还可以创建您自己的divers来扩展和定制Clair功能。Clair有几个​​Indexer​​、​​match​​、​​notify​​或combo模型。
•  ​​Trivy ​​-基于CVE威胁数据库的安全容器扫描程序。Trivy可以安装在你的PC上或Kubernetes节点上，使用npm, apt-get, brew和其他包管理器，比如：

1. apt-get install trivy  
2. yum install trivy
3. brew install aquasecurity/trivy/trivy

使用如下命令扫描图像：

$ trivy image app-backend:1.9-test

静态图像漏洞扫描的另一个关键是安全内容自动化协议(SCAP)。SCAP为基于Linux的基础设施定义安全合规性检查。​​OpenSCAP​​是一种工具，包括复杂的安全审计选项。它允许您扫描、编辑和导出​​SCAP文档​​，包括以下组件和工具：

• OpenSCAP Base -用于漏洞和配置扫描
• oscap-docker-用于合规扫描
• SCAP工作台-一个图形实用工具，用于典型的OpenSCAP任务的执行

下面是一个关于如何运行SCAP内容验证过程的示例：

oscap ds sds-validate scap-ds.xml

配置验证

静态镜像验证是威胁检测过程中的重要组成部分。然而，静态镜像扫描无法检测到YAML和JSON配置中的错误配置，并且可能导致复杂YAML配置中的中断。因此，要实现一种简单且自动化的方法，就需要像Kubeval这样的配置验证和扫描工具。我们可以引入配置验证，它可以解决静态配置的问题并简化自动化过程。

作为一个例子，我们将合并​​Kubeval​​，这是一个用于验证一个或多个Kubernetes配置文件的开源工具，经常在本地作为开发工作流的一部分和/或在CI/CD管道中使用。

运行验证，请使用下面的例子：

$ kubeval my-invalid-rc.yaml
WARN - fixtures/my-invalid-rc.yaml contains an invalid ReplicationController - spec.replicas: Invalid type. Expected: [integer,null], given: string
$ echo $?
1

机密（Secrets）扫描

机密（Secrets）扫描的主要目标是查看容器镜像、作为代码的基础设施文件、JSON日志文件等，以获得硬编码的和默认的秘密、密码、AWS访问id、AWS秘密访问密钥、谷歌OAuth密钥、SSH密钥、令牌等。

管理控制台和传感器代理

管理控制台是一种UI工具，用于构建安全基础设施概述，并提供漏洞和威胁报告。另一方面，传感器代理是一种扫描集群节点并收集安全遥测数据的工具。因此，传感器代理向管理控制台报告遥测。

例如，在AKS集群中安装传感器代理，需要遵循以下原则：

helm repo add deepfence https://deepfence-helm-charts.s3.amazonaws.com/threatmapper
helm show readme deepfence/deepfence-agent
helm show values deepfence/deepfence-agent

# helm v2
helm install deepfence/deepfence-agent \
    --name=deepfence-agent \
    --set managementConsoleUrl=x.x.x.x \
 --set deepfenceKey=C8TtyEtNB0gBo1wGhpeAZICNSAaGWw71BSdS2kLELY0

例如，在AKS集群中安装传感器代理，需要遵循以下原则：

helm repo add deepfence

​​https://deepfence-helm-charts.s3.amazonaws.com/threatmapper​​

helm install deepfence-console deepfence/deepfence-console

完成安装需两个操作：

• 从https://deepfence-helm-charts.s3.amazonaws.com/threatmapper下载Helm包
• 将Helm包直接安装到集群名称空间

这两个命令都非常简单，可以很容易地集成到IaC进程中。

6 Kubernetes加固指南

因为Kubernetes是最流行的编排平台，它需要经常进行安全调整。因此，美国国家安全局制定了​​K8加固指南​​。让我们根据国家安全局的强化指南来探索最常见的安全规则。

组网与网络策略

理解Kubernetes网络模型是如何工作的，对于在pods之间设置正确的网络通信，假装创建开放端口或直接访问节点至关重要。​​网络策略​​可以帮助组织这种通信。

确保Pod的进出流量

在保护Pod的入口和出口流量时，拒绝所有流量，然后逐个打开端口是很有帮助的。使用像Istio这样的服务网格（service mesh）也很有帮助，因为它添加了额外的服务层，自动化流量，并有助于监控。然而，在使用服务网格（Service Mesh）时要小心，因为它可能会增加更多的复杂性。

强认证和授权策略

• 加强传输层安全-传输层安全(TLS)应该用于Kubernetes集群服务之间的通信。
• 采用​​RBAC​​和最小特权原则。
• 限制对Kubelet的访问-启用使用该工具的身份验证和授权；只有管理员才能访问Kubelet。

使用日志审计

启用Kubernetes​​控制面板审计​​，以便向安全团队提供完整的信息。通常，这可以通过将日志转发到监视平台来实现。

验证和检查错误配置

要检查错误配置，可以采用自动化方法和配置扫描工具。可用CNCF项目​​Open Policy Agent​​创建安全策略，以防止创建错误配置。

例如，拒绝运行带有最新标签的容器：

package K ubernetes

import data.kubernetes
import data.lib as l

check03 := “K8S_03”

exception[rules] {
  make_exception(check03)
  rules = [“usage_of_latest_tag”]
}

deny_usage_of_latest_tag[msg] {
   ubernetes.containers[container]
  [image_name, “latest”] =  ubernetes.split_image(container.image)
  msg =  ubern(“%s: %s in the %s %s has an image, %s, using the latest tag. More info: %s”, [check03, container.name,  ubernetes.kind, image_name,  ubernetes.name, l.get_url(check03)])
}

更多的策略示例可以在​​Open Policy Agent policies​​中找到。

入侵检测系统与安全信息系统的实现

入侵检测系统是Kubernetes安全系统的重要组成部分。这些系统检查主机的行为是否有可疑活动和/或异常流量，并向管理员发出警报。

7 容器威胁检测工具选择标准

工具和平台是威胁检测基础的基本组成部分。有许多原生云提供商和开源工具包含威胁检测选项，包括以下服务：

• 静态镜像漏洞扫描
• 配置验证
• 机密（Secrets）扫描

问题是如何为你的架构选择合适的安全工具。让我们回顾一下选择合适的威胁检测工具的一些要求和策略：

让我们看一下下面的本地混合场景示例，在该场景中，我们使用开源工具和服务的组合构建模型架构。

威胁检测架构示例

作为使用开源安全工具的一个例子，我们将从Kubernetes集群开始。可以使用云提供商（或内部环境）进行部署。我们的示例架构包含以下开源平台：

​​Cadvisor​​-用于检测漏洞。

​​Grafana​​-通过导入所有组件来构建和配置仪表板和警报。

Prometheus-一个功能强大的开源选项，用于监控CPU、GPU、内存、图像和其他指标。

​​Kube-bench​​-检测Kubernetes集群的威胁和安全问题。它的安全检查基于CIS Kubernetes基准。

图6：威胁检测架构示例

要配置kube-bench，请使用YAML文件。例如,下面列出的YAML文件。它用于针对单个pod运行验证过程：

---
apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench
spec:
  template:
    metadata:
      labels:
        app: kube-bench
    spec:
      hostPID: true
      containers:
        - name: kube-bench
          image: docker.io/aquasec/kube-bench:v0.6.8
          command: ["kube-bench"]
          volumeMounts:
            - name: var-lib-etcd
              mountPath: /var/lib/etcd
              readOnly: true
            - name: var-lib-kubelet
              mountPath: /var/lib/kubelet
              readOnly: true
            - name: var-lib-kube-scheduler
              mountPath: /var/lib/kube-scheduler
              readOnly: true
            - name: usr-bin
              mountPath: /usr/local/mount-from-host/bin
              readOnly: true
            - name: etc-cni-netd
              mountPath: /etc/cni/net.d/
              readOnly: true
            - name: opt-cni-bin
              mountPath: /opt/cni/bin/
              readOnly: true
…
      restartPolicy: Never
      volumes:
        - name: var-lib-etcd
          hostPath:
            path: "/var/lib/etcd"
        - name: var-lib-kubelet
          hostPath:
            path: "/var/lib/kubelet"
…

让我们将这个文档内容保存到文件job.ymal中，然后使用apply命令运行：$ kubectl apply -f job.yaml

​​你可以在这里找到完整的版本。​​

8 结论

在本Refcard中，我们介绍了容器化云原生应用程序的威胁和漏洞检测机制的完整指南。从云原生环境的安全基线到Kubernetes的加固指南，这个Refcard提供了开始为云原生应用程序构建安全容器化架构所需的一切。

译者介绍

涂承烨，51CTO社区编辑，信息系统项目管理师、信息系统监理师、PMP，某省综合性评标专家，拥有15年的开发经验。对项目管理、前后端开发、微服务、架构设计、物联网、大数据等较为关注。

原文标题：​​Essentials to Securing Threats for Containerized Cloud-Native Applications​​，作者：Boris Zaikin