现代Web应用程序的身份验证和授权与亚马逊VPC Lattice 安全博客

现代网络应用程序的身份验证与授权：利用 Amazon VPC Lattice

关键要点

在构建基于 API 的云应用时，身份验证和授权是两个基本组成部分。本文探讨了如何利用 Amazon VPC Lattice 实现这两种通信流的安全机制，提供简洁高效的架构示例，以确保应用程序的身份验证和访问控制。

当构建云中的基于 API 的网络应用时，身份验证和授权是两个主要的通信流，这些流中的身份验证至关重要：

为了设计适用于这些流程的身份验证和授权解决方案，您需要为每个流程增加一个维度：

在每个流程中，用户或服务必须向应用程序服务提供某种凭据，以便该服务可以判断是否允许该流程进行。这些凭据通常伴随着其他元数据，可以用于进一步的访问控制决策。

在这篇博客中，我将介绍两种方法，您可以利用 Amazon VPC Lattice 来实现这两种通信流程。我还将向您展示如何构建一个简单且干净的架构，以安全地保护您的网络应用，提供可扩展的身份验证，并提供身份验证元数据以做出粗粒度的访问控制决策。

示例解决方案基于一个标准的 API 应用，其中多个 API 组件通过 TLS 提供 HTTP 数据。通过这个解决方案，我将展示如何使用 VPC Lattice 为应用程序提供身份验证和授权功能，而无需应用程序开发者自己创建这些逻辑。在此解决方案中，示例应用程序不实现自己的身份验证或授权，因此您将利用 VPC Lattice 及其与 Envoy 结合使用的额外代理功能来以最小的应用程序更改提供这些功能。此解决方案使用 Amazon Elastic Container Service (Amazon ECS) 作为容器环境来运行 API 端点和 OAuth 代理，但 Amazon ECS 和容器并不是 VPC Lattice 集成的先决条件。

如果您的应用程序已经有客户端身份验证，例如使用 OpenID Connect (OIDC) 的 Web 应用程序，您仍然可以使用示例代码来查看如何使用 VPC Lattice 实现安全的服务间通信流程。

VPC Lattice 配置

VPC Lattice 是一种应用网络服务，可以连接、监控和保护服务之间的通信，帮助提高生产力，使开发者能够更专注于构建对业务重要的特性。您可以定义 网络流量管理、访问控制 和 监控 的策略，以简化并一致地连接计算服务，无论是在实例、容器还是无服务器应用程序中。

对于 web 应用程序，尤其是那些基于 API 并由多个组件组成的应用，VPC Lattice 是一个非常合适的选择。借助 VPC Lattice，您可以利用原生 AWS 身份功能进行凭据分发和访问控制，而无需许多应用程序安全解决方案所需的操作开销。

该解决方案使用单一的 VPC Lattice 服务网络，每个应用组件被表示为单独的服务。VPC Lattice 授权策略是 AWS 身份和访问管理 (IAM) 策略文档，您可以将其附加到服务网络或服务上，以控制指定主体是否有权访问一组服务或特定服务。在此解决方案中，我们对服务网络使用了一个授权策略，并在服务本身上使用了更细粒度的策略。

用户与服务的通信流程

在这个例子中，web 应用由多个 API 端点构成。这些是典型的 REST API，提供与各种应用组件的 API 连接。

保护 REST API 的最常见方法是使用 OAuth2。OAuth2 允许客户端代表用户与 授权服务器 进行交互并检索 访问令牌。访问令牌旨在提供给 REST API，并包含足够的信息以确定访问令牌中标识的用户已经同意 REST API 代表他们操作他们的数据。

访问令牌使用 OAuth2 范围来表示用户的同意。定义 OAuth2 范围的工作超出了本帖的范畴。您可以在 AuthO 博客中的 权限、特权与范围 中了解关于范围的知识。

VPC Lattice 不支持 OAuth2 客户端或检查功能，但它可以验证 HTTP 头内容。这意味着您可以在 VPC Lattice 服务策略中使用头匹配，仅在包含正确头的情况下授予对 VPC Lattice 服务的访问权限。通过基于进入服务网络之前进行的验证生成的头，我们可以使用关于用户的上下文在服务网络或服务中做出访问控制决策。

图 1：用户与服务的通信流

该解决方案利用 Envoy 终止来自 OAuth 20 客户端的 HTTP 请求。这在图 1 中被展示。

Envoy在图 2 中标记为 (1)可以验证访问令牌作为嵌入在 Authorization Bearer 头中的 JSON Web Token (JWT)。如果可以验证访问令牌，则从该令牌中提取的范围2会被放入 XJWTScopelt范围名gt 头中，使用简单的内联 Lua 脚本完成。Envoy 文档提供了 示例 说明如何在 Envoy 中使用内联 Lua。图 2展示了 JWT 范围到 HTTP 头的高层流程。

图 2：JWT 范围到 HTTP 头

接下来，Envoy 使用 签名版本 4 (SigV4) 对请求进行签名 (3) 并将其传递给 VPC Lattice 服务。SigV4 签名是 Envoy 的原生功能，但它要求 Envoy 正在运行的底层计算具有 AWS 凭据的访问权限。当使用 AWS 计算时，将角色分配给该计算可验证该实例是否能够为在该计算上运行的进程提供凭据，在此情况下是 Envoy。

通过添加只允许来自 Envoy 的访问权限的授权策略通过验证 Envoy 的 SigV4 签名以及只使用在 HTTP 头中提供的正确范围，您可以有效地将 VPC Lattice 服务锁定为来自 Envoy 的特定经过验证的用户，他们在其承载令牌中提供特定 OAuth2 范围。

为了回答关于身份来自何方的原始问题，身份由用户在与其身份提供者IdP通信时提供。此外，Envoy 正在从其底层计算中提供自己的身份以进入 VPC Lattice 服务网络。从配置的角度来看，这意味着您的用户与服务的通信流不需要了解用户，或者存储用户或机器凭据。

所提供的示例代码展示了一个完整的 Envoy 配置，适用于 VPC Lattice，包括 SigV4 签名、访问令牌验证和 JWT 内容提取到头。这种参考架构支持多种客户端，包括服务器端 Web 应用程序、厚 Java 客户端，甚至是直接调用 API 的命令行界面客户端。这篇文章没有详细介绍 OAuth 客户端，但可选的示例代码允许您使用 OAuth 客户端和流程通过 Envoy 与 API 进行通信。

服务与服务的通信流程

在服务间通信流程中，您需要为应用程序提供 AWS 凭据，并配置它们使用 SigV4 来签署 HTTP 请求以到达目标 VPC Lattice 服务。您的应用组件可以具有自己的身份IAM 角色，从而允许您唯一地识别应用组件并基于所需的特定流程做出访问控制决定。例如，应用组件 1 可能需要与应用组件 2 进行通信，但不与应用组件 3 进行通信。

如果您完全控制应用程序代码，并且有干净的方法找到目标服务，则这可能是您能在服务器代码中直接实现的东西。这是本文所附的 AWS Cloud Development Kit (AWS CDK) 解决方案中实现的配置，app1、app2 和 app3 Web 服务器能够对其需要与之通信的 VPC Lattice 服务进行 SigV4 签名请求。此 示例代码 展示了如何在 nodejs 中执行 VPC Lattice SigV4 请求，使用 awscrt node bindings。图 3 描述了服务间及 VPC Lattice 之间的 SigV4 认证的使用。

图 3：服务与服务的通信流程

要回答此流中身份来自何方的问题，您使用 VPC Lattice 的原生 SigV4 签名支持来验证应用身份。凭据来自 AWS STS，再次通过原生底层计算环境。为您的应用程序透明地提供凭据是 VPC Lattice 解决方案相较于其他类型应用程序安全解决方案如服务网格时的最大优势之一。这种实现无需提供凭据、管理身份存储，并在需要时自动轮换凭据。这意味着以低开销的方式部署和维护此解决方案的安全性，并从 IAM 和 AWS 安全令牌服务 (AWS STS) 的可靠性和可扩展性中获益这是保护服务间通信流程的一种非常灵活的解决方案！

