我们正在处理为使用AWS CodePipeline构建并部署到ECS的应用程序提供构建时间和运行时机密的问题。
最终,我们的愿景是为每个应用程序创建一个通用管道,以实现以下目标:
以下是手头的问题:
除了一些警告:
我们已考虑使用credstash等工具来帮助管理凭据。此解决方案要求CodeBuild和ECS任务实例都能够使用AWS CLI。为了避免改组更多凭据,我们认为最好将特权角色分配给需要使用AWS CLI的实例。这样,CLI可以从实例元数据
中的角色推断凭据考虑到这些限制,我们试图设法管理我们的秘密。对于每个应用程序,我们创建一个管道。使用Cloudformation模板,我们创建:
4资源:
3个角色:
CodePipeline的CodeBuild步骤假定CodeBuildRole允许它从凭证表中读取构建时间机密。 CodeBuild然后构建项目并生成一个Docker Image,它将其推送到ECR。最后,部署步骤使用Cloudformation模板和项目公共存储库中存在的附带参数文件创建ECS服务ECS任务定义包括假设ECSTaskRole允许任务从凭证表读取运行时机密并提取所需图像来自ECR。
Here is a simple diagram of the AWS resources and their relationships as stated above
我们目前提出的解决方案存在以下问题:
是否有一种更为完善的方式来传递我们可能忽略的CodePipeline中的秘密,或者这是我们能够获得的最佳方式?
答案 0 :(得分:3)
三个想法:
AWS Secret Manager AWS Secrets Manager可帮助您保护秘密,以访问应用程序,服务和IT资源。您可以在整个生命周期内轮换,管理和检索数据库凭据,API密钥和其他秘密。
AWS Parameter Store可以通过细粒度访问来保护访问密钥。此访问权限可以基于ServiceRoles。
ECS通过以下模式提供对ServiceRole的访问:
build:
commands:
- curl 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI | jq 'to_entries | [ .[] | select(.key | (contains("Expiration") or contains("RoleArn")) | not) ] | map(if .key == "AccessKeyId" then . + {"key":"AWS_ACCESS_KEY_ID"} else . end) | map(if .key == "SecretAccessKey" then . + {"key":"AWS_SECRET_ACCESS_KEY"} else . end) | map(if .key == "Token" then . + {"key":"AWS_SESSION_TOKEN"} else . end) | map("export \(.key)=\(.value)") | .[]' -r > /tmp/aws_cred_export.txt
- chmod +x /tmp/aws_cred_export.txt
- /aws_cred_export.txt && YOUR COMMAND HERE
如果您提供给CodeBuild任务的ServiceRole有权使用参数存储键,那么您应该很高兴。
快乐狩猎和希望这有助于
答案 1 :(得分:0)
在较高级别,您可以使用细化权限(这听起来像您尝试做的那样)或使用多个AWS账户来隔离单个AWS账户中的应用程序。这本身既不对或错,但我倾向于支持单独的AWS账户而不是管理细化权限,因为您的起始位置是完全隔离的。