为什么建议在 AWS SecretsManager 中手动预置预先存在的密钥，而不是通过 CDK/Cloudformation？答案

【问题标题】：Why is it recommended to manually provision pre-existing secrets in AWS SecretsManager as opposed via CDK/Cloudformation?为什么建议在 AWS SecretsManager 中手动预置预先存在的密钥，而不是通过 CDK/Cloudformation？
【发布时间】：2022-01-26 00:41:43
【问题描述】：

引用自aws cdk docs：

如果您需要使用预先存在的密钥，推荐的方法是在 AWS SecretsManager 中手动预置密钥并使用 Secret.fromSecretArn 或 Secret.fromSecretAttributes 方法使其在您的 CDK 应用程序中可用

这是为什么呢？是不是因为把纯文本密码保存到代码中不太理想？

或者我们不希望秘密出现在 cloudformation 模板中？

【问题讨论】：

标签： amazon-cloudformation aws-cdk

【解决方案1】：

是的，是的。早期的 CDK 版本甚至不允许将文本值传递给 Secret 构造函数。我们only recently got secretStringBeta1: string 道具以及严厉警告：

强烈建议不要定义此字段并允许 SecretsManager 创建密钥值。秘密字符串（如果提供）将作为综合的一部分包含在 cdk 的输出中，并将出现在控制台的 CloudFormation 模板中。如果该值只是对另一个资源（或其属性之一）的引用，这可能是安全的（-ish），但如果该值是纯文本字符串，则任何有权访问 CloudFormation 模板（通过 AWS控制台、SDK 或 CLI）。

我们的 CDK 代码和生成的模板是 deterministic and version-controlled，如果使用明文机密，则会进一步增加泄露的风险。

编辑：根据@gshpychka 的评论，使用Secret.fromSecretArn 导入的安全替代方法是构造一个没有秘密值的新Secret。这将创建一个带有随机密码的密钥，您可以在控制台中进行部署后更改。这种方法有助于将密钥的生命周期与堆栈联系起来，并允许您在堆栈的上下文中设置其属性。

【讨论】：

值得一提的是，在 CDK 中创建秘密，然后在控制台中手动填充它们可能是个好主意。这样，您可以修改密钥的属性，例如资源策略和标签。
@gshpychka 使用这种方法，Cloudformation 不会将其检测为某种漂移吗？既然你在 CDK/CF 之外改变了它的状态？
@fedonev 我担心让秘密管理器通过 cdk 生成密码是不确定的。当我们拆除堆栈并重新启动它时，它将重置值，从而丢失原始秘密值。可以吗？
不，它不会检测到任何漂移。
@froi Horses 的课程。哪个选项“更好”取决于用例细节。