- Newest
- Most votes
- Most comments
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.
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 Thing
s 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.
Relevant content
- asked 6 years ago
- AWS OFFICIALUpdated a day ago
- AWS OFFICIALUpdated a month ago
- AWS OFFICIALUpdated 6 months ago