在 Amazon Redshift Serverless 中定义向联合用户授予的数据库角色 - Amazon Redshift
定义数据库角色 定义授予联合用户的数据库角色的使用场景其他资源

在 Amazon Redshift Serverless 中定义向联合用户授予的数据库角色

当您属于某个组织时，您会具有一系列关联的角色。例如，您的工作职能有不同的角色，可能是程序员和经理。您的角色决定了您可以访问哪些应用程序和数据。大多数组织使用身份提供者（例如 Microsoft Active Directory）向用户和组分配角色。组织越来越多地使用角色来控制对资源访问权限，因为这样就不必过多地管理单个用户。

最近，Amazon Redshift Serverless 中引入了基于角色的访问控制。例如，使用数据库角色，您可以安全访问架构或表等数据和对象。或者，您可以使用角色来定义一组提升的权限，例如用于系统监控或数据库管理员的权限。但是，在向数据库角色授予资源权限后，还有一个额外步骤，即将组织的用户角色连接到数据库角色。您可以通过运行 SQL 语句，向每个用户在初次登录时分配其数据库角色，但这需要完成大量的工作。一种更简单的方法是定义要授予的数据库角色，然后将这些角色传递给 Amazon Redshift Serverless。这样做的好处是简化初始登录流程。

您可以使用 GetCredentials 将角色传递给 Amazon Redshift Serverless。当用户首次登录 Amazon Redshift Serverless 数据库时，会创建关联的数据库用户并将其映射到匹配的数据库角色。本主题详细介绍了将角色传递给 Amazon Redshift Serverless 的机制。

传递数据库角色主要用于几个使用场景：

  • 当用户通过第三方身份提供者（通常配置了联合身份验证）登录并通过会话标签传递角色时。

  • 当用户通过 IAM 登录凭证登录时，他们的角色通过标签键和值传递。

有关基于角色的访问控制的更多信息，请参阅基于角色的访问控制 (RBAC)。

定义数据库角色

在将角色传递给 Amazon Redshift Serverless 之前，您必须在数据库中配置数据库角色，并向这些角色授予对数据库资源的相应权限。例如，在一个简单的场景中，您创建了一个名为 sales 的数据库角色，并授予其访问权限来查询包含销售数据的表。有关如何创建数据库角色和授予权限的更多信息，请参阅 CREATE ROLE 和 GRANT。

定义授予联合用户的数据库角色的使用场景

这些部分概述了几个使用场景，在这些使用场景中，将数据库角色传递给 Amazon Redshift Serverless 可以简化对数据库资源的访问。

使用身份提供者登录

第一个用使用场景设您的组织在某个身份和访问管理服务中具有用户身份。此服务可以为云端，例如 JumpCloud 或 Okta，也可以是本地服务，例如 Microsoft Active Directory。此时的目标是在用户使用 JDBC 等客户端登录查询编辑器 V2 这样的客户端时，自动将用户的角色从身份提供者映射到您的数据库角色。要进行此设置，您必须完成一些配置任务。这些功能包括：

  1. 使用信任关系配置与身份提供者 (IdP) 的联合身份验证集成。这是先决条件。当您完成了此设置时，身份提供者负责通过 SAML 断言对用户进行身份验证并提供登录凭证。有关更多信息，请参阅将第三方 SAML 解决方案提供商与 AWS 集成。您还可以在使用 Active Directory Federation Services (AD FS) 对 Amazon Redshift 查询编辑器 V2 进行联合身份访问或者使用 Okta 对 Amazon Redshift 查询编辑器 v2 进行联合身份单点登录访问。

  2. 角色还必须具有以下策略权限：

    • GetCredentials – 提供凭证用于临时授权登录 Amazon Redshift Serverless。

    • sts:AssumeRoleWithSAML – 提供一种机制，用于将企业身份存储或目录绑定到基于角色的 AWS 访问。

    • sts:TagSession – 在身份提供者主体上，对标记会话执行操作的权限。

    在此例中，对于已经通过 SAML 身份验证响应进行了身份验证的用户，AssumeRoleWithSAML 返回一组安全凭证。此操作提供了一种机制，用于将身份存储或目录绑定到基于角色的 AWS 访问，而无需用户特定的凭证。对于具有 AssumeRoleWithSAML 权限的用户，身份提供者负责管理用于传递角色信息的 SAML 断言。

    作为最佳实践，我们建议将权限策略附加到 IAM 角色，然后根据需要将其分配给用户和组。有关更多信息，请参阅 Amazon Redshift 中的 Identity and Access Management。

  3. 您可以使用冒号分隔的角色值配置标签 RedshiftDbRoles，格式为 role1:role2。例如，manager:engineer。这些值可以从身份提供者中配置的会话标签实施来检索。SAML 身份验证请求以编程方式传递角色。有关传递会话标签的更多信息，请参阅在 AWS STS 中传递会话标签。

    如果您传递的角色名在数据库中不存在，则忽略该名称。

在此使用场景中，当用户使用联合身份登录时，他们的角色将通过会话标签键和值在授权请求中传递。随后，在授权后，GetCredentials 会将角色传递给数据库。成功连接后，系统将映射数据库角色，然后用户就可以执行与其角色对应的数据库任务。该操作的关键部分是在初始授权请求中，向角色授予了 RedshiftDbRoles 会话标签。有关传递会话标签的更多信息，请参阅 使用 AssumeRoleWithSAML 传递会话标签。

使用 IAM 凭证登录

在第二个使用场景中，可以为用户传递角色，他们可以通过 IAM 凭证访问数据库客户端应用程序。

  1. 对于在这种情况下登录的用户，必须向其分配对以下操作的策略权限：

    • tag:GetResources – 返回与指定标签关联的带标签资源。

    • tag:GetTagKeys – 返回当前正在使用的标签键。

      作为最佳实践，我们建议将权限策略附加到 IAM 角色，然后根据需要将其分配给用户和组。有关更多信息，请参阅 Amazon Redshift 中的 Identity and Access Management。

  2. 允许权限还需要访问数据库服务，例如 Amazon Redshift Serverless。

  3. 对于此使用场景，请在 AWS Identity and Access Management 中为您的角色配置标签值。您可以选择编辑标签，然后创建名为 RedshiftDbRoles 的标签键，以及附带的包含角色的标签值字符串。例如，manager:engineer。

当用户登录时，他们的角色会被添加到授权请求中并传递到数据库。其角色映射到现有的数据库角色。

其他 资源

如使用场景中所述，您可以配置 IdP 与 AWS 之间的信任关系。有关详细信息，请参阅使用信赖方信任配置您的 SAML 2.0 IdP 并添加声明。