我有一个针对AWS上的Terraform配置部署。当使用有权执行任何操作的IAM用户(即{actions: ["*"], resources: ["*"]}
。
为使此Terraform配置的应用程序自动化,我想确定最初应用配置并影响后续更改所需的最小权限集。我特别想避免在政策中授予过分的权限,例如{actions: ["s3:*"], resources: ["*"]}
。
到目前为止,我只是运行terraform apply
直到出现错误。我查看输出或terraform日志输出,以查看失败的API调用,然后将其添加到部署用户策略中。 EC2和S3特别令人沮丧,因为操作的名称似乎不一定与API方法名称一致。我花了几个小时用简单的方式告诉我我要走多长时间。
是否有更有效的方法?
如果Terraform告诉我我需要什么许可/动作,那真是太好了,但这是Hashicorp最好的产品增强功能。
答案 0 :(得分:21)
这是另一种方法,类似于上面所说的,但是没有涉及CloudTrail-
TF_LOG=trace terraform apply --auto-approve &> log.log
cat log.log | grep "DEBUG: Request"
您将获得所有使用的AWS操作的列表。
答案 1 :(得分:3)
虽然我仍然相信这种超级严格的政策会带来持续的痛苦并可能会扼杀生产力(但可能取决于项目),但现在有一个工具可以做到这一点。
iamlive 使用 AWS 开发工具包的客户端监控功能根据执行的 API 调用创建最小策略。由于 Terraform 使用 AWS 开发工具包,这也适用于此。
与我之前(并接受)的回答相比,iamlive 甚至应该正确执行实际的 IAM 操作,这些操作不一定与 API 调用 1:1 匹配(并且会被 CloudTrail 记录)。
答案 2 :(得分:1)
由于我想没有完美的解决方案,因此请把这个答案当作我脑力激荡的结果。至少对于初始权限设置,我可以想象以下内容:
首先允许所有内容,然后处理CloudTrail日志以查看在terraform apply
/ destroy
周期中进行了哪些API调用。
然后,您更新IAM策略以完全包括这些调用。
答案 3 :(得分:0)
我处理的方法是,首先允许该服务的所有权限(*),然后在不需要时拒绝其中的某些权限。
例如
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSpecifics",
"Action": [
"ec2:*",
"rds:*",
"s3:*",
"sns:*",
"sqs:*",
"iam:*",
"elasticloadbalancing:*",
"autoscaling:*",
"cloudwatch:*",
"cloudfront:*",
"route53:*",
"ecr:*",
"logs:*",
"ecs:*",
"application-autoscaling:*",
"logs:*",
"events:*",
"elasticache:*",
"es:*",
"kms:*",
"dynamodb:*"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "DenySpecifics",
"Action": [
"iam:*User*",
"iam:*Login*",
"iam:*Group*",
"iam:*Provider*",
"aws-portal:*",
"budgets:*",
"config:*",
"directconnect:*",
"aws-marketplace:*",
"aws-marketplace-management:*",
"ec2:*ReservedInstances*"
],
"Effect": "Deny",
"Resource": "*"
}
]
}
如果不需要terraform或公司不使用某些AWS服务,则可以在“拒绝”会话中轻松调整列表。
答案 4 :(得分:-1)
您尝试的方法在云技术中有点不寻常。您可以在具有EC2 IAM配置文件的EC2实例上运行terraform,而不是对运行API调用的terraform用户进行精细控制,该实例允许EC2 IAM配置文件本身使用正确的AWS服务权限集调用API。
每个调用都针对特定的API端点。如果您推送更新,则在应用期间应用的某些Terraform操作将有所不同。您还需要知道在修改操作期间在适当位置更新资源时会发生什么。
与其将API密钥限制为特定细节,不如让它有更多的回旋余地;如果它需要创建和销毁EC2,请让其具有EC2完整权限,也许有条件限制于帐户级别或VPC。