时间戳

首页 > 解决方案 > AWS-CDK：跨账户资源访问和资源参考

aws-lambda - AWS-CDK：跨账户资源访问和资源参考

问题描述

Secrets Manager我在 Account-1 中有一个秘密键值对us-east-1。这个秘密是使用客户管理的 KMS 密钥加密的——我们称之为KMS-Account-1。所有这些都是通过控制台创建的。

现在我们转向CDK. 我们有cdk.pipelines.CodePipeline哪个部署Lambda到多个阶段/环境 - 所以第一次到{ Account-2, us-east-1 }然后到{ Account-3, eu-west-1 } 等等。这已经完成了。

上面所有阶段/环境中的 lambda 代码现在需要更改为使用 Account-1 中存在的密钥-值对，方法us-east-1 SecretsManager是通过secretsmanager客户端获取它。该代码应该看起来像这样（python）：

client = boto3.session.Session().client(
    service_name = 'secretsmanager',
    region_name = 'us-east-1'
)
resp = client.get_secret_value(
    SecretId='arn:aws:secretsmanager:us-east-1:<ACCOUNT-1>:secret:name/of/the/secret'
)
secret = json.loads(resp['SecretString'])

各种帐户和区域（即环境）中的所有 lambda 将具有与上面完全相同的代码，因为需要从us-east-1.

  1. 首先，我希望这在概念上是可能的。是对的吗？
  2. 接下来如何更改cdk代码以促进这一点？代码管道中的代码部署将如何获得导入此自定义kms密钥SecretManager' secret的权限，并通过 cdk 管道创建的 lambda 应用正确的跨账户访问权限？

有人可以指点一下吗？

标签： aws-lambdaaws-cdkaws-codepipelineaws-secrets-manageramazon-kms

解决方案

这有点棘手，因为 CloudFormation，因此 CDK 不允许跨账户/跨阶段引用，因为据我了解，CloudFormation 导出不能跨账户工作。所有这些“集中”资源模式都属于这一类——即。其他阶段引用的一个帐户（或 CDK 中的阶段）中的资源。

如果资源是在 CDK 的上下文之外创建的（例如通过控制台），那么您不妨硬编码名称/arns/etc。在其使用的整个 CDK 代码中，这应该足够了。

  1. 对于能够保存基于资源的策略的资源，它更简单，因为您可以直接将跨账户访问权限附加到它们 - 同样，通过控制台脱机，因为无论如何您都是手动维护它。每次向管道添加阶段（帐户）时，您都需要转到资源并手动添加跨帐户权限。
  2. 对于没有基于资源的策略的资源，例如 SSM，事情有点迂回，因为您需要创建一个可以跨账户假定的角色，然后访问该资源。在这种情况下，您还必须单独维护 IAM 角色，并在向 CDK 管道添加阶段时手动将信任策略更新到其他账户。然后，像往常一样在 CDK 代码中对角色 arn 进行硬编码，在一些 CustomResource lambda 中假设它并使用它。

如果创建也在 CDK 代码本身中完成（即由 CloudFormation 管理 - 不是通过控制台/aws-cli 等单独完成），它会变得更有趣。在这种情况下，很多时候您不会“知道”确切的 ARN，因为物理 ID 将由 CloudFormation 生成并且可能是 ARN 的一部分。即使您自己影响物理ID（例如通过硬编码存储桶名称）也可能无法在所有情况下解决它。例如。KMS ARNs并将SecretManager ARNs唯一 ID 或某种散列附加到ARN.

与其尝试解决所有这些问题，不如保持不变，让其CFn生成它选择的任何随机名称/arn。然后要引用这些构造/ARN，只需将它们放入源/中央帐户的 SSM 参数中。SSM 没有我所知道的基于资源的策略。因此，另外在 cdk 中创建一个信任您的 cdk 代码中的帐户的角色。完成后，不再需要维护 - 每次您将新环境/帐户添加到 CDK 时（假设这里是 cdk 管道），您将创建的“循环”构造将自动将新帐户添加到信任关系中。

现在，您需要做的就是将此 role-arn 和 SSM Parameternames 分发到其他阶段。选择明确的角色名称和 SSM 参数。给定角色名的手动 ARN 构造非常简单。因此，将 CDK 代码周围的 SSM 参数和 SSM 参数分发到其他阶段（编译时间字符串而不是引用）。AWSCustomResource在目标阶段，创建由 lambda 支持的custom-resource(s) ( )AwsSdkCall以简单地承担此角色并进行 SDK 调用以检索 SSM 参数值。这些值可以是您无法轻易猜到的任何值，例如您的 KMS ARN、SecretManager 的完整 ARN 等。现在只需使用这些。

迂回的方式来做一件简单的事情，但到目前为止，我能做的就是让它工作。

#You need to maintain this list no matter what you do - so it's nothing extra
all_other_accounts = [ <list of accounts that this cdk deploys to> ]

account_principals = [iam.AccountPrincipal(a) for a in all_other_account]
role = iam.Role(
   assumed_by = iam.CompositePrincipal(*account_principals), #auto-updated as you change the list above
   role_name = some_explicit_name,
   ...
)
role_arn = f'arn:aws:iam::<account-of-this-stack>:role/{some_explicit_name}'

kms0 = kms.Key(...)
kms0.grant_decrypt(role)
# Because KMS also needs explicit resource policy even if role policy allows access to it
kms0.add_to_role_policy(iam.PolicyStatement(principals = [iam.ArnPrincipal(role_arn)], actions = ...))

kms1 = kms.Key(...)
kms1.grant_decrypt(role)
kms0.add_to_role_policy(... same as above ...)

secrets0 = secretsmanager.Secret(...) #maybe this is based off kms0
secrets0.grant_read(role)
secrets1 = secretsmanager.Secret(...) #maybe this is based off kms1
secrets1.grant_read(role)

# You can turn all this into a loop ofc.
ssm0 = ssm.StingParameter(self, '...', parameter_name = 'kms0_arn', string_value = kms0.key_arn, ...)
ssm0.grant_read(role)
ssm1 = ssm.StingParameter(self, '...', parameter_name = 'kms1_arn', string_value = kms1.key_arn, ...)
ssm1.grant_read(role)
ssm2 = ssm.StingParameter(self, '...', parameter_name = 'secrets0_arn', string_value = secrets0.secret_full_arn, ...)
ssm2.grant_read(role)
...

#Now simply pass around the role and ssm parameter names
for env in environments:
   MyApplicationStage(self, <...>, ..., role_arn = role_arn, params = [ 'kms0_arn', 'kms1_arn', ... ], ...)

然后在目标阶段：

for parm in params:
   fn = AwsSdkCall('ssm', 'get_parameter', { "Name": param }, ...)
   acr = AwsCustomResource(..., on_create = fn, on_update = fn, ...)
   collect['param'] = acr.get_response_field('Parameter.Value')

现在对收集的工件做任何你想做的事情，包括将它们作为环境变量提供给你的主服务 lambda（这将在部署时解决）。

请记住，它们都将是令牌并且仅在部署时解析，但任何资源都是如此，无论是否通过自定义资源，这都无关紧要。

这是一个适用于任何情况的通用模式。

（问这个问题的GitHub链接，我也在那里回答过）

推荐阅读