随着云原生和容器化的普及，Kubernetes（一种协调工作负载的绝佳方式）越来越受欢迎，就像任何伟大的技术一样。因此，出现了很多混乱的情况。每个人都在使用Kubernetes来迁移他们的工作负载，但他们在投入生产之前并没有考虑安全问题。这可能是自然的行动过程，但它在 Kubernetes 中不起作用。 你不能等到最后一刻才使用 Kubernetes 将工作负载转移到生产环境；你需要从一开始就考虑安全问题。如果在 Kubernetes 这样的系统中不考虑安全问题，工作负载很容易受到影响，而且你也不会有一个有效的解决方案。
这其中的原因是什么呢？云原生与其他技术有何不同？让我们看看其中的一些区别，看看为什么它们需要对云原生应用的安全和可观察性采取更全面的方法，无论是在Kubernetes还是其他地方。
云原生技术简史
如果把云原生排除在外，我们习惯于客户端-服务器设计，其中服务器在虚拟机 (VM) 上运行，客户端连接到服务器集群。我们习惯于以 这种方式开发和部署客户端-服务器应用程序。
由于多种原因，云原生在本质上是不同的。从服务器的角度来看，大多数从业者会认为，对于必须完成的简单操作来说（例如，从数据库中检索某些内容或评估 HTTP 请求并将其发送出去），VM 过于“繁重”。
因为一个虚拟机可以承载多个容器，每个容器都有自己的网络，所以你需要一个协调器来跟踪它们。
这就是 Kubernetes 的作用：使用最广泛的编排器。（云原生系统在业界非常普遍，以至于很多人将它与 Kubernetes 混为一谈。）Kubernetes 使用你的容器并为你完成几乎所有的事情；你所要做的就是告诉它要运行什么。
为什么 Kubernetes 如此受欢迎？因为它提供了大量的多功能性。过去，你有一台服务器，有一堆IP，并且可能有几个接口可以让你访问计算资源，但现在已经不是这样了。 你现在拥有一个服务器，它被分成多个容器，可以部署在任何主机上，你可以指定这些容器必须与哪些应用程序连接。Kubernetes 负责一切，包括将所有东西链接在一起并运行这些操作。
云原生技术面临哪些挑战？
云原生在两个关键方面有所不同：工作负载的安全和交付方式。从安全用户的角度来看，没有身份的概念。虽然 IP 和端口用于识别容器，但 Kubernetes 现在会为你处理这个问题；你的容器今天可能在一个 IP 上，明天可能在另一个 IP 上。这需要你重新考虑如何保护你的工作负载。
就工作负载的交付方式而言，情况发生了巨大变化。你过去常常构建应用程序、创建一个镜像、可执行文件或安装程序，然后把它交给安全团队。之后，之后，安全团队会选择要使用的服务器，并在其周围建立围栏。一旦一切准备就绪，他们就会部署应用程序，因为他们知道它是安全的。但是，随着CI/CD 管道的自动化，不再需要安全团队的参与。
这是什么原因？使用 CI/CD，你可以创建一个容器来生成一组特定的镜像文件，然后将其存储在你的存储库中，并使用自动化过程进行验证和部署。
安全问题并没有太多的空间来发挥作用。如果安全问题阻碍了CI/CD过程，那将是自相矛盾的，因为CI/CD过程是自动化的，以实现更快的速度。左移安全要求安全团队在开发周期中提前操作，并与开发过程更紧密地联系在一起，以更好地理解它。
如何构建云原生安全和可观察性策略？
采用公有云是很复杂的。它通常需要重点关注威胁检测和重新调整安全事件管理、监控、检测和响应流程及游戏规则。幸运的是，一些第三方和云原生工具和服务可以帮助收集、聚合和分析云事件。 在他们的云监控、检测和响应策略中，一些企业正在考虑使用可观察性和安全事件导向和决策。可观察性策略可以帮助制定可靠的指标和跟踪，以确保安全操作随着时间的推移而改进。
可观察性是一个来自控制系统工程领域的术语，指的是对系统输出的监测和确定。被称为可观察的，系统的行为和活动必须能够被观察到，以确定系统的状态。
云可观察性的要素：IT 管理人员必须首先确定所涵盖的内容，以制定一个完整的云可观察性计划。可观察性从典型的工作负载扩展到控制平面、网络、应用程序、容器和存储层面。
应用程序可观察性：应用程序的可见性是通过大规模跟踪事件和行为来实现的。这可能很困难，因为工作负载和身份关联以及个别系统和容器上的本地应用程序日志在整个云环境中进行交流。企业必须将事件输入到针对云环境量身定制的事件管理和 SIEM 平台中，通常通过 API 集成，以实现真正的应用程序可观察性。
数据库和存储的可观察性：在许多云安装中使用了广泛的存储类型，包括块存储、二进制对象存储和数据库。大多数云存储系统包括各种住宿选项和其他一些配置选项，可以被观察和查看。
云原生可观察性工具
云设置中可观察性的主要来源是：
配置评估工具和服务的反馈，例如AWS Config 或开源 Cloud Custodian 工具，以及来自其他云原生技术的反馈，都是其他来源。
代理和标准监控工具可能无法在 AWS Fargate 或 Azure Functions 等云原生计算服务中使用。因此，实现可观察性是一个独一无二的问题。外部反馈和监控机制和控制，使用一个统一的软件底板，所有工作负载和服务都连接到该底板，对企业来说变得越来越重要。
安全和可观察性：一种综合方法
在像 Kubernetes 这样的动态环境中，把安全和可观察性结合起来考虑，可以帮助你安全地部署应用程序。例如，你可能需要“观察”你的集群以确定安装安全控制的最佳方法。
由于其声明式设计，允许用户指定更高层次的结果，Kubernetes 作为编排引擎具有很高的采用率。Kubernetes 还具有内置功能，可确保你的集群按计划运行。
它通过跟踪几个属性，并在其中一个属性长时间偏离指定值的情况下采取行动（例如，重新启动 pod）来实现这一点。由于 Kubernetes 的这些特性，实现保护集群所需的可见性和控制可能很困难。Kubernetes 操作必须与你实施的控制保持一致。因此，在向Kubernetes添加任何控制措施之前，了解背景是至关重要的，——例如，你不能通过执行一个策略来隔离一个pod，阻止它与其他pod进行通信。
Kubernetes 会注意到 pod 无法与其他元素（例如 API 服务器）通信，确定 pod 没有按预期运行，然后在集群中的某个位置重新启动 pod。在应用控制或检测意外事件之前，你必须首先了解 Pod 的功能以及它的预期功能是什么。之后，你评估意外事件是安全问题还是操作问题，并采取适当的措施。
可观察性和安全问题共同实现这一目标：你通过观察来了解预期的东西，并应用控制措施来保证预期的功能，通过观察来发现和评估意外事件，最后，你添加适当的控制措施来修复由事件引起的任何问题。因在研究集群的安全性和可观察性时，整体的方法是至关重要的。
总结
简而言之，Kubernetes的安全与传统的安全不同，它需要在工作负载部署的所有阶段（构建、部署和运行时）采取全面的安全和可观察方法。
工作负载可以在节点网络上的任何地方运行，因为 Kubernetes 是声明性的，对工作负载操作的复杂性进行了抽象。工作负载也可以是临时的，这意味着它们被删除并在一个单独的节点上重新创建。确保这样一个声明式的分布式系统的安全，需要在所有阶段考虑安全问题。
在创建和实施整体安全方法时，我们希望你能看到应用、平台和安全团队之间协作的重要性。
安全团队广泛使用两个安全框架：MITRE 和 Kubernetes 威胁矩阵，因为一个成功的安全和可观察性策略是整体的，你必须同时考虑所有的问题。
本文为翻译文章，原文链接： https://www.metasecure.ai/blog/an-integrated-approach-to-cloud-native-security-and-observability
