AWS IoT Core: Lifecycle Events, being generated for unknown clientid

0

Hello;

I have subscribed to the two lifecycle event topics $aws/events/presence/connected/+ & $aws/events/presence/disconnected/+ . However, i noticed that we are receiving event message for ClientIds which are not things we have registered. Meaning the clientId has a value "iotconsole-<uuid>". We were hoping that these event would be generated for clients or things that we have defined in AWS IoT Core console. We are creating a thing with thing name equal to clientId in IoT core.

We are pushing these events to SQS queue via a rule action. My question is:

  1. How do we ensure these events are generated for only the clients or things that we have created?
  2. If the 1st approach is not possible, how do we validate the clientId with a thing name in the IoT SQL? Can this can be done via SQL?
madmax
질문됨 4달 전203회 조회
2개 답변
1
수락된 답변

Hi. You can use the thing policy variable iot:Connection.Thing.ThingName to ensure that devices can only connect if they use a client ID that matches a Thing name. Some policy examples: https://docs.aws.amazon.com/iot/latest/developerguide/connect-policy.html. This would satisfy 1 and is the recommended approach.

However, the iotconsole-<uuid> client ID is from when you use the MQTT test client in the console. The above policy variable will not apply to those connections. You could use the WHERE clause of the SQL statement, and the clientId() and startswith() SQL functions, to filter those events out.

https://docs.aws.amazon.com/iot/latest/developerguide/iot-sql-functions.html#iot-sql-function-clientid

https://docs.aws.amazon.com/iot/latest/developerguide/iot-sql-functions.html#iot-func-startswith

profile pictureAWS
전문가
Greg_B
답변함 4달 전
  • Thank you Greg for pointing out to the functions in the documentation, that was what i was looking for.

    Although the recommended policy approach seems useful. In our scenario, we would need to create adhoc short-lived subscribers on the go, to monitor messages for a short period and it seems like creating a thing for this for a short period might be counter productive.

    Would the below policy be appropriate? I hope this will allow all connection requests where clientId = thingname or clientIds where the thingTypeName = either "Devices" or "LOG". is this right? { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iot:Connect" ], "Resource": [ "arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}", "arn:aws:iot:us-east-1:123456789012:client/${iot:ClientId}" ], "Condition": { "ForAllValues:StringEquals": { "iot:Connection.Thing.ThingTypeName": ["Devices","LOG"] } } } ] }

0

This solution helped. However, i decided to use a different solution if anyone else has a similar problem.

I used the IoT Events service which was very easy to setup and worked like a charm. Since it already had templates for managing device heartbeat and which is what we were looking for.

madmax
답변함 3달 전

로그인하지 않았습니다. 로그인해야 답변을 게시할 수 있습니다.

좋은 답변은 질문에 명확하게 답하고 건설적인 피드백을 제공하며 질문자의 전문적인 성장을 장려합니다.

질문 답변하기에 대한 가이드라인