Skip to the page
CloudArqStart free

What is <something>.amazonaws.com doing in my trust policy?

It is an AWS service, not an outside company, named so that the service can use the role you made for it.

You open a role and the trust policy has "Principal": { "Service": "lambda.amazonaws.com" }. No account number, no company name. Is that someone getting in?

Short answer. Not an outsider. It is an AWS service, and the policy says that service may use the role.

What a service principal is

AWS's Lambda page puts it this way:

the role's trust policy must specify the Lambda service principal (lambda.amazonaws.com) as a trusted service.

So the role exists for the service. You make a Lambda function, the function needs to act in your account, and the trust policy lets Lambda do that. The EventBridge Scheduler page says the same in other words:

This trust policy allows EventBridge Scheduler to assume the role on your behalf.

That is the reason it is not an outsider in the way a vendor account is. It is a part of AWS that you chose to use.

Ten services we looked up

We read the AWS documentation page for each service. These ten come from the 97 service principals our research covers, and they are not a ranking: our research does not count how common each one is, and 97 is not every service principal AWS has.

  • lambda.amazonaws.com: AWS Lambda
  • ec2.amazonaws.com: Amazon EC2
  • ecs-tasks.amazonaws.com: Amazon Elastic Container Service (tasks)
  • eks.amazonaws.com: Amazon Elastic Kubernetes Service
  • states.amazonaws.com: AWS Step Functions
  • codebuild.amazonaws.com: AWS CodeBuild
  • codepipeline.amazonaws.com: AWS CodePipeline
  • cloudformation.amazonaws.com: AWS CloudFormation
  • events.amazonaws.com: Amazon EventBridge
  • backup.amazonaws.com: AWS Backup

Odd shapes are still services. Not every principal is the service name with a prefix. Examples from our research: ops.apigateway.amazonaws.com (Amazon API Gateway), pods.eks.amazonaws.com (EKS Pod Identity) and ecs-tasks.amazonaws.com. Regional forms exist, such as codedeploy.<region>.amazonaws.com. The same principal can do two jobs: EKS's service-linked role and a cluster's own role both trust eks.amazonaws.com. One entry shows a China form, elasticmapreduce.amazonaws.com.cn.

The one case worth checking

A service principal in a trust policy can be narrowed with conditions. The only example in our research is the EKS Fargate Pod execution role (eks-fargate-pods.amazonaws.com), where the AWS page adds an aws:SourceArn condition on the Fargate profile.

AWS's own page on the confused deputy problem names the risk:

"The confused deputy problem arises when an actor uses the trust of an AWS service’s service principal to gain access to resources that they are not intended to have access to."

And what to do about it:

"We recommend using these condition keys whenever access to one of your resources is granted to an AWS service principal."

The keys are aws:SourceArn, aws:SourceAccount, aws:SourceOrgID and aws:SourceOrgPaths. Whether a service supports them is in that service's own documentation, the same page says.

What you can check first: does the role trust a service principal that you did not expect? A role you did not make, trusting a service you do not use, is worth a look.

What our research does not cover

AWS pages show no date, so a page may have changed since we read it. Eight of the 97 rest on a community list or a web search, not an AWS page, so we do not count them as confirmed. For a few services, we found no AWS page on the role they use.

What to do

  1. Read the Principal.Service string and find the service it names. Use the AWS page for that service.
  2. Ask whether you use that service. If you do, the role is expected.
  3. Look at the permissions on the role. A service principal does not mean the role is harmless; the role can still be too broad.
  4. Look for aws:SourceArn or aws:SourceAccount conditions on roles that matter to you, and ask AWS's page for that service whether it recommends one.
  5. If you do not use the service, find who made the role.

CloudArq reads the trust policies that let pipelines, partner accounts and sign-ins into your cloud without a password, and tells you in one sentence who each one actually lets in.

Sources