Kubernetes——也被称为K8s——是一个开源软件, 用于管理容器化工作负载和服务的容器编排平台. Kubernetes负责容器部署，还管理软件定义的网络层，该网络层允许容器相互通信. 该平台是可移植的，便于声明式配置和自动化.
Kubernetes官方网站表示, Kubernetes这个名字来源于希腊语, 意思是舵手或飞行员. 谷歌在2014年开源了Kubernetes项目. Kubernetes结合了Google在大规模运行生产工作负载方面超过15年的经验，以及来自社区的最佳想法和实践.”
Kubernetes通过对运行应用程序的各种容器进行分组和管理，在管理容器化应用程序的规模和复杂性方面发挥着关键作用. 容器不断地被旋转和替换, 因此Kubernetes将立即交换容器以确保没有停机时间.
但是，容器到底是什么? 根据Gartner，容器简化了应用程序打包并支持快速应用程序部署. 这使得跨开发、测试和登台的平台保持一致性. 它还有助于加速构建和软件发布，从而产生更多可重复的过程.
Kubernetes很重要，因为它抽象了容器管理和编排，并自动化了人类无法大规模管理的任务. 在很多方面, 它是实现DevOps团队在建立持续集成/持续部署时试图实现的目标的基础组件 (CI / CD)管道.
当人的因素被排除在外时，安全风险就会发挥作用——分析师现在信任一个系统来管理环境, 基于一组声明性策略和命令. 以确保这是安全地完成, 应该在基于kubernetes的应用程序中实施护栏并持续监控操作. 这确保了 合规 漂移或异常/可疑行为被捕捉和处理.
因为它的好处, Kubernetes已经迅速成为许多企业DevOps团队事实上的编排工具. 结果是, 像AWS这样的云服务提供商, Azure和GCP已经发布了Kubernetes的托管版本(EKS, AKS, and GKE, )，这几乎完全消除了管理和监控kubernetes节点和集群的需要
将安全性集成到DevOps流程中的实践称为 DevSecOps. 在开发过程中构建安全检查和护栏是非常有益的, 这两方面都允许开发团队在不牺牲安全性和遵从性的情况下快速迭代，并允许团队在到达生产环境之前捕获问题.
Kubernetes的操作可以是复杂的过程来保证安全. 成功地完成, 它可以以一种不会增加风险的方式安全地加速您的开发过程. 让我们看一下在将安全性转移到Kubernetes操作时可能出现的一些更突出的问题.
此进程在运行时（当应用程序处于生产状态时）监视应用程序，以阻止潜在的恶意活动. 挑战来自于显示相关的见解，如警报和威胁发现. 这些调查结果往往缺乏迅速开展调查和满怀信心地进行适当调查所需的许多背景. 自动化持续监控的过程可以提高DevSecOps团队的效率, 但这也迫使政府放弃部分控制权, 这可能会导致安全问题.
小的错误配置可能导致大的漏洞. 在一个实例中更改Kubernetes资源可能会导致这些更改在没有跟踪的情况下被覆盖. 这可能导致无法预见的漏洞，即使安全检查正常工作. 如果检测到漏洞或安全问题，版本控制可以快速恢复到先前的配置状态.
确保Kubernetes 容器 最大的挑战是什么. 当然, 市场上有许多解决方案可以减轻在此过程中可能出现的任何漏洞或攻击. 一次部署多个容器尤其难以确保安全. 这将是扩展部署的情况，这也会增加复杂性. 利用单一策略框架跨所有Kubernetes工作负载执行可以确保风险被标记，并保护云部署免受恶意攻击.
利用注册表中的容器映像可以加快这个过程, 但这些图片可能包含恶意代码. Indeed, 在使用Kubernetes容器时，必须在过程中构建漏洞扫描等工具，这些容器存在于公开可用的注册表中.
私有存储容器映像并利用漏洞扫描可以确保开发管道尽可能少地看到公开可用的资源和容器映像. 速度也可能是一个不利因素, 特别是如果团队跳过将映像漏洞与已部署的容器映像关联起来的步骤. 这种比较对于理解您的网络所面临的风险至关重要.
那么，什么是最关键的部分 确保Kubernetes操作的安全?
到目前为止，我们所讨论的内容应该传达了一个非常重要的信息：Kubernetes非常有益, 但应该谨慎而有条不紊地加以利用. 说到这一点, 将最佳实践集成到Kubernetes工作流中是学习流程和提升的关键.
RBACs 允许您配置用户访问，并在数据和用户群的规模和复杂性增长时有效地管理它们. 分配的产品, roles, 和资源，以便用户只能访问其角色所需的信息. 这鼓励了 最小特权原则，这有助于防止用户访问与其角色无关的敏感数据或信息.
api控制应用程序之间发出的请求类型, 这些请求是如何提出的, 以及这些请求的格式. 因为单个应用程序通常可以包含许多api的使用, 它们给开发和部署过程增加了漏洞. 因此，最好将api的访问权限限制在绝对需要的人员.
安全Shell （SSH） 有助于使用加密安全性保护开发协议. 它本质上是一个外壳，用强化的安全检查覆盖信息系统. 如果SSH不安全且防御不当, 它可能会使云应用程序和Kubernetes工作负载暴露于漏洞和攻击之下, 特别是对于上市公司和向互联网开放的系统.
这可能是不言而喻的, 但确保工作负载和部署得到保护和适当容器化的最佳方法是保持Kubernetes的最新状态. 事实上, Kubernetes具有滚动更新过程，因此用户可以通过使用新版本增量更新实例来零停机地更新部署.
持续和主动的扫描和监视可以防止意外的漏洞和恶意威胁. 在最近的云工作负载保护平台市场指南中, Gartner表示，工作负载正变得更加细化, 寿命更短. 有时每周甚至每天部署多个迭代.
主动方法是保护这些快速变化和短暂工作负载的最佳方法. 部署前漏洞管理和持续的代码扫描有助于从一开始到部署和运行时保护基于云的工作负载.
维护Kubernetes集群的适当配置是必要的. 与任何其他运行时工作负载一样, 不正确的配置可能会使K8s环境容易受到破坏. 确保正确配置和安全性的实践称为 Kubernetes安全态势管理（KSPM）.
KSPM建立了一个系统，用于建立和维护Kubernetes集群防御的强度，并确保它们符合内部和外部安全标准.