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

【问题标题】：Glue Job Cross-Account secret access failing despite policies尽管有政策，胶水作业跨账户秘密访问失败
【发布时间】：2021-07-22 20:50:27
【问题描述】：

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

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

我看到的错误（带有编辑值）：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 添加到服务帐户政策中，但我认为这不会解决问题。

【问题讨论】：

注意：我刚刚更新了错误消息的性质。我们的 Glue python 脚本没有使用秘密的完整 ARN，所以我们看到的错误是一个红鲱鱼。

标签： amazon-web-services boto3 amazon-iam aws-glue aws-secrets-manager

【解决方案1】：

正如这些涉及的问题有时会发生的那样，尽管我尽了最大努力，但在我提供的信息之外找到了用于回答问题的信息。

解决方案有两个：

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

【讨论】：