Question

注意：我已经查看了其他问题，并认为这是独一无二的，因为它特别涉及使用粘合作业的跨账户机密访问。

我遇到了一个问题，即在一个帐户中承担服务角色的粘合作业无法访问存储在另一个帐户中的机密，尽管我认为我的政策应该允许这样做。

我看到的错误（包含已编辑的值）：An error occurred (AccessDeniedException) when calling the GetSecretValue operation: Access to KMS is not allowed. This version of secret is not encrypted with the current KMS key.

问题

下面的设置是什么导致权限失败？

现状图

我对需要做的事情的理解

基于 the AWS docs 和 2018 blog post，我认为我们必须做的是：

添加有关机密的策略以允许访问服务角色
在 CMK 上添加策略以允许服务角色解密
添加关于服务角色的策略以允许访问机密
添加关于服务角色的策略以允许 CMK 解密

现行政策

保密政策

{
  "Version" : "2012-10-17",
  "Statement" : [ {
    "Effect" : "Allow",
    "Principal" : {
      "AWS" : "arn:aws:iam::GLUE_ACCOUNT:role/GLUE_SERVICE_ROLE"
    },
    "Action" : "secretsmanager:GetSecretValue",
    "Resource" : "*",
    "Condition" : {  
      "ForAnyValue:StringEquals" : {
        "secretsmanager:VersionStage" : "AWSCURRENT"
      }
    }
  } ]
}

CMK 政策

请注意，下面经过编辑的 SECRET_NAME 包含 AWS 在 ARN 中附加的几个字符，我们似乎需要包括这些字符。

{
    "Sid": "AllowUseOfTheKey",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::GLUE_ACCOUNT:role/GLUE_SERVICE_ROLE"
    },
    "Action": ["kms:Decrypt","kms:DescribeKey"], 
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "kms:ViaService": "secretsmanager.us-east-1.amazonaws.com"
        },
        "StringLike": {
            "kms:EncryptionContext:SecretARN": "arn:aws:secretsmanager:us-east-1:SECRET_ACCOUNT:secret:SECRET_NAME"
        }
    }
}

Glue 帐户中附加到 Glue 服务角色的政策声明

{
    "Sid": "AllowGetSecretValue",
    "Effect": "Allow",
    "Action": [
        "secretsmanager:GetSecretValue"
    ],
    "Resource": [
        "arn:aws:secretsmanager:us-east-1:SECRET_ACCOUNT:secret:SECRET_NAME"
    ]
},
{
    "Sid": "AllowKMSDecrypt",
    "Effect": "Allow",
    "Action": [
        "kms:Decrypt"
    ],
    "Resource": [
        "arn:aws:kms:us-east-1:SECRET_ACCOUNT:key/CMK_KEY_ID"
    ]
},

关于服务角色的信任策略

只是为了确认胶水工作确实似乎有权承担服务角色：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "glue.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

可能的后续步骤

作为思想实验，我正在考虑执行以下操作，看看它是否有效：

删除机密策略中的条件
删除 CMK 策略中的条件
还将 kms:DescribeKey 添加到服务帐户政策中，但我认为这不会解决问题。

Answer 1

有时会遇到这些涉及到的问题，尽管我尽了最大努力，但在我提供的信息之外找到了回答问题的信息。

解决方案有两个：

作为原始问题一部分的授权错误根本不是由于身份验证访问造成的。这是因为使用 boto3 的代码指定了密钥的名称而不是完整的 ARN。当然，机密管理员不会神奇地知道机密在不同的帐户中。
- 在这种情况下，令人惊讶的是，AWS 抛出了一个未经授权的异常，而不是未找到的异常，这对我们的工作非常有用。
修复此问题后，我们看到了当前存在于票证中的错误，与加密 CMK 相关。显然，当我们更改 CMK 时，我们没有选择使用该 CMK 自动创建新版本的密钥。授权用户只需简单地编辑和保存密钥，即可使用所选 CMK 对其进行重新加密并解决问题。

尽管有政策，胶水作业跨账户秘密访问失败

问题

现状图