<p>I think you may have this a little backwards.</p>
<p>S3 is a service that you may want to access with a role.  S3 would not be accessing anything, things access s3.</p>
<p>So, if you made IAM role <code>ABC</code>, you could set up policy to allow it to list and write to a specific S3 bucket, for example.</p>
<p>You could also make role <code>ABC</code> assume-able by another role.  In that case, you may have a server with default IAM role (instance profile) <code>XYZ</code> and the assume role policy can state that <code>XYZ</code> can assume <code>ABC</code>, which would then let it access S3.</p>
<p>Any entity is just one role at a time.  So, once your server assumed <code>ABC</code> from <code>XYZ</code>, it effectively is just <code>ABC</code>.</p>
<p>You can also assume roles from IAM users - but IAM users are generally bad practice as they are very losable.</p>
<p>Assuming a role is a very explicit operation, you have to do it on purpose.  Some programs may &quot;seem&quot; like they do it easily by configuration, but in reality if they are assuming a role, they are running very specific code for it, similarly to what you would do to assume the role from a command line.</p>
<h2>Example Tutorial</h2>
<p>Here is a decent AWS tutorial for assuming roles in a CLI to get familiar with it.</p>
<p><a href="https://aws.amazon.com/premiumsupport/knowledge-center/iam-assume-role-cli/" rel="nofollow noreferrer">https://aws.amazon.com/premiumsupport/knowledge-center/iam-assume-role-cli/</a></p>
<p>The final command looks like this:</p>
<pre><code>aws sts assume-role --role-arn \
&quot;arn:aws:iam::123456789012:role/example-role&quot; \
--role-session-name AWSCLI-Session
</code></pre>
<p>But that assumes role <code>arn:aws:iam::123456789012:role/example-role</code> is set up to allow your current role (whatever it is) to assume it.  Note that role assumption within an account only requires the target role to allow it, but role assumption between two AWS accounts requires the source and target role to be set upt o allow it.</p>

CC BY-SA 4.0
2022-05-31T00:53:18.723Z
The motivation for this question is S3 Inventory, where according to the docs the S3 principal is what's accessing resources: https://docs.aws.amazon.com/AmazonS3/latest/userguide/configure-inventory.html#configure-inventory-kms-key-policy
Simon Hardman
CC BY-SA 4.0
2022-05-31T01:56:23.817Z
Ah, interesting. I stand to learn something good here too then =). Thanks for clarifying!
John Humphreys
CC BY-SA 4.0
2022-05-31T07:07:31.563Z
@SimonHardman could you please update the question with this information on how you're using S3? I think it significantly changes the context.
Bruce Becker
CC BY-SA 4.0
2022-05-31T00:22:47.447Z
2022-05-31T00:22:47.447Z
John Humphreys
<p>There is a variety of ways how different services access an S3 bucket. What John Humphreys answer describes is the scenario where the access is performed by some user controlled code running in the same AWS account. Some other access patterns include:</p>
<ul>
<li><p>Delivering content through Cloudfront: There is something called an &quot;Origin Access Identity&quot; - a sort of Cloudfront specific role that can access the S3 bucket. This role cannot be assigned any policies itself, so you have to use the S3 bucket policy as an overlapping security layer to allow the policy access to the bucket (on top of any other access that exists).
An additional example would be a certain Wordpress plugin I have worked with that in the past required the S3 bucket and objects to be public. In this case the policy would have to be configured to be &quot;nothing but the Origin Access Identity&quot;</p>
</li>
<li><p>You could imagine a SaaS service that delivers something to your bucket, but without wanting to be restricted to how they do that. They may use EC2 now, but want to be free to deliver the data later by using Lambda or even S3 bucket replication. In this case, you would set up a policy that allows anything in the other AWS account to have write access to your bucket.</p>
</li>
<li><p>Some AWS Services have a default named role, for example if you use EC2 Lifecycle Manager, a role is created in your account called AWSDataLifecycleManagerDefaultRole. For this role to use a KMS key, the key needs to have a policy to allow access for this role.</p>
</li>
<li><p>While I have not used S3 inventory myself, if you look at the example policy linked from the service description: <a href="https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html#example-bucket-policies-use-case-9" rel="nofollow noreferrer">https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html#example-bucket-policies-use-case-9</a></p>
<pre><code>  {  
        &quot;Version&quot;: &quot;2012-10-17&quot;,
        &quot;Statement&quot;: [
          {
              &quot;Sid&quot;: &quot;InventoryAndAnalyticsExamplePolicy&quot;,
              &quot;Effect&quot;: &quot;Allow&quot;,
              &quot;Principal&quot;: {
                  &quot;Service&quot;: &quot;s3.amazonaws.com&quot;
              },
              &quot;Action&quot;: &quot;s3:PutObject&quot;,
              &quot;Resource&quot;: [
                  &quot;arn:aws:s3:::destinationbucket/*&quot;
              ],
              &quot;Condition&quot;: {
                  &quot;ArnLike&quot;: {
                      &quot;aws:SourceArn&quot;: &quot;arn:aws:s3:::sourcebucket&quot;
                  },
                  &quot;StringEquals&quot;: {
                      &quot;aws:SourceAccount&quot;: &quot;111122223333&quot;,
                      &quot;s3:x-amz-acl&quot;: &quot;bucket-owner-full-control&quot;
                  }
              }
          }
      ]
  }
</code></pre>
</li>
</ul>
<p>In this case the policy allows the S3 service itself (in some undefined capacity) to write to your target bucket and it could even be an inventory of an S3 bucket in another account.</p>
<p>So, the S3 service does not &quot;pick the right role&quot;, it operates without a specific(ally known) role.</p>

CC BY-SA 4.0
2022-07-05T06:52:36.007Z
2022-07-05T06:52:36.007Z
jdog
<p>Suppose I create a role with <code>AssumeRolePolicyDocument</code> allowing an AWS service (e.g. <code>s3.amazonaws.com</code>) to assume the role - do I need to in some way tell the service to assume the role, or will it automatically assume the role if it needs a permission that the role grants?</p>
<p>The motivation for this question is S3 Inventory, where according to the docs the S3 principal is what's accessing resources: <a href="https://docs.aws.amazon.com/AmazonS3/latest/userguide/configure-inventory.html" rel="nofollow noreferrer">https://docs.aws.amazon.com/AmazonS3/latest/userguide/configure-inventory.html</a></p>

CC BY-SA 4.0
2022-07-12T20:45:28.313Z
any feedback on our answers?
jdog
CC BY-SA 4.0
2022-07-12T23:18:31.903Z
It seems like the answer is that there is no implicit assumption of a role
Simon Hardman
<aws-iam>
Does an AWS service automatically assume a needed IAM role?
Simon Hardman
# Does an AWS service automatically assume a needed IAM role?

(Asked by: username_0 on 2022-05-30)

Suppose I create a role with `AssumeRolePolicyDocument` allowing an AWS service (e.g. `s3.amazonaws.com`) to assume the role - do I need to in some way tell the service to assume the role, or will it automatically assume the role if it needs a permission that the role grants?

The motivation for this question is S3 Inventory, where according to the docs the S3 principal is what's accessing resources: <https://docs.aws.amazon.com/AmazonS3/latest/userguide/configure-inventory.html>

**Tags:** aws-iam

> **Comments:**
> **username_1**: any feedback on our answers?  
> **username_0**: It seems like the answer is that there is no implicit assumption of a role  

---

## 2 answers

### Answer by username_2 on 2022-05-31. Score: 1

I think you may have this a little backwards.
S3 is a service that you may want to access with a role.  S3 would not be accessing anything, things access s3.
So, if you made IAM role ABC, you could set up policy to allow it to list and write to a specific S3 bucket, for example.
You could also make role ABC assume-able by another role.  In that case, you may have a server with default IAM role (instance profile) XYZ and the assume role policy can state that XYZ can assume ABC, which would then let it access S3.
Any entity is just one role at a time.  So, once your server assumed ABC from XYZ, it effectively is just ABC.
You can also assume roles from IAM users - but IAM users are generally bad practice as they are very losable.
Assuming a role is a very explicit operation, you have to do it on purpose.  Some programs may "seem" like they do it easily by configuration, but in reality if they are assuming a role, they are running very specific code for it, similarly to what you would do to assume the role from a command line.
Example Tutorial
Here is a decent AWS tutorial for assuming roles in a CLI to get familiar with it.
https://aws.amazon.com/premiumsupport/knowledge-center/iam-assume-role-cli/
The final command looks like this:
aws sts assume-role --role-arn \
"arn:aws:iam::123456789012:role/example-role" \
--role-session-name AWSCLI-Session

But that assumes role arn:aws:iam::123456789012:role/example-role is set up to allow your current role (whatever it is) to assume it.  Note that role assumption within an account only requires the target role to allow it, but role assumption between two AWS accounts requires the source and target role to be set upt o allow it.

> **Comments:**
> **username_0**: The motivation for this question is S3 Inventory, where according to the docs the S3 principal is what's accessing resources: https://docs.aws.amazon.com/AmazonS3/latest/userguide/configure-inventory.html#configure-inventory-kms-key-policy  
> **username_2**: Ah, interesting. I stand to learn something good here too then =). Thanks for clarifying!  
> **username_3**: @SimonHardman could you please update the question with this information on how you're using S3? I think it significantly changes the context.  

---

### Answer by username_1 on 2022-07-05. Score: 0

There is a variety of ways how different services access an S3 bucket. What username_2 answer describes is the scenario where the access is performed by some user controlled code running in the same AWS account. Some other access patterns include:

Delivering content through Cloudfront: There is something called an "Origin Access Identity" - a sort of Cloudfront specific role that can access the S3 bucket. This role cannot be assigned any policies itself, so you have to use the S3 bucket policy as an overlapping security layer to allow the policy access to the bucket (on top of any other access that exists).
An additional example would be a certain Wordpress plugin I have worked with that in the past required the S3 bucket and objects to be public. In this case the policy would have to be configured to be "nothing but the Origin Access Identity"

You could imagine a SaaS service that delivers something to your bucket, but without wanting to be restricted to how they do that. They may use EC2 now, but want to be free to deliver the data later by using Lambda or even S3 bucket replication. In this case, you would set up a policy that allows anything in the other AWS account to have write access to your bucket.

Some AWS Services have a default named role, for example if you use EC2 Lifecycle Manager, a role is created in your account called AWSDataLifecycleManagerDefaultRole. For this role to use a KMS key, the key needs to have a policy to allow access for this role.

While I have not used S3 inventory myself, if you look at the example policy linked from the service description: https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html#example-bucket-policies-use-case-9
  {  
        "Version": "2012-10-17",
        "Statement": [
          {
              "Sid": "InventoryAndAnalyticsExamplePolicy",
              "Effect": "Allow",
              "Principal": {
                  "Service": "s3.amazonaws.com"
              },
              "Action": "s3:PutObject",
              "Resource": [
                  "arn:aws:s3:::destinationbucket/*"
              ],
              "Condition": {
                  "ArnLike": {
                      "aws:SourceArn": "arn:aws:s3:::sourcebucket"
                  },
                  "StringEquals": {
                      "aws:SourceAccount": "111122223333",
                      "s3:x-amz-acl": "bucket-owner-full-control"
                  }
              }
          }
      ]
  }



In this case the policy allows the S3 service itself (in some undefined capacity) to write to your target bucket and it could even be an inventory of an S3 bucket in another account.
So, the S3 service does not "pick the right role", it operates without a specific(ally known) role.


---

