Kno*_*SQL 3 aws-lambda amazon-kms aws-codepipeline aws-secrets-manager 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 }等等。这已经完成了。
us-east-1 SecretsManager上述所有阶段/环境中的 lambda 代码现在都需要更改为通过客户端获取Account-1 中存在的秘密键值对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'])
Run Code Online (Sandbox Code Playgroud)
各个帐户和区域(即环境)中的所有 lambda 表达式都将具有与上述完全相同的代码,因为需要从us-east-1.
cdk代码以促进这一点?代码管道中的代码部署如何获得导入此自定义kms密钥的权限,并SecretManager' secret通过 cdk 管道创建的 lambda 为跨帐户访问应用正确的权限?有人可以指点一下吗?
这有点棘手,因为 CloudFormation 以及 CDK 不允许跨帐户/跨阶段引用,因为据我了解,CloudFormation 导出不能跨帐户工作。所有这些“集中”资源模式都属于该类别 - 即。一个帐户(或 CDK 中的某个阶段)中的资源被其他阶段引用。
如果资源是在 CDK 上下文之外创建的(例如通过控制台),那么您也可以对名称/arns/等进行硬编码。整个 CDK 代码中使用它的地方,这应该足够了。
如果创建也在 CDK 代码本身中完成(即由 CloudFormation 管理 - 不通过控制台/aws-cli 等单独完成),那么它会变得更有趣。在这种情况下,很多时候您不会“知道”确切的 ARN,因为物理 ID 将由 CloudFormation 生成,并且可能是 ARN 的一部分。即使您自己影响物理 ID(例如通过对存储桶名称进行硬编码)也可能无法在所有情况下解决该问题。例如。KMS ARNs并将SecretManager ARNsunique-ids 或某种哈希值附加到ARN.
与其尝试解决所有问题,最好保持不变,并生成CFn它选择的任何随机名称/arn。要引用这些构造/ARN,只需将它们放入源/中央账户中的 SSM 参数中即可。据我所知,SSM 没有基于资源的策略。因此,另外在 cdk 中创建一个信任 cdk 代码中帐户的角色。完成后,不再需要维护 - 每次您向 CDK 添加新环境/帐户(此处假设其为 cdk 管道)时,您将创建的“循环”构造都会自动将新帐户添加到信任关系中。
现在您需要做的就是将此角色 arn 和 SSM 参数名称分发到其他阶段。选择显式角色名称和 SSM 参数。给定角色名的手动 ARN 构建非常简单。因此,将 CDK 代码周围的 SSM 参数分发到其他阶段(编译时字符串而不是引用)。AWSCustomResource在目标阶段,创建由 lambda 支持的自定义资源 ()AwsSdkCall以简单地承担此角色-arn 并进行 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', ... ], ...)
Run Code Online (Sandbox Code Playgroud)
然后在目标阶段:
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')
Run Code Online (Sandbox Code Playgroud)
现在,对收集到的工件执行您想要的任何操作,包括将它们作为环境变量提供给您的主服务 lambda(将在部署时解析)。
请记住,它们都是令牌,并且仅在部署时解析,但这对于任何资源都是如此,无论是否通过自定义资源,这都不重要。
这是一个适用于任何情况的通用模式。
| 归档时间: |
|
| 查看次数: |
6503 次 |
| 最近记录: |