当组织迁移到一个新的平台（比如Kubernetes）来构建他们的应用程序时，有很多事情需要重新考虑。安全、访问控制和监视只是几个例子。当谈到在库伯内特斯环境中解决这些挑战时，网站自助建站系统，特使和伊斯蒂奥带来了很多东西。甚至谷歌设想的PaaS PaaS也建立在ISTIO和Kubernetes上的使者的基础上。这就是为什么我们选择了一个相对简单的安全需求——HTTP安全头——并想举例说明如何以默认安全的方式为这一新兴技术栈实现它。

好吧，多年来，web发展了很多。引入了许多新技术，但也伴随着新的攻击载体，如点击劫持和跨站点脚本以及隐私问题。浏览器供应商通过新的安全和隐私功能解决了这些问题。不幸的是，默认启用它们会破坏现有的网站。因此，每个站点都必须决定启用哪些功能以及如何配置这些功能。这是通过发送相应的HTTP响应头来完成的，这些响应头通知浏览器要为您的站点启用哪些功能。下面的代码片段给出了一个设置安全标头的示例。

给定的HTTP响应通过设置X frame Options标头告诉浏览器不要框显其内容。这可以防止对页面的点击劫持攻击。如果你真的需要被某些站点框起来，你可以通过用你想要被框起来的页面的相应来源来替换deny来显式地允许它们。通过明确允许源代码，被攻击者控制的源代码陷害的风险被最小化。

当您移动到新平台并从头开始构建应用程序时，破坏遗留应用程序的问题会发生变化–或者至少您必须为新平台设置它们。关键是，不会有太多的遗留应用程序因为浏览器的安全和隐私特性而崩溃。这些情况允许我们改变现状，默认设置安全头。每个需要不同行为的应用程序都可以通过显式设置更宽松的安全头来否决这个新的默认值。

在internet上搜索安全头时，您会发现很多建议。OWASP提供了最佳实践指南和编程框架，描述了如何使用安全头来保护应用程序。甚至还有一些服务可以直接对部署的安全性和隐私头进行评级。尽管这些指导原则中的大多数都符合我们的要求，但也有一些是非常特定于应用程序的，如果没有特定于应用程序上下文的知识，就无法进行设置。考虑到可能有多个应用程序在单个集群上运行，解决方案应该保持通用性。另外，一些处理HTTPS/TLS细节的头被省略了，默认情况下，不配置用于暴露群集的负载平衡器的证书。

将其归结为可为整个群集集中设置且不处理HTTPS细节的安全和隐私标头：

此默认标头列表可能会扩展以用于支持HTTPS的端点的生产性使用以及更严格的限制内容安全策略或功能策略设置。但现在，这是我们的基线设置。

我们有一个要在集群范围内部署的安全头的列表，现在的问题是如何将它们集成到特使resp中。Istio编程模型。如果你对Istio和特使以及他们的互动方式完全陌生，请查看docs页面。下图描述了Istio如何通过代理和网关处理入口和出口，并有助于获得可以设置标头的概述。

（来源：https://istio.io/docs/concepts/traffic management/#入口-和出口）

对集群和服务网的传入请求和通过入口的传出响应路由网关。服务网内的服务对服务通信通过放置在每个吊舱中的特使侧车进行处理。传出请求和传入响应通过可选的出口网关路由。网关和侧车都是集群中运行的特使代理的实例。

mesh中的服务对服务调用不需要浏览器解释的安全头。因此，采购返利，当我们不想造成不必要的处理和集群内部通信开销时，特使侧车可能不是检查和设置头部的最佳位置。另外，通过可选出口网关离开mesh的请求不会以安全头的方式与浏览器通信。入口网关的出站处理程序是响应可能在浏览器中结束的地方，我们应该在这里设置安全标头。因此，入口网关是为浏览器默认设置安全头的最佳位置。

请注意：Kubernetes还有其他公开服务的方法，但本文重点介绍了Istio的编程模型！

如前所述，入口网关实际上是作为代理实现的。为了实现默认安全报头概念，可以利用特使提供的响应操作功能。根据特使文档，可以通过定义为Lua过滤器的响应处理程序来完成报头操作。Lua过滤器基本上是Lua代码的一个片段，它为注册的每个请求或响应执行。使用Istio，可以集中配置这个Lua过滤器，并将其分发到入口网关的各个特使实例。在Istio中使用特使过滤器的文档可以在这里找到。下面的资源给出了如何通过Istio为入口网关配置默认安全头过滤器的示例：