多云系统的授权

这是我目前正在致力于消耗SPIFFE（
安全生产身份框架（Every Production Identity Framework For Everyone ）在WSO2的Prabath Siriwardena先生的启发下，在Moratuwa大学的Gihan Dias教授的指导下，通过信任和身份验证在动态扩展的异构系统中提供授权。像在混合云中一样，跨多个云运行的企业系统就是一个明显的例子，将从中受益。目的是为基于SPIFFE标准的系统打开大门，使其以最小的努力与其余系统共存，而不会损害安全性，同时拥有基于SPIFFE的授权解决方案。

简而言之，它是一个信任引导和识别框架，已作为标准提交并被CNCF（Cloud Native Computing Foundation）[1]接受。到目前为止，该标准有两个主要实现，分别是SPIRE和Istio [2]，该平台支持使用SPIFFE进行识别方面的服务网格体系结构。此实现解决了跨异构系统的信任引导和标识所涉及的许多复杂问题。更多细节可以在
spiffe.io网站。

OAuth 2.0当前是API安全领域中使用最广泛的标准，在工作负载领域中也用于访问委派和授权。尽管SPIFFE是目前新兴的标准，但是OAuth 2.0已经存在了一段时间，可以说大多数企业系统都采用了它。因此，如果我们可以将这两个标准融合在一起，则可以兼具两全其美的优势，并具有OAuth 2.0提供的互操作性以及SPIFFE的动态信任引导和识别功能。

请注意，下图中的SPIRE服务器可以是任何支持SPIFFE标准的实现。

–我们假设一个企业系统由两个云中的工作负载组成，此处我们假设是AWS和GCP。如果我们将其想象为GCP中当前正在运行的系统，且其工作负载基于OAuth 2.0范围而受到保护，则要消耗这些工作负载的其他工作负载应带有有效的访问令牌和相关范围。

–可以想象在AWS云中运行的系统部分是新设计的，可以作为多云系统的一部分运行。它利用SPIFFE标准来唯一地识别跨多个云的工作负载。 –作为此基于SPIFFE的信任引导和标识的一部分，每个工作负载都会接收由SPIRE服务器签名的X.509证书，并带有其标识符，称为SPIFFE ID。例如。 spiffe：// localdomain / us-west / data（包含在SAN中）[3] –这是OAuth 2.0的图片。我们依赖于授权服务器在客户端凭据授予类型下发出OAuth 2访问令牌的能力。这将处于草拟阶段[4]的MTLS OAuth2.0规范之下。

这里很少发生什么特别的事情，

基于工作负载的SPIRE服务器签名密钥对创建MTLS连接。因此，假定授权服务器和SPIRE服务器具有预先建立的信任。
当工作负载创建与授权服务器的MTLS连接时，它会动态地动态创建OAuth 2客户端，生成OAuth2机密并颁发令牌。此时，授权服务器应在发出验证之前进行几次验证。
首先需要验证证书，然后需要读取证书的内容以及SAN中的SPIFFE ID。
仅查看SPIFFE ID并颁发令牌不足以满足企业用例。
因此，我们将提供基于使用OPA在授权服务器中定义的策略将范围附加到这些令牌的功能。（OPA代表开放策略代理，它非常灵活，可以像复杂策略一样提供RBAC，ABAC或XACML。）此策略可以使用其他可用数据并做出决策。
验证完成后，授权服务器将发出一个自包含的访问令牌，包括范围，到期时间等，这些令牌将发送到AWS工作负载，以便在调用GCP工作负载时提交。
除了使用其现有机制来验证OAuth 2.0令牌并获取其附带的任何有用信息外，GCP工作负载此处不需要任何其他功能。

希望这能很好地解释这种情况。我将这个解决方案命名为Dvaara，表示要打开更多的门并控制进出。 :)
我们欢迎任何反馈，建议。
[1] – https://www.cncf.io/blog/2018/03/29/cncf-to-host-the-spiffe-project/ [2] – https://istio.io/docs/concepts/security/#istio-security-vs-spiffe [3] –样本SVID https://gist.github.com/Pushpalanka/b70d5057154eb3c34d651e6a4d8f46ee#file-svid-cert [4] – https://tools.ietf.org/html/draft-ietf-oauth-mtls-12 [5] – https://www.openpolicyagent.org/docs/comparison-to-other-systems.html

干杯!