简体   繁体   English

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

[英]Allow a secret in secret manager for all lambda functions in a particular AWS account

I'd like to have a secret that can be access by all lambdas with different roles in an AWS account.我想要一个 AWS 账户中具有不同角色的所有 lambda 都可以访问的秘密。 One option would be to attach a policy that allows access to the secret to all the lambdas, but given that we have large number of lambdas, I was wondering if I could do the reverse with resource permissions with in secrets manager.一种选择是附加一个允许访问所有 lambda 的秘密的策略,但鉴于我们有大量的 lambda,我想知道我是否可以在秘密管理器中使用资源权限进行反向操作。

I've attached the following policy to the secret.我已将以下政策附加到机密中。

{
  "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}"
      }
    }
  } ]
}

I'd expect the following policy to allow reads from all the lambdas that is in the AWS_ACCOUT_ID, but I am still getting following error:我希望以下策略允许读取 AWS_ACCOUT_ID 中的所有 lambda,但我仍然收到以下错误:

ERROR |错误 | Error while trying to read an API Key from Secrets Manager: Secrets Manager read error: AccessDeniedException: User: arn:aws:sts::AWS_ACCOUNT_ID:assumed-role/dummy-role-name is not authorized to perform: secretsmanager:GetSecretValue on resource: arn:aws:secretsmanager:us-east-1:AWS_ACCOUNT_ID:secret:dummy-secret-46DfjO because no identity-based policy allows the secretsmanager:GetSecretValue action尝试从 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 操作

What am I missing here?我在这里错过了什么?

It appears that your lambda function is leveraging an IAM execution role ( dummy-role-name ).您的 lambda function 似乎正在利用 IAM 执行角色 ( dummy-role-name )。 This actually implies that when the permissions are evaluated against the resource-based policy of the secret, there is no service principal ( lambda.amazonaws.com ), but instead there is an assumed-role session principal.这实际上意味着当根据基于资源的秘密策略评估权限时,没有服务主体 ( lambda.amazonaws.com ),而是有一个假定角色 session 主体。

As outlined in the documentation , the syntax for this principal is:文档中所述,此主体的语法是:

"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" } “委托人”:{“AWS”:“arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name”}

where the role-session-name corresponds to the name of the lambda function.其中role-session-name对应于 lambda function 的名称。

So your resource-based policy would be:因此,您的基于资源的政策将是:

{
  "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"
  } ]
}

since you mentioned that you would like multiple lambdas to be able to read from this secret, you would have to change the policy to allow the secret retrieval from the other lambda functions.由于您提到您希望多个 lambda 能够读取此机密,因此您必须更改策略以允许从其他 lambda 函数检索机密。


Alternatively, you could ditch the resource-based policy entirely and leverage an identity-based policy.或者,您可以完全放弃基于资源的策略并利用基于身份的策略。 This would require you to modify the dummy-role-name role to include a policy that allows the secretsmanager:GetSecretValue action.这将要求您修改dummy-role-name角色以包含允许secretsmanager:GetSecretValue操作的策略。

This might be a better solution if you have many lambda functions, since you could have each lambda function have its own role with its own finegrained permissions.如果您有许多 lambda 函数,这可能是一个更好的解决方案,因为您可以让每个 lambda function 都有自己的角色和自己的细粒度权限。 This would be easier than having to manage a single resource-based policy for all of the lambdas.这比必须为所有 lambda 管理一个基于资源的策略要容易得多。

You can read more about the differences between identity-based and resource-based policies here: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html您可以在此处详细了解基于身份和基于资源的策略之间的区别: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 AWS Secret Manager 轮换 Lambda 在数据库秘密轮换时超时 - AWS Secret Manager Rotation Lambda is timing out on a DB secrets rotation AWS 秘密管理器不允许我为 RDS 只读副本创建秘密 - AWS Secret manager does not allow me to create a secret for a RDS read-replica Terraform AWS Redshift 和 Secret Manager - Terraform AWS Redshift and Secret Manager 如何从 lambda function 呼叫 Secret Manager - How to call secret manager from lambda function 如何从 terraform 中的跨区域 AWS Secret Manager 检索机密 - How to retrieve secret from cross region AWS Secret Manager in terraform 用于本地模拟功能的 Google Secret Manager 权限 - Google Secret Manager Permissions For Local Emulating of Functions AWS CLI Secrets Manager 创建密钥 - AWS CLI Secrets Manager Create Secret 如何在 GitLab CI/CD 期间从 AWS Secret Manager 检索密钥 - How to retrive secret from AWS Secret Manager during GitLab CI/CD 在 AWS 秘密管理器中存储 Ansible Vault 密码并在需要时使用它 - Storing Ansible Vault password in AWS secret manager and using it when required 将 google secret manager secret 挂载到 KubernetesPodOperator - Mount google secret manager secret to KubernetesPodOperator
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM