Support client device thing policies for authorization

[mschwab12]

Feature Description Ability to support policies attached to client things for authorization instead of component configuration. This could be switched on by a configuration flag.

Use Case We have many plants with multiple connectors sending data over mqtt. As they have no direct internet connection we have deployed a greengrass core device in a DMZ on every plant and bridge the traffic to IoTcore with the bridge component. All the data sent will be ingested into our data layer.

Every connector on the plant is represented by an aws IoT thing in the cloud and has it's own certificate for authentication against the greengrass core device. The thing itself has different attributes e.g. the uuid of the connector.

The things send messages in specific topics, based on their type and include some of their attribues in the topic. So we have made policies which allow iot:Publish to this topics including thing attributes e.g. data/energysensor/${iot:Connection.Thing.Attributes[id]}/status

We want to use the polices attached to the thing certificates instead of the policy defined in the config of this component. This has the benefit that policy could be used for devices that can connect directly to IoTcore and devices connecting over greengrass core devices. Also policies are attached to things by fleetprovisioning and the core device deployment is the same for all core devices.

Proposed Solution So maybe this could be implemented by adding a feature flag to the config, so existing auth is still default choice. If flag is set then policy of the certificate is loaded with certificate and can then be used for permissionEvaluation and stored locally.

Other In this documentation about Minimal AWS IoT policy for client devices, it is stated that the policy of a local client device needs some of the iot: actions with a star wildcard. This is not true as I tested it and it works just fine without any policy at all. But that would be the behaviour we would like to have.

• [x] :wave: I may be able to implement this feature request
• [ ] :warning: This feature might incur a breaking change

[MikeDombo]

Hello Marco, Thank you for your suggestion. This is something that we considered when first designing CDA. Unfortunately it is not feasible to implement this in a way that meets our bar for security and efficiency. I won't go into all the details, but we are addressing these needs in the coming months with wildcard and policy variable support in the CDA policy. These features should be able to meet your requirements.

[mschwab12]

Hey Mike, thank you for your reply and I understand this. I saw the PR for wildcard support in publish restrictions and we are looking forward for that. What do you mean by policy variable support?

[MikeDombo]

Policy variables would be like this: ${iot:Connection.Thing.Attributes[id]}

[mschwab12]

Ah ok so perfect, looking forward for this feature!