Using ResourceTags or ThingAttributes for AWS IoT policy "conditions"

0

I would like to lock down user access to the following operations on iot "Things":

ListThingsInThingGroup, UpdateThingShadow, GetThingShadow

I am aware that there are iot policy variables for the connected device, but I believe that only represents the attributes of the connecting device, not the device that is being accessed in the above operations.

Never the less, I tried it and it did not work:

    {
      "Condition": {
        "StringLike": {
          "iot:Connection.Thing.Attributes[department_id]": "${aws:PrincipalTag/department}"
        }
      },
      "Effect": "Allow",
      "Action": "iot:ListNamedShadowsForThing",
      "Resource": "arn:aws:iot:ap-southeast-2:<accountId>:*"
    },

I found a list with Condition keys for iot at this url . https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiot.html

An interesting one that I thought might be useful is iot:ThingGroupArn. As Things themselves can't have Tags to use with ResourceTag, ThingGroup could be used in the same way.

However, this list of iot policy variables doesn't contain any condition keys for the operations above.

Never the less, I tried it and it didn't work.

  {
      "Effect": "Allow",
      "Action": "iot:ListNamedShadowsForThing",
      "Resource": "arn:aws:iot:ap-southeast-2:<accountId>:*",
      "Condition": {
        "StringLike": {
          "aws:ThingGroupArn": [
            "arn:aws:iot:ap-southeast-2::thinggroup/department-id-${aws:PrincipalTag/deparpmentid}"
          ]
        }
      }
    }

Has anyone found a successful strategy for implementing a policy as above?

2 Answers
0

Hi,

Can you kindly clarify your use case and what you meant by "lock down user access?" What entities are you trying to lock down in this case?

As you know, IAM and IoT policies are two separate systems. The features or mechanisms for each cannot be used interchangeably. IAM will be used by IAM users or roles which try to call IoT operations usually via the CLI or SDK. On the other hand, IoT policies are attached to device certificates which are used by IoT devices to communicate with IoT -> https://docs.aws.amazon.com/iot/latest/developerguide/client-authentication.html

The link that you have provided https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiot.html is for IAM policies so this can only be used for IAM policies while iot:Connection.Thing.Attributes[department_id] is for IoT policies.

From the table in the above documentation we can see the Condition Keys colument where we can see that only certain operations will allow ConditionKeys. For example, the iot:ThingGroupArn is only allowed for OpenTunnel and RotateTunnelAccessToken. This is most likely why the second IAM policy is not working as expected

Again, can you clarify your use case here so that we can dive deep and try to figure out a solution? We are looking forward to your reply.

AWS
SUPPORT ENGINEER
Ryan_A
answered a year ago
0

So the use case is that i have a multi-tenanted application where my users are grouped by departments. I am using the aws iot js sdk to use the operations mentioned in the OP to avoid needing to build an api around these operations.

I need users in Department A to only have access to execute these operations (e.g. iot:ListNamedShadowsForThing) on Things that they own in their department.

The users are being authorised using Cognito, and I have successfully mapped their department into the identity pool making it available on the AssumeWebIdentityRole using TagSession action on the cognito_authenticated role. This becomes available in the iot policy as ${aws:PrincipalTag/deparpmentid}

I can successfully ensure that users in Department A can only publish and receive from topics prefixed with department A's Id by using their department id tag mapped as above in the IoT policy for iot:Publish, iot:Subscribe actions. So this proves that ${aws:PrincipalTag/deparpmentid} indeed works in an IoT policy (if you click all the right buttons in the aws console.

The issue, is as you say, those operations don't have any useful Condition Keys to use for this purpose. This seems like a big oversight in the design of iot policies. If you enabled the iot:ThingGroupArn Condition Key for any operation related to a Thing, not just tunnel operations, that would solve this problem.

The only alternative solution I see is to move those operations behind my API and assert the proper permissions imperatively.

Or might you be able to suggest another way.

answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions