作者：Andrew Harding
你好！这是来自 Scytale 的 Andrew Harding。如果你目前正在使用 Envoy 提供安全的服务到服务通信，我想向你展示如何利用开源 SPIRE 项目，通过基于多个因子工作负载认证，自动交付和轮换密钥和证书来显着提高你的身份验证安全性。
Envoy 和 SPIRE 已经存在了一段时间，但我们最近才在 SPIRE 中增加了对 Envoy SDS API 的支持，这使得设置起来更加容易。我们来探讨一下。
背景
Envoy 是一个流行的开源服务代理，除其他外，广泛用于在服务之间提供抽象、安全、经过身份验证和加密的通信。Envoy 享有丰富的配置系统，允许灵活的第三方交互。
该配置系统的一个组件是秘密发现服务协议或 SDS（Secret Discovery Service）。Envoy 使用 SDS 从 SDS 供应商处检索并维护更新的“秘密”。在身份验证的意思来说，这些秘密是 Envoy 用于在服务之间提供安全 TLS 通信的 TLS 证书、私钥和可信 CA 证书。
短暂的秘密是安全的一个重要方面，因为它们减少了对撤销列表基础设施的需求，这削弱了安全性并导致攻击面增加。旋转短寿命秘密经常涉及手动审计和部署，并且通常对操作员来说非常麻烦。SDS 供应商向 Envoy 提供更新秘密的能力，是简化秘密管理和为 Envoy 提供最新服务标识的有用步骤。
SPIRE（SPIFFE 运行时环境）是一个工具链，用于在各种平台上建立软件系统之间的信任。SPIRE 支持容器化和弹性扩展环境，例如 Kubernetes、托管基础架构如 Azure、AWS 和 GCP，以及内部裸机部署。这些环境中的服务可以利用 SPIRE 以 X.509 证书（X509-SVID）的形式，获取具有关联私钥的服务标识，以及服务可用于验证其他身份的一组可信 CA 证书。
当服务与 SPIRE 接合时，它会经历一个称为证明（attestation）的过程，其中 SPIRE 宣称
（assert）有关服务及其环境的特征。这些宣称与运营商定义的政策相匹配，以决定应该为服务提供哪个服务标识。（有关证明的更多详细信息，请参阅此视频。）SPIRE 根据运营商定义的政策自动轮换服务的 X.509 证书和密钥。
换句话说，Envoy 可以通过 SDS 动态消费服务标识，SPIRE 可以动态提供服务标识。听起来很棒！
这个怎样运作
当 Envoy 连接到 SDS 服务器时，SPIRE 代理会证明 Envoy 并确定它应该通过 SDS 向 Envoy 提供哪些服务身份和 CA 证书。
随着服务标识和 CA 证书的轮换，更新将流式传输回 Envoy，Envoy 可立即将它们应用于新连接，而不会中断或停机，也无需私钥触及磁盘。换句话说，SPIRE 丰富的定义和证明服务的方法可用于定位 Envoy 流程，为其定义身份，并为其提供 Xv09 证书和 Envoy 可用于 TLS 通信的信任信息。
在两个服务之间的两个 Envoy 代理，使用 SPIRE 代理作为 SDS 的实现，以获取相互认证的 TLS 通信的秘密
配置 SPIRE
在 SPIRE 中设置 SDS 支持就像在 SPIRE 代理配置中设置 enable_sds = true 配置值一样简单。
配置 Envoy
SPIRE 代理群集
必须将 Envoy 配置为与 SPIRE 代理通信，通过配置集群指向 SPIRE 代理提供的 Unix 域套接字（domain socket）。
例如：
clusters:
– name: spire_agent
connect_timeout: 0.25s
http2_protocol_options: {}
hosts:
– pipe:
path: /tmp/agent.sock
connect_timeout 会影响 Envoy 在启动 Envoy 时 SPIRE 代理未运行或者如果重启 SPIRE 代理时能够响应的速度。
TLS 证书
要从 SPIRE 获取 TLS 证书和私钥，你可以在 TLS 上下文中设置 SDS 配置。
例如：
tls_context:
common_tls_context:
tls_certificate_sds_secret_configs:
– name: “spiffe://example.org/backend”
sds_config:
api_config_source:
api_type: GRPC
grpc_services:
envoy_grpc:
cluster_name: spire_agent
TLS 证书的名称是 Envoy 充当代理服务的 SPIFFE ID。
验证上下文（Validation Context）
Envoy 使用可信 CA 证书来验证对等证书。验证上下文提供这些可信 CA 证书。SPIRE 可以为每个信任域提供验证上下文。
要获取信任域的验证上下文，可以在 TLS 上下文的 SDS 配置中配置验证上下文，将验证上下文的名称设置为信任域的 SPIFFE ID。
例如：
tls_context:
common_tls_context:
validation_context_sds_secret_config:
name: “spiffe://example.org”
sds_config:
api_config_source:
api_type: GRPC
grpc_services:
envoy_grpc:
cluster_name: spire_agent
SPIFFE 和 SPIRE 专注于促进安全认证作为授权的构建块，而不是授权本身，因此对验证上下文中的授权相关字段（例如 verify_subject_alt_name）的支持超出范围。相反，我们建议你利用 Envoy 广泛的过滤器框架来执行授权。此外，你可以将 Envoy 配置为将客户端证书详细信息转发到目标服务，从而允许它执行自己的授权步骤，例如使用嵌入在客户端 X.509 SVID 的 URI SAN 中的 SPIFFE ID。
试试看！
这就是你使用 SPIRE 改善服务到服务通信中的身份验证安全性的方法！尝试一下，让我们知道你的试用是怎么回事！你可以通过 SPIFFE slack 与我们联系。计划进行未来的改进，你的经验对于塑造 SPIRE 对 Envoy 的支持非常有价值。
我要感谢 Scytale 公司自己的 Marcos Yacob 和 Marcos Yedro，他们的努力有助于 SPIRE SDS 实施的原型设计和开发。
KubeCon + CloudNativeCon 和 Open Source Summit 大会日期：
会议日程通告日期：2019 年 4 月 10 日
会议活动举办日期：2019 年 6 月 24 至 26 日
KubeCon + CloudNativeCon 和 Open Source Summit 赞助方案 KubeCon + CloudNativeCon 和 Open Source Summit 多元化奖学金现正接受申请 KubeCon + CloudNativeCon 和 Open Source Summit 即将首次合体落地中国 KubeCon + CloudNativeCon 和 Open Source Summit 购票窗口，立即购票！