允许秘密管理器中的秘密用于特定 AWS 账户中的所有 lambda 函数

q_k*_*kim 3 amazon-web-services aws-lambda aws-secrets-manager

我希望拥有一个可供 AWS 账户中具有不同角色的所有 lambda 访问的秘密。一种选择是附加一个允许所有 lambda 访问机密的策略,但考虑到我们有大量 lambda,我想知道是否可以使用机密管理器中的资源权限执行相反的操作。

我已将以下策略附加到该秘密中。

{
  "Version" : "2012-10-17",
  "Statement" : [ {
    "Effect" : "Allow",
    "Principal" : {
      "Service" : "lambda.amazonaws.com"
    },
    "Action" : "secretsmanager:GetSecretValue",
    "Resource" : "arn:aws:secretsmanager:us-east-1:{AWS_ACCOUNT_ID}:secret:dummy-secret-46DfjO",
    "Condition" : {
      "StringEquals" : {
        "aws:sourceAccount" : "{AWS_ACCOUNT_ID}"
      }
    }
  } ]
}
Run Code Online (Sandbox Code Playgroud)

我希望以下策略允许读取 AWS_ACCOUT_ID 中的所有 lambda,但我仍然收到以下错误:

错误 | 尝试从 Secrets Manager 读取 API 密钥时出错:Secrets Manager 读取错误:AccessDeniedException:用户:arn:aws:sts::AWS_ACCOUNT_ID:assumed-role/dummy-role-name 无权执行:secretsmanager:GetSecretValue 对资源: arn:aws:secretsmanager:us-east-1:AWS_ACCOUNT_ID:secret:dummy-secret-46DfjO 因为没有基于身份的策略允许 Secretsmanager:GetSecretValue 操作

我在这里缺少什么?

Unb*_*ess 6

Lambda 函数利用 IAM 执行角色 ( dummy-role-name)。这意味着当根据基于资源的秘密策略评估权限时,不存在服务主体 ( lambda.amazonaws.com),而是存在假定角色会话主体。

如文档中所述,该主体的语法为:

"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }

其中role-session-name对应于 lambda 函数的名称。

因此,您的基于资源的政策将是:

{
  "Version" : "2012-10-17",
  "Statement" : [ {
    "Effect" : "Allow",
    "Principal": { 
      "AWS": "arn:aws:sts::AWS_ACCOUNT_ID:assumed-role/dummy-role-name/role-session-name" 
    },
    "Action" : "secretsmanager:GetSecretValue",
    "Resource" : "arn:aws:secretsmanager:us-east-1:{AWS_ACCOUNT_ID}:secret:dummy-secret-46DfjO"
  } ]
}
Run Code Online (Sandbox Code Playgroud)

由于您提到您希望多个 lambda 能够读取此机密,因此您必须更改策略以允许从其他 lambda 函数检索机密。


或者,您可以完全放弃基于资源的策略并利用基于身份的策略。这需要您修改dummy-role-name角色以包含允许该操作的策略secretsmanager:GetSecretValue

如果您有许多 lambda 函数,这可能是一个更好的解决方案,因为您可以让每个 lambda 函数拥有自己的角色和自己的细粒度权限。这比必须为所有 lambda 管理单个基于资源的策略更容易。

您可以在此处详细了解基于身份的策略和基于资源的策略之间的差异: https: //docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html