CDK管道 https://aws.amazon.com/blogs/developer/cdk-pipelines-continuous-delivery-for-aws-cdk-applications/非常棒，特别适合跨账户部署。它使开发人员能够根据自己的喜好为其应用程序定义和自定义 CI/CD 管道。
但为了保持 SoC 兼容，我们需要确保验证/强制执行如下必要的控制
- 手动审批阶段应该存在在跨账户部署到生产的阶段之前
- 不允许绕过开发/登台环境直接部署到生产
- 测试用例（单元测试/集成测试）和信息安全测试应在部署之前通过
我知道上述事情在 CDK Pipelines 中实现起来很简单，但我不太确定如何确保每个 CDK Pipeline 始终符合这些标准.
我可以想到以下解决方案
- 分支限制 - 合并到主分支（CDK 管道监控的分支）应受到限制，并且仅允许通过拉取请求
- 测试 - 添加单元测试或集成测试，以验证生成的云形成模板是否具有特定的资源/属性
- 创建一个标准生产阶段，定义所有必要的控件，并将其包装在一个库中，如果开发人员想要部署到生产环境，则需要在 CDK 管道的定义中使用该库
但如何以自动化方式实施上述控制呢？开发人员可以选择绕过上述控制，只需在定义管道时不指定它们即可。我们不想依赖审批者手动检查这些事情。
总而言之，问题是 - 在使用 CDK 管道时，如何为开发人员提供设计 CI/CD 解决方案时最大的可定制性和自由度，同时确保以自动化方式验证和执行 SoC 限制和强制控制？
开放策略代理可能有助于根据管道中的自定义策略检查基础设施。
https://aws.amazon.com/blogs/opensource/realize-policy-as-code-with-aws-cloud-development-kit-through-open-policy-agent/ https://aws.amazon.com/blogs/opensource/realize-policy-as-code-with-aws-cloud-development-kit-through-open-policy-agent/
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
