AWS recently introduced "service-linked roles" - a more secure way of delegating permissions to other AWS services. Trust policy of such roles cannot be modified and only the linked service can assume such role.
These roles are especially useful in AWS accounts where "powerful" services like CloudFormation, Elastic Beanstalk, etc. are used, but IAM admin wants to reduce chances of users/instances assuming traditional service roles.
I'm not sure whether this an enhancement to existing aws_iam_role
resource or best be treated as a new resource. While output of the API is the same Role object, API input parameters are different. It might be more straightforward for end users to create/import and configure this as a separate resource, especially since it cannot be attached to instance profile or assumed by principals other than AWS service.
Hi,
Any update on this?
Given the very different interface for CreateServiceLinkedRole
compared to the general CreateRole
, I think a new resource makes sense here. Ideally it'd export the attributes of the resulting role object using the same attribute names and types as aws_role
uses for input, so that interpolations for attributes of both will be as similar as possible.
resource "aws_iam_service_linked_role" "example" {
aws_service_name = "elasticbeanstalk.amazonaws.com"
}
resource "aws_iam_role_policy" "example" {
name = "example"
role = "${aws_iam_service_linked_role.example.name}"
policy = ...
}
output "role_arn" {
value = "${aws_iam_service_linked_role.example.arn}"
}
The Terraform team at HashiCorp is not currently working on this particular issue. It's likely that we'll get to it at some point since it's a good general UX improvement for using a lot of AWS services -- how to write working assume role policies is a very common question! However, if someone else has the time and motivation to work on this sooner we'd be happy to review a PR for it.
It should be noted that service-linked roles are automatically created. Also, in at least some cases (certainly, for aws_appautoscaling_target
), AWS also insists on overriding your choice of role and using the service-linked role instead. This has meant that newly created aws_appautoscaling_target
resources are appearing as tainted every time.
Cloudwatch events are affected as well:
does not create AWSServiceRoleForCloudWatchEvents.
terraform 0.11.2
I just ran into this issue trying to setup a new ecs service. I cannot assign a regular role to a new ecs service anymore, it requires a service linked role.
+1 to this, would be something really useful.
The initial aws_iam_service_linked_role
resource has been merged into master and will release with v1.15.0 of the AWS provider, likely in a week. 🎉
This has been released in version 1.15.0 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.
I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.
If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!
Most helpful comment
The initial
aws_iam_service_linked_role
resource has been merged into master and will release with v1.15.0 of the AWS provider, likely in a week. 🎉