今天，云原生技术不仅为企业带来了快速交付的优势，也带来了新的安全需求和挑战。一方面，新技术（容器、编排、DevOps、微服务）的引入带来了新的安全问题，比如镜像的供应链问题、容器的逃逸问题、集群的横向移动问题，以及微服务的边界问题。引入新的安全保护方式；另一方面，随着云原生持续开发/集成开发模式的转变，传统安全已经不能适应新的开发节奏和安全需求。长期跟踪容器安全研究，结合各种资料，本文着重整理分析容器发展、容器镜像安全、K8S发展的技术趋势，分享给业界安全同仁，以投稿到云原生安全的发展。力量。1.容器生态发展的八个洞见与传统部署相比，安全专家和管理员需要在容器化环境中保护越来越复杂的组件，涉及容器和底层基础设施，安全需要融入开发流水线，以便有序确保所有组件从初始开发阶段到其生命周期结束都受到保护。洞察1：超过一半的组织运行超过250个容器，6%管理超过5,000个容器（如图1所示）。这表明越来越多的工作负载正在从传统架构转移到容器中。图1运行容器数洞察2：2020年每台主机上的容器中位数同比增长33%，2021年同比增长12%，达到46个（如图2所示）).许多组织都受益于硬件资源利用率的提高。图2每台主机的容器数量中位数洞察3：大约44%的容器存活时间不到五分钟（如图3所示），许多容器只需要足够长的时间来执行一个功能，几秒钟可能看起来很短，但是对于某些过程来说已经足够了。这表明容器的短暂性仍然是该技术的独特优势之一，但也带来了新的挑战，包括监控、安全性和合规性的新问题。图3容器生命周期洞察4：在容器运行时使用方面，Docker采用率占46%，首次低于50%，但Docker仍然是组织中使用最多的容器运行时（如图4所示）。图4ContainerRuntimeInsight5：Quay在容器注册中心的使用率上首次超过Docker，占客户采用率的26%（如图5所示）。图5容器镜像仓库洞察6：在资源使用限制方面，60%的容器没有定义CPU限制，51%的容器没有定义内存限制。即使在CPU密集型集群中，平均也有34%的CPU内核未被使用（如图6所示）。图6容器容量规划洞察7：在开源软件的使用中，在基于容器的应用开发中，使用前12名的开源技术（如图7所示），前三名分别是NGINX、GO、JMX.图7容器开源软件洞察8：容器化服务不断完善（如图8），服务周期保持相对稳定，其中31%的服务周期在2周以上。图8容器化服务周期2.容器镜像安全格局的八个洞察随着组织将更多的容器工作负载转移到生产中，我们看到需要将安全性和合规性集成到DevOps工作流中。容器镜像在容器安全中起着至关重要的作用。从镜像创建的任何容器都继承了它的所有特征，包括安全漏洞、错误配置，甚至恶意软件。见解1：76%的映像最终以root身份运行（如图9所示）。图9以根身份运行的容器洞察2：公共镜像注册表越来越受信任，从2020年的47%增加到2021年的61%（如图10所示）。图10镜像仓库拉取（公共仓库vs私有仓库）洞察3：RHEL是迄今为止最流行的基础镜像，占使用的基础镜像的36%，只有25%的人使用Alpine（如图11所示）.可以通过使用像Alpine这样的瘦基础镜像来减少容器的攻击面。图11BasicImageOSInsight4：镜像生命周期数据反映了代码发布之间的时间变化（如图12所示），大约一半的容器镜像在一周或更短时间内被替换。图12ContainerImageLifecycleInsight5：在容器工作负载中，在62%的容器中检测到shell，38%是使用敏感挂载点启动的容器（如图13所示），这意味着容器可以更改主机上的重要文件系统。图13容器运行时安全警报洞察6：52%的图像在运行时扫描，42%最初在CI/CD管道中扫描（如图14所示）。青藤建议所有容器在镜像制作、分发和运行阶段都需要不断地重新扫描，以发现任何新披露的漏洞。图14扫描图像的位置Insight7：在生产环境中，85%的运行图像包含至少一个可修补的漏洞。此外，75%的图像包含“高”或“严重”可修补漏洞（如图15所示）。图15RuntimepatchablevulnerabilitiesInsight8:在关注的警报中，Kubernetes.node.ready仍然是最常用的，其次是CPU使用率和正常运行时间指标（如图16所示）。图16Top10告警3.K8S安全发展八大洞察Kubernetes在组织中的使用越来越成熟。它是一个复杂的平台，需要大量的配置和管理。为了保证Kubernetes工作负载的安全，需要通过实施安全措施来解决关键的架构漏洞和平台依赖性问题。Pod是Kubernetes中最小的部署单元，由一个或多个容器组成。Pod通常是网络攻击者利用容器时的初始执行环境。鉴于此，我们应该加强Pod的安全性，让网络攻击者难以利用漏洞，限制入侵的影响。洞察一：在编排工具的使用上，Kubernetes已经成为绝对主流，K8S的使用率高达96%（如图17）。图17OrchestrationToolInsight2：在过去两年中，每个组织的平均Pod数量翻了一番（如图18所示），Kubernetes主机的平均数量也出现了类似的相对增长。图18Insight3每个组织的Pod数量：总体而言，大多数用户拥有的集群相对较少，49%的用户只有一个集群。另外，每个集群的节点数量都比较少，大部分只有1-5个Node，这说明很多企业还处于使用Kubernetes的早期阶段（如图19所示）。未来，企业将转向更多的集群和每个集群的更多节点。图19集群数量和每个集群的节点数量见解4：每个集群的Pod数量显着增加，54%的组织每个集群运行超过100个Pod（如图20所示）。每个节点的平均pod数量有所减少，表明团队正在部署更多和更小的节点来处理他们的工作负载。图20集群中的pod数量和节点pod数量洞察5：Kubernetes组织每台主机运行16个pod，而使用ECS的组织每台主机运行5个任务。在2020-2021年，两种环境的数量是一致的，表明组织正在寻找合适数量的pod和任务来支持他们的应用程序。我们还发现KubernetesPod和ECS任务平均运行1.5个容器（如图21所示）。图21每个环境的主机密度见解6：Kubernetes可以根据指标自动水平或垂直扩展pod，以构建高可用性和高性能的容器应用程序。横向扩展Pod总数可确保应用程序能够支持需求波动，而垂直扩展单个Pod的CPU和内存有助于管理应用程序的整体性能和成本。大约40%的Kubernetes组织使用HPA（水平扩展），而只有不到1%使用VPA（垂直扩展）（如图22所示）。图22Kubernetes自动扩展使用情况的时间依赖性变化洞察7：组织平均使用13个StatefulSet和28个PVC（持久卷声明）（如图23所示），这表明越来越依赖Kubernetes来支持有状态应用程序，包括内的各种工作负载。图23KubernetesStatefulSets和PVCUsageInsight8：Prometheus广泛用于Kubernetes、OpenShift和Istio等项目的指标。在JMX、StatsD和Prometheus这三大主流解决方案中，Prometheus连续第三年取得增长。与去年同期相比，Prometheus指标的使用率从去年的62%增加到83%。随着新编程框架使用的扩展，JMXMetrics（用于Java应用程序）和StatsD等替代方案继续下降，今年JMX急剧下降至仅4%，而去年为19%（如图24所示）。图24按指标类型的平均使用情况
