Join Log in
Score:1
spinkus avatar Server

AWS IAM Roles: What is a trusted entity exactly?

de flag
spinkus

I have a role attached to a LaunchConfiguration for an EC2 instance, that gives the EC2 instance privs to do certain things like do Cloudwatch logs (the context isn't important to the question). In Cloudformation the Role looks like:

    Type: 'AWS::IAM::Role'
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
        - Effect: Allow
          Principal:
            Service: 'ec2.amazonaws.com'
          Action: 'sts:AssumeRole'
      Policies: ...

If I view the Role in AWS console, under "Trust relationships" it says "Trusted entities: The identity provider(s) ec2.amazonaws.com":

enter image description here

I assume the Cloudformation AssumeRolePolicyDocument.Principal.Service maps to the "Trusted Entity" in the console (which, as an aside, is a strange way to name things, because I read "Principal" as having a different meaning in IAM, but anyway ... ). I'm straining my brain trying to piece together what is going on. My questions are:

  1. What exactly is an IAM "trusted entity"?
  2. How is it the entity 'ec2.amazonaws.com' "assumes the role"? The concept of the service 'ec2.amazonaws.com' assuming the roll just doesn't click with me.
  3. In what sense is the entity 'ec2.amazonaws.com' is "providing identities"?
  4. Where can I find a full list of these so called trusted entities?
2342
1 + 0
Score:2
Tim avatar Server
gp flag
Tim
  1. A trusted entity is which service can assume any given role. If you make EC2 the trusted entity you can't assume the role to use the permissions, lambda can't assume the role, only an EC2 instance. Most services in AWS are given permissions by assuming roles. Many services can configure this automagically for you, which is common when people are learning AWS. When you're working in secure environments setting up roles and permissions becomes fairly critical. For example, if you give EC2 a role with admin permissions and someone compromises the instance, they effectively have admin rights into your AWS account, which is why you give all resources / roles least permissions.
  2. When you configure a resource like an EC2 instance or Lambda function (etc) you tell it what role to assume. That EC2 instance / function / etc then has the permissions associated with the role.
  3. This just means that an EC2 instance is allowed to assume that role. When an EC2 instance starts it identifies the role it wants to assume. IAM validates the role is allowed to assume that role and the instance is allowed to start.
  4. There's a list of AWS service principals here. When you hit "create role" in the console you get a list in trusted entities. When I need one to put into my CloudFormation I just click that then copy and paste it from the json.

The AssumeRolePolicyDocument specifies who can assume the role. I suspect you can specify multiple entities can assume a role, but in practice I write a role for each service.

You can think of IAM roles similar to roles people have. My role as "architect for company XYZ" give me permissions to enter the office, log into the system, that kind of thing. If I assume a role as say a policeman I have additional rights, such as going into a police station, arresting people, etc.

0 + 6
spinkus avatar
de flag
spinkus
That helps a lot thanks. Q3 is still a little bit of a mystery to me. The ec2.amazonaws.com service entity provides the instance ids? Or is it just that the ids in this case are within the realm of ec2, kind of like the police department provide the identities of its officers? I get the policeman, fireman, architect analogy, but I thought more it was my ec2 instance / policeman *itself* that assumed role not the ec2 service / police department. I just can't quite grasp the concept of the police dept assuming a role :/.
0
Reply
Tim avatar
gp flag
Tim
In the analogy the person assumes the role of policeman, the police department does not assume a role. In AWS the EC2 instance assumes the role, not the EC2 service. In the trusted entities you're telling AWS that individual instances / functions / etc within a service can assume a role, not that the service itself can assume a role.
0
Reply
Tim avatar
gp flag
Tim
It took me quite a while to really get my head around IAM, it is quite complex. After doing AWS associate and professional certification I had a pretty good idea, but it was only after I did security specialty and then actively used IAM every day as part of my work that I really fully understood it. Even now I get tripped up occasionally, with interactions between IAM policy, SCP, and service resource policies. Suggest you do some AWS training, Cloud Guru security specialty training covers this very well but start with architect associate.
0
Reply
spinkus avatar
de flag
spinkus
"... you're telling AWS that individual instances / functions / etc within a service can assume a role, not that the service itself can assume a role." OK that's how I intuitively saw it, but the IAM Console says "The following trusted entities can assume this role" then lists a service. And I've noticed sometimes the "trusted entity" *is* actually a user (for cross organisation account access roles).
0
Reply
spinkus avatar
de flag
spinkus
It's turning out to take me quite a long time too. I thought I more or less got it, but then the harder I look the more it falls apart :). I will get there. Thx.
0
Reply
Tim avatar
gp flag
Tim
The console wording isn't quite correct, it's the users / EC2 instances / lambda functions / etc that can assume roles. We use cross account roles extensively in some AWS Organisation where we have IAM user authentication. (This next bit is more advanced) In other organisations that are federated with an external identity provider like AD we use AWS SSO which creates roles in each accounts that users can assume.
1
Reply
glitchwizard avatar
br flag
glitchwizard
This was so helpful, thank you. I've been trying to figure out how to identify dormant roles and this helped me wrap my head around it pretty well. We have roles that are old, but not necessarily completely defunct, like they may be used every few years, so identifying them with only 400 days tracked by default isn't helpful considering they may be used every 700 days or so. This helps me identify which services may assume the roles based on their trusted entities.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.