[Issue report]Misuse of iaminstanceprofile in aws_ec2_iaminstance.json due to missing EC2InstanceProfile object

[xiaoen-liu]

Title: Misuse of iaminstanceprofile in aws_ec2_iaminstance.json due to missing EC2InstanceProfile object

Description:

In aws_ec2_iaminstance.json (found here), Cartography incorrectly assumes a direct connection between the iaminstanceprofile name and the IAM Role. This assumption is not accurate, as AWS uses IamInstanceProfile as a distinct resource that links to a single IAM Role.

The misuse happens because Cartography does not currently create a separate EC2InstanceProfile object, leading to incorrect modeling of the relationship between EC2 Instances and IAM Roles.

Expected behavior:

A separate EC2InstanceProfile object should be created and properly linked to EC2 Instances.
The relationship between the EC2InstanceProfile and its associated IAM Role should be accurately represented, avoiding the incorrect assumption about the name correlation.

[optional Relevant Links:]

here

[achantavy]

@xiaoen-liu - Thanks for reporting, this is a valid issue.

To make sure I understand, the current model is

EC2 Instance ←→ IAM Role

but it should be this instead:

EC2 Instance ←→ IamInstanceProfile ←→ IAM Role

Is this right?

[xiaoen-liu]

Yes, without having the IamInstanceProfile as a separate model, it's not possible to correctly establish the node relationships between EC2 Instances and IAM Roles.

[xiaoen-liu]

I would like to further clarify the cause of this confusion. The creation of an AWS Instance Profile and the binding of an Instance Profile to an IAM Role are two separate API calls: IAM.Client.create_instance_profile and IAM.Client.add_role_to_instance_profile. These APIs do not require the instance profile name and the IAM role name to have any relationship.

However, the AWS Console design makes it appear as though the instance profile name and the IAM role name are identical, which leads to confusion. This issue becomes more pronounced when using Infrastructure as Code (IaC) tools like Terraform, CloudFormation, or CDK, where instance profile names and IAM role names are often completely different.

This discrepancy can cause significant issues in environments where IaC is used to manage AWS resources, making it important to properly model the distinction between instance profiles and IAM roles.

[chandanchowdhury]

From what I understand and also from looking at our tfstate files

aws_iam_instance_profile -(one-to-one)→ role

while

role -(one-to-many)→ aws_iam_instance_profile 

So not sure what the issue issue!

@xiaoen-liu Are you able to provide an example please?

[achantavy]

Bumping up this issue and hoping to come to a fix soon.

This issue becomes more pronounced when using Infrastructure as Code (IaC) tools like Terraform, CloudFormation, or CDK, where instance profile names and IAM role names are often completely different.

Right, I can confirm this. If I run this cloudgoat scenario https://github.com/RhinoSecurityLabs/cloudgoat/tree/master/scenarios/cloud_breach_s3 and then run cartography on it, the created role node is not attached to the EC2 instance even though it is the instance's iaminstanceprofile. This is because cartography assumes that the iaminstanceprofile has the same name as the associated role, but that cloudgoat scenario shows that this is not always the case.

Relevant code:

• https://github.com/cartography-cncf/cartography/blob/1f39c2467a0d9e758978fb7773a3a792a4c0a5d7/cartography/data/jobs/analysis/aws_ec2_iaminstance.json#L6C174-L6C205
• https://github.com/RhinoSecurityLabs/cloudgoat/blob/992fb6ed1f1ceca7730bde09fbd427d199d067ca/scenarios/cloud_breach_s3/terraform/ec2.tf#L3
• https://github.com/RhinoSecurityLabs/cloudgoat/blob/992fb6ed1f1ceca7730bde09fbd427d199d067ca/scenarios/cloud_breach_s3/terraform/ec2.tf#L32

I'm not sure if splitting out the profile to a separate node is necessary as long as we can correctly handle that the iaminstanceprofile name can be different from the role name.

What do you think @xiaoen-liu?

[achantavy]

Another thing to consider: we need to call list-instance-profiles anyway because describe-ec2-instances does not tell us the role name. So, if we are calling list-instance-profiles, one argument is that we should represent it faithfully with its own node so that we can match existing patterns in the code. I'll get started on a fix shortly.