为什么CodePipline需要KMS密钥？

Question

我制作了codepipeline将源代码从codeCommit构建ecr by cdk

在部署此CDK代码时，以某种方式以某种方式像This codepipeline-cdkmyNavirepomynavipelinefe7f8d68命名的键

是用kmms客户托管密钥

我不确定为什么要制作的，我不想使用它。

为什么或何处制作键？

const adminPipeline = new codepipeline.Pipeline(this, 'mynaviPipeline', {
  pipelineName: 'cdk-mynavi-pl',
});


const mynavi_cc_repo_name = 'cdk-mynavi-cc'
const mynavi_cc_repo = new codecommit.Repository(this,
  "mynavi-cc-repo",{
    repositoryName: mynavi_cc_repo_name,
    description:"for resizer repo"
})

const adminBuildProject = new codebuild.PipelineProject(this, 'adminBuildproject', {
  environment: {
    buildImage:codebuild.LinuxBuildImage.STANDARD_4_0,
    privileged:true, 
  },
  buildSpec: codebuild.BuildSpec.fromSourceFilename("./buildspec.yml")
});
const adminSourceOutput = new codepipeline.Artifact();
const adminSourceAction = new cdk.aws_codepipeline_actions.CodeCommitSourceAction({
  actionName: 'AdminSource',
  repository: mynavi_cc_repo,
  output: adminSourceOutput,
  trigger:  cdk.aws_codepipeline_actions.CodeCommitTrigger.POLL,
})

const dockerHubSecretArn = 'arn:aws:secretsmanager:ap-northeast-1:678100228231:secret:docker_login-TBFA5B';
const dockerHubSecret = secretsmanager.Secret.fromSecretCompleteArn(this, 'SecretFromCompleteArn', dockerHubSecretArn);

dockerHubSecret.grantRead(adminBuildProject)

cronEcrRepo.grantPullPush(adminBuildProject)
djangoEcrRepo.grantPullPush(adminBuildProject)
nginxEcrRepo.grantPullPush(adminBuildProject)

const adminBuildOutput = new codepipeline.Artifact();
const adminBuildAction = new cdk.aws_codepipeline_actions.CodeBuildAction({
  actionName: 'AdminCodeBuild',
  project: adminBuildProject,
  input: adminSourceOutput,
  outputs: [adminBuildOutput]
});

adminPipeline.addStage({
  stageName: "mynaviSource",
  actions: [adminSourceAction],
});
adminPipeline.addStage({
  stageName : "mynaviBuild",
  actions: [adminBuildAction]
});

Answer 1

它与REST 时的加密有关。

使用AWS KMS键在REST上加密Codepipeline中的数据。代码工件存储在客户拥有的S3存储桶中，并使用AWS托管密钥或客户托管密钥进行加密。

加密codepipline trifacts 默认启用。

如果您选择用于加密代码工件的默认选项，则CodePipeline使用AWS托管密钥。您无法更改或删除此AWS托管密钥。

您不能禁用加密，但是您可以选择如何加密工件。

好消息是，如果您使用默认选项，则不必管理加密键。

例如，可以在codepipeline控制台中选择：

更多在 AWS Codepipeline中的数据保护。

Answer 2

OP问为什么 CDK管道默认情况下使用了不需要的KMS 客户托管键，这在接受的答案中未直接解决。我将尝试在这里解决为什么。

由于无法更新或更换AWS托管密钥的策略，因此至少在两种情况下需要客户托管的密钥策略的灵活性：

1. 最少特权安全性： aws托管关键策略允许内部任何原则。相同的说法解密工件。在单个帐户中使用客户托管钥匙以更严格的控制权限是可选的，但它被认为是最佳实践。可以跳过，以避免额外的成本和管理麻烦。但是，人们可能会争辩说，使用最少特权的原则（POLP）对于不利用跨学会部署的困难边界的单个帐户部署更为重要。

2. 交叉计算部署：无法更新或替换以配置跨账户权限。因此，除了最少的特权安全外，需要客户托管密钥（或客户提供的密钥），以启用由于其可自定义的策略而启用任何交叉雅特人工访问。

鉴于这两种情况，CDK团队默认情况下希望配置最佳实践，CrossAccountkeys：True是管道的默认值也就不足为奇了。但是，对于那些在单个帐户非生产部署中尝试CDK并可能利用自由层的人来说，这些KMS键费用可以开始加起来。我认为这就是为什么CDK现在没有客户托管键的默认存储键的CDK帐户，除非您为其设置CLI标志。

OP并没有直接提及它，但是由于op在此评论所述设置CrossAccountkeys：False解决了问题，这意味着OP在一个帐户中工作。尽管这可能是可以的，例如在沙盒帐户中探索AWS的方便起见，但我建议在事情变得更加认真和更接近生产后，仍然会遇到最小的特权访问权限的麻烦。