credentials.iot.amazonaws.com "assuming a Role"

Question

In order to give an IoT device a simple access to an S3 bucket, one must do all this: https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html (phew!)

I would like this understand what I'm actually doing.   The first thing is to let "credentials.iot.amazonaws.com" service to "assume a role", in more details "role that the credentials provider assumes on behalf of your device".

The device has a role which let's it to do pubsub on MQTT messages (among other things).

Why the credential services would be interested in "assuming a role on behalf/from the device" ?  I mean, it is going to give out an access key id & secret access key associated to the IoT device certificate.   Such a task is farm from the "roles" that the device does.

Accepted Answer

Thanks for the answers.  However, I was looking for a bit more "mechanistic" answer: what are the instances that give out the credentials (iot credentials server) and who gets which role and why: is it the iot credentials server, or the iot device..?   you know - boxes and arrows explanation.  :)

Something like this: 
```

+--------------------------+  -----> gives creds, according to a role alias
|IoT credentials provider  |         "my-role-alias"  ---> creds allows stuff according to 
|server                    |                                        "my-role-credentials"
|                          |
+--------------------------+  <----- request creds according to role alias
  - can give creds requested         "my-role-alias" --link--> role "my-role-credentials"
    with certs because role          creds are requested with certificates
    because role alias
    "my-role-alias" has
    "it:AssumeRoleWithCertificate"
    enabled

- can give creds for "my-role-alias"
    in the first place, since "my-role-alias"
    role alias "inherits" role "my-role-credentials"
```
I also created a "batteries included" example repo to demo this thing in [here](https://github.com/elsampsa/aws-iot-testbed)

So I'm going (shamelessly) to accept my own answer as the correct one.

Answer

The credential provider is a way for an IoT device to access AWS services that cannot be directly accessed using an X.509 certificate and IoT policy.  Here's a really good [C-SDK demo](https://github.com/aws/aws-iot-device-sdk-embedded-C/tree/main/demos/http/http_demo_s3_download) that you can build and run on a Linux system. Note that the request that fetches the security token and keys (`getTemporaryCredentials()`) is HTTPS not MQTT.

Typically, IoT devices will be [provisioned with an X.509 certificate and private key](https://docs.aws.amazon.com/iot/latest/developerguide/iot-provision.html). Not IAM keys. The [X.509 certificate is used to authenticate](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html) the device. An [IoT policy](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policies.html), attached to the certificate, [authorizes](https://docs.aws.amazon.com/iot/latest/developerguide/iot-authorization.html) the device to perform [IoT actions](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policy-actions.html) on [IoT resources](https://docs.aws.amazon.com/iot/latest/developerguide/iot-action-resources.html). So it can publish/subscribe to MQTT topics, use Shadows, use Jobs etc, but only perform IoT actions on IoT resources. This is deliberate. To limit blast radius if a device is compromised.

If a device needs to perform non IoT actions on non IoT resources, it uses the credential provider to get IAM credentials.

Please be aware that IoT Core offers various mechanisms for getting data in and out of an S3 bucket (without always having to resort to credential provider). For example, data can be published on MQTT topics and the IoT Core [Rules Engine](https://docs.aws.amazon.com/iot/latest/developerguide/iot-rules.html) can be used to land the data in S3 ([directly](https://docs.aws.amazon.com/iot/latest/developerguide/s3-rule-action.html) or via [other services](https://docs.aws.amazon.com/iot/latest/developerguide/iot-rule-actions.html)). An IoT Core [Job with presigned URL](https://docs.aws.amazon.com/iot/latest/developerguide/create-manage-jobs.html) can be used to retrieve a file from an S3 bucket. Hence there is no need to make your bucket, or bucket object, public.

Answer

It is mostly about security.  This workflow allows a device to assume a role temporarily that has a defined set of permissions within your AWS account.  This is done using the devices certificate rather than hard-coded credentials. In the case of S3, if a bucket has all public access blocked, then this allows a device to upload or download files from that bucket using credentials passed over secure MQTT topics.  One use case would be where an IOT Job instructs the device to download a file from bucket X using role Y.

On the other hand if the device already has permissions to the bucket (e.g. the bucket is public), there is no need to obtain temporary credentials and the device can call S3 APIs without credentials.  If bucket access is controlled through and ACL, then each device would need AWS credentials.  This would be difficult to manage in the long term and also present security issues.

credentials.iot.amazonaws.com "assuming a Role"

Relevant content