VPC Lattice 策略配置

VPC Lattice 提供了两级授权策略配置在 VPC Lattice 服务网络和单个 VPC Lattice 服务上。这将使您的云运营和开发团队能够独立工作，从而消除单个团队实施访问控制的依赖关系。这种模型促进了敏捷性和职责分离。有关 VPC Lattice 策略配置的更多信息，请参见 使用授权策略控制对服务的访问。

服务网络授权策略

此设计使用服务网络授权策略，允许特定 IAM 主体访问服务网络。这可以作为提供整体访问控制的保护措施，以保护整个服务网络及其基础服务。移除单个服务授权策略仍将首先执行服务网络策略，因此您可以确信能够识别进入服务网络的网络流量源，并阻止未来自之前定义的 AWS 主体的流量。

json{ Version 20121017 Statement [ { Effect Allow Principal { AWS [ arnawsiam111122223333role/app2TaskRole arnawsiam111122223333role/app3TaskRole arnawsiam111122223333role/EnvoyFrontendTaskRole arnawsiam111122223333role/app1TaskRole ] } Action vpclatticesvcsInvoke Resource } ]}

上述授权政策示例允许任何经过身份验证的请求，使用其中一个 IAM 角色 app1TaskRole、app2TaskRole、app3TaskRole 或 EnvoyFrontendTaskRole 向附加于服务网络的服务发起请求。在下一节中，您将看到如何将服务授权政策与服务网络授权政策结合使用。

服务授权策略

单个 VPC Lattice 服务可以有自己的政策，独立于服务网络政策。这种设计使用服务政策来展示用户与服务及服务与服务的访问控制。

json{ Version 20081017 Statement [ { Sid UserToService Effect Allow Principal { AWS [ arnawsiam111122223333role/EnvoyFrontendTaskRole ] } Action vpclatticesvcsInvoke Resource arnawsvpclatticeapsoutheast2111122223333service/svc123456789/ Condition { StringEquals { vpclatticesvcsRequestHeader/xjwtscopetestall true } } } { Sid ServiceToService Effect Allow Principal { AWS [ arnawsiam111122223333role/app2TaskRole ] } Action vpclatticesvcsInvoke Resource arnawsvpclatticeapsoutheast2111122223333service/svc123456789/ } ]}

上述授权策略是可以附加到 app1 VPC Lattice 服务的示例。该策略包含两个声明：

与标准的 IAM 策略一样，存在隐性拒绝，这意味着不会允许其他主体的访问。

调用者主体通过 VPC Lattice 的 SigV4 签名过程进行识别。这意味着通过使用提供给底层计算的身份，可以将网络流与服务身份关联，然后由 VPC Lattice 服务访问政策对其进行授权。

分散的开发

这种访问控制模型支持分散的开发和运营模型。因为服务网络授权策略脱离了对服务授权策略的依赖，服务授权策略可以由开发团队进行迭代，而不影响运营团队为整个服务网络设定的总体政策控制。

解决方案概览

我提供了一个 awssamples AWS CDK 解决方案，您可以部署以实现前述设计。

图 4：可部署的 CDK 解决方案

该 AWS CDK 解决方案部署了四个 Amazon ECS 服务，一个用于客户端到服务流的前端 Envoy 服务器，其余三个用于后端应用组件。图 4 显示了在应用程序内部域参数 applicationinternal 部署的解决方案。

后端应用组件是一个简单的 nodejs express 服务器，它将以 JSON 格式打印请求内容并执行服务间调用。

为了支持该解决方案，还部署了一些其他基础设施组件：

Envoy 和应用组件的代码可以在 latticesoln/containers 目录下找到。

所有其他可部署基础设施的 AWS CDK 代码可以在 latticesoln/latticesolnstackpy 中找到。

前提条件

在您开始之前