Amazon Web Services ELB has permission to change DNS records by default?

Question

I'm creating an ECS (Elastic Container Service) service on AWS. For that service, I need to supply an application load balancer. The default role for it is the following: AWSServiceRoleForECS. When I look at the policy for that role, then under Route 53, I see ChangeResourceRecordSets, which allows you to change the DNS records.

Questions:

1) Should I be worried that my application load balancer has the ability to change DNS records? Is there any way for a malicious developer inside my company to exploit this? Because for example, if your ec2 permissions are too loose, and you give a developer with otherwise limited permissions ssh access to your instance, then he can use the loose permissions of the ec2 instance to wreak havoc.

2) If there's no way to exploit loose permissions in ELB, then why have them at all? Or in other words, why would giving it admin privileges, for example, be a bad idea?

Answer 1

There are several roles involved in the ECS service, the one you are asking about AWSServiceRoleForECS is a specific type of IAM Role called a Service-Linked Role: https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html

This type of Role allows AWS services to make changes to your account on your behalf. (By default AWS do not have permissions to make any changes to your account) To use some of their services you need to grant them permissions e.g. to modify loadbalancers to add your container services.

The key portion of the role in this case is the "Trust Relationship" which defines who is allowed to assume the role. In the case of AWSServiceRoleForECS the only trusted entity is ecs.amazonaws.com. This means that only the ECS service can access the permissions granted by the role. While this does have some risk, if you cannot trust the ECS service to make changes on your behalf then it is arguable that you should not be using such a managed service in the first place.

To answer your questions directly:

1) Your ALB does not have any permissions, this role is granted to ECS to allow it to manage ALBs for you. The only exploit that somebody within your organisation could do is via valid ECS operations that require ECS to make changes. Its unlikely there are any useful avenues here that are a worry. But you should be practising minimal permissions on ECS and all other services for your users.

2) Amazon manage the policies on service linked roles to give themselves enough permissions to do what they need, if new features were added they would update the policy. They could give all of their services admin permissions but this would be lazy and unnecessary and increase the risks in the event of both accidents (bugs) and compromises.