AWS 为什么要向 Secret Store ARN 添加 uid？

Question

当我在 AWS 中创建秘密存储时，我讨厌它，它会在 ARN 末尾添加一个随机 uid。 示例：

arn:aws:secretsmanager:us-east-1:xxxxxxxx:secret:secrets-store-development-k8s-klbiCG

这会弄乱 Terraform 模板，并且每次需要为每个环境创建 ENV 变量时都会让我感到畏缩。 请解释一下为什么要这样做，这样我就可以更放心。我会把我的善缘分享给你们作为交换

Answer 1

我认为这个实现细节没有公开记录，所以除非你找到在 AWS 工作的人来回答这个问题，否则你可能只能得到猜测。

免责声明：这是一个猜测，但我认为这是有道理的

正如该服务的名称所暗示的那样，Secrets Manager 旨在存储可能应严格控制和限制访问的秘密。 如果 ARN 是可预测的，您就会面临以下问题：

1. Alice 使用 ARN

   demo

    创建一个秘密 

   arn:aws:secretsmanager:(...):secret:demo
2. Alice 现在创建一个 EC2 实例并向其添加实例配置文件，这允许对由其 ARN 标识的演示密钥执行

   GetSecret

   操作

   arn:aws:secretsmanager:(...):secret:demo

3. 现在爱丽丝删除了该秘密，并且在所需的最短时间（7 天）后该秘密被删除。 Alice 没有更新 EC2 实例上的策略，因为授予对不存在的秘密的访问权限似乎不是一个大问题，或者她只是忘记了。
4. 大约一周后，Bob 出现并创建了一个密钥，他也决定将其称为

   demo

   ，并且由于 ARN 可预测，该密钥的 ARN 如下所示：

   arn:aws:secretsmanager:(...):secret:demo

5. 他不知道的是，爱丽丝一周前创建的实例现在可以访问鲍勃的秘密

对于旨在保护您的秘密的服务而言，这并不理想。

一个简单的解决方案是在秘密名称中添加随机后缀。

其他野外例子

在 AWS 中，IAM 和角色也存在类似的问题，他们选择以不同的方式实现它。

如果您设置创建角色，则为其添加信任关系。这种信任关系或承担角色策略定义了允许哪个主体承担此角色。

假设您设置了一个角色 Bob，然后创建了一个角色 Eve，并允许 Bob 角色的 ARN 代入角色 Eve。

现在您删除 Bob 角色并使用相同的名称重新创建它。 您会发现新的 Bob 角色与旧角色具有相同的 ARN。 当新的 Bob 角色尝试承担 Eve 角色时，他们会收到

AccessDenied

错误。 现在你挠头了，因为你很困惑。 您认为它应该有效，因为您将未更改的 ARN 添加到了信任策略中……或者您这样做了？

您打开信任策略，在代入角色策略中，您将看到一个神秘的 ID，而不是您之前放置在那里的 ARN。 这是因为在假设角色文档中，AWS 使用基础角色的物理 ID，而不是 ARN。 新鲍勃有一个新的物理 ID，这就是为什么这不起作用。 他们这样做正是出于我上面概述的原因。

Answer 2

对于需要 ARN 的人

按照这个doc，它表明我们可以使用通配符

?

代替最后6个随机字符（例如-

）来生成ARN

arn:aws:secretsmanager:Region:AccountId:secret:another_secret_name-??????

Answer 3

为了修复您的脚本和模板，可以动态获取 ARN。

以下是在 Terraform 中执行此操作的方法：

// dynamically acquire the opaque ARN based on the secret name
// implicit dependency: assumes that the secret already exists
data "aws_secretsmanager_secret" "mysecret" {
  name = "name-of-my-secret"
}

然后您可以通过以下方式访问 arn：

data.aws_secretsmanager_secret.mysecret.arn