容器安全性是实现保护容器化应用程序和工作负载的机制/流程的实践. 在当今的云环境中，最大程度地了解容器主机位置等方面是至关重要的, identifying running or stopped containers, spotting container hosts not in compliance with 独联体基准, 和 performing vulnerability assessments.
什么是容器? 谷歌云 定义了容器 作为运行软件服务所需的轻量级应用程序代码包(与诸如特定版本的编程语言运行时和库等依赖项相结合). A container orchestration platform – like Kubernetes – has a big job to do, automating provisioning as well as starting, 停止, 和 maintenance of images.
因为容器编排是通过Kubernetes等工具抽象和自动化的, 它非常适合集成到持续集成/持续部署(CI / CD)生命周期，并且是采用DevOps实践的关键组成部分. 此过程是交付新应用程序或代码更新的有效且可靠的方法. 因此，护栏是必要的，以确保事情不会失控. From a container perspective, we should:
As with anything that drives increased speed, 在这个过程中，我们确实冒着牺牲安全和控制的风险. 这意味着安全团队必须与开发组织中的对应团队携手合作，以确保适当的防护和检查到位.
容器安全性应该尽可能早地在CI / CD管道中实现，以便更快地暴露应用程序风险，并尽可能减少开发过程中的摩擦.
容器安全性非常重要，因为该技术在云工作负载环境中的操作非常复杂. Security is also important because containers are the foundation upon which so many of today’s public-internet facing applications are built; this leaves them exposed to many potential risks. 那些 risks associated with containerizing digital assets are manageable 和 can be mitigated by:
现在我们对容器操作有了更多的了解，并了解了它们为什么如此受欢迎, 让我们来看看团队如何将一些最佳实践用于保护这些环境.
重要的是要实现安全性，而不仅仅是针对稳定状态容器和扫描图像, but also during runtime when containers are operational. Issues can 和 should be fixed post-deployment, 因为安全是一个持续的过程，不能在发展中得到充分保证.
在CI / CD环境中，漏洞可能随时冒出来——或者可能已经潜伏了好几个月才被发现. When deployments 和 updates go out on the regular, 对于安全团队来说，能够发现他们所能发现的每一个漏洞是至关重要的. 对容器安全程序来说，定期扫描以识别漏洞是必要的. 容器映像扫描通常会引用一个包含公开已知漏洞列表的漏洞利用数据库.
Infrastructure is becoming more compartmentalized, 更短暂, 并且更依赖于代码而不是物理机器. 这就是为什么监视容器的漏洞在系统健康中起着如此关键的作用. Even if everything tests 和 passes, 在进行部署后测试时，仍然会出现问题. 这就是为什么必须在整个CI / CD管道中使用具有一致的安全检查集的解决方案. 这使得团队能够在不延迟部署的情况下纠正错误配置和策略违反.
在DevOps组织中，决定将操作启动到虚拟世界是一个转折点, 和 there are many benefits of containers. If a business is going to invest in that infrastructure, 最好将其一直保护到应用层，并为如何配置容器设置标准. 实时监视和跟踪关键容器事件有助于优化应用程序性能. To top off the process, 利用实时性能监控和分析(如CPU)是一个很好的最佳实践, 内存, 和 network usage – for all running containers.
Like other cloud resources, 容器和在其中运行的进程被分配了角色/权限，这些角色/权限需要使用 identity 和 access management (IAM) plan, preferably in accordance with least privilege access (LPA). 后 DevSecOps organization has calibrated a fancy, new multi-cloud container environment, access should be restricted to only those who need it. IAM是保证云和容器服务安全和兼容的关键. 它还可以帮助制定合理和可持续的方法，以解决边界流动性和大规模管理云环境的重大挑战.
客户在购买云服务提供商(csp)时可以选择供应商。, 并且有各种不同的容器运行时和容器编排平台可供选择. 但重要的是要选择一个由底层云平台适当支持的云, 同时考虑到csp有多种管理容器的产品.
码头工人 first came onto the market in 2013, 并提供了在容器中打包和运行应用程序的能力. 该平台允许在用户工作时共享容器, 并确保每个人都看到并使用相同的容器和功能. 它通过开发、分发、测试和部署来帮助管理容器生命周期.
Kubernetes 是一个用于管理工作负载和服务的开源、容器编排平台吗. Kubernetes负责容器部署，还管理软件定义的网络层，该网络层允许容器相互通信. The platform is portable 和 facilitates declarative configuration 和 automation. Google open-sourced the Kubernetes project in 2014.
Google Kubernetes Engine (GKE) 于2018年推出，是运行码头工人容器的集群管理器和编排系统. It works with on-prem, 混合动力, or public-cloud infrastructure, 并且可以管理容器集群的虚拟机，快速部署. GKE可以按照声明的方式安排声明的容器，并主动管理应用程序.
Amazon Elastic Container Service (ECS) 于2014年推出, 旨在与AWS平台的其余部分集成，以在云和本地运行容器工作负载. ECS跨环境提供一致的工具、管理、工作负载调度和监视. Users can also automatically scale apps across 可用性区域，以及根据资源需求和可用性随意放置容器.
我们已经稍微谈到了它，但是这些云容器环境在幕后可能很复杂. 近年来，供应商一直把易用性放在首位, 大部分的复杂性都被放到了后台. 这并不意味着, 然而, 用户不需要意识到保护这些环境的挑战. 换句话说，你必须知道它是如何工作的，才能知道如何修复它. 让我们看一下一些常见的容器安全挑战.