Amazon Secrets Manager 在 Amazon Data Firehose 中进行身份验证 - Amazon Data Firehose
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

亚马逊 Data Firehose 以前被称为亚马逊 Kinesis Data Firehose

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

Amazon Secrets Manager 在 Amazon Data Firehose 中进行身份验证

Amazon Data Firehose 与 Amazon Secrets Manager 之集成,可让您安全地访问您的密钥并自动轮换证书。这种集成允许 Firehose 在运行时从 Secrets Manager 检索密钥,以连接到前面提到的直播目的地并交付您的数据流。这样,无论是在还是 API 参数中,在直播创建工作流程中,您的密钥都不会以 Amazon Web Services Management Console 纯文本形式显示。它提供了一种安全的方法来管理您的密钥,并使您免于复杂的凭证管理活动,例如设置自定义 Lambda 函数来管理密码轮换。

有关更多信息,请参阅 Amazon Secrets Manager 《用户指南》

了解秘密

秘密可以是密码、一组凭证(如用户名和密码)、OAuth 令牌或以加密形式存储在 Secrets Manager 中的其他秘密信息。

对于每个目标,您必须以正确的 JSON 格式指定密钥值对,如下一节所示。如果您的密钥没有按照目的地正确的 JSON 格式,Amazon Data Firehose 将无法连接到您的目的地。

亚马逊 Redshift 预配置集群和亚马逊 Redshift 无服务器工作组的密钥格式

{ "username": "<username>", "password": "<password>" }

Splunk 的秘密格式

{ "hec_token": "<hec token>" }

Snowflake 的秘密格式

{ "user": "<user>", "private_key": "<private_key>", "key_passphrase": "<passphrase>" // optional }

HTTP 端点、Coralogix、Datadog、Dynatrace、Elastic、Honeycomb、Logz.io、Mon LogicMonitor goDB Cloud 和 New Relic 的秘密格式

{ "api_key": "<apikey>" }

创建密钥

要创建密钥,请按照《Amazon Secrets Manager 用户指南》创建 Amazon Secrets Manager 密钥中的步骤进行操作。

使用秘密

我们建议你使用存储凭证或密钥 Amazon Secrets Manager 来连接直播目的地,例如亚马逊 Redshift、HTTP 终端节点、Snowflake、Splunk、Coralogix、Datadog、Dynatrace、Elastic、Honeycomb、Logz.io、MongoDB Cloud 和 New Relic。 LogicMonitor

在创建 Firehose 直播时,您可以通过 Amazon 管理控制台使用 Secrets Manager 为这些目标配置身份验证。有关更多信息,请参阅 配置目的地设置。或者,您也可以使用CreateDeliveryStreamUpdateDestinationAPI 操作来配置 Secrets Manager 的身份验证。

Firehose 使用加密技术缓存机密,并在每次连接目的地时都使用这些机密。它每 10 分钟刷新一次缓存,以确保使用最新的凭据。

在直播生命周期中,你可以选择随时关闭从 Secrets Manager 检索密钥的功能。如果您不想使用 Secrets Manager 来检索机密,则可以改用用户名/密码或 API 密钥。

注意

尽管在 Firehose 中使用此功能无需支付额外费用,但您需要为访问和维护 Secrets Manager 付费。有关更多信息,请参阅Amazon Secrets Manager定价页面。

授予访问 Firehose 的访问权限以检索密钥

要让 Firehose 从中检索密钥 Amazon Secrets Manager,您必须向 Firehose 提供访问密钥所需的权限以及加密您的密钥的密钥。

使用 Amazon Secrets Manager 存储和检索密钥时,有几种不同的配置选项,具体取决于密钥的存储位置和加密方式。

  • 如果密钥与您的 IAM 角色存储在同一个 Amazon 账户中,并且使用默认 Amazon 托管密钥 (aws/secretsmanager) 进行加密,则 Firehose 担任的 IAM 角色只需要secretsmanager:GetSecretValue获得该密钥的权限即可。

    // secret role policy { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "Secret ARN" } ] }

    有关 IAM 策略的更多信息,请参阅权限策略示例 Amazon Secrets Manager

  • 如果密钥与角色存储在同一个账户中,但使用客户托管密钥 (CMK) 加密,则该角色同时需要secretsmanager:GetSecretValuekms:Decrypt权限。CMK 策略还需要允许 IAM 角色执行kms:Decrypt

    { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "Secret ARN" }, { "Effect": "Allow", "Action": "kms:Decrypt", "Resource": "KMSKeyARN" } ] }
  • 如果密钥存储在与您的角色不同的 Amazon 账户中,并且使用默认 Amazon 托管密钥进行加密,则无法进行此配置,因为当使用托管密钥加密密钥时,Secrets Manager 不允许跨账户访问。 Amazon

  • 如果密钥存储在不同的账户中并使用 CMK 加密,则 IAM 角色需要secretsmanager:GetSecretValue获得该密钥的kms:Decrypt权限和 CMK 的权限。该密钥的资源策略和其他账户中的 CMK 策略还需要允许 IAM 角色获得必要的权限。有关更多信息,请参阅跨账户访问

轮换秘密

轮换是指定期更新密钥。您可以配置 Amazon Secrets Manager 为按照您指定的时间表自动轮换密钥。这样,您就可以用短期机密替换长期机密。这有助于降低被泄露的风险。有关更多信息,请参阅《Amazon Secrets Manager 用户指南》中的轮换 Amazon Secrets Manager 密钥