iotedge 1.2: provisioning of module identities on a downstream device #5155
Assignees
Labels
Comments
|
Hi @mlilien - We don't currently support module identities on leaf (non-edge) devices. We will work on fixing this limitation, but I don't have a timeline yet on that yet. Here are answers to your questions above: Re #2: EdgeHub does support a Registry API which allows downstream devices to create module identities, but currently it works only for IoT Edge devices. So you won't be able to create module identities for your leaf IoT Edge device via EdgeHub, yet. Re #3: I am not sure what you mean here... one application uses device identity and is able to connect properly. Other application is not provisioned, and not able to connect (which seems expected). Am I missing something? Hope this clarifies your questions. |
|
Hi @varunpuranik
|
|
This issue is being marked as stale because it has been open for 30 days with no activity. |
kodiakhq bot
pushed a commit
that referenced
this issue
Aug 18, 2021
Fixing #5155, it is now possible to connect device module through edgeHub as well as creating new modules. Test: Connected module through edgeHub using SAS token Created new module through edgeHub.
huguesBouvier
added a commit
to huguesBouvier/iotedge
that referenced
this issue
Sep 1, 2021
Fixing Azure#5155, it is now possible to connect device module through edgeHub as well as creating new modules. Test: Connected module through edgeHub using SAS token Created new module through edgeHub.
|
Since my colleague @mlilien is on holidays for another 2 weeks I try to give some feedback on your fix. From my understanding the fix focuses on the 1st scenario described by @mlilien with the corresponding logs: "suspicious edgehub logs". The use case we are struggling with is scenario 2.) where two module identities on a leaf device (non-edge iot device) behind an edge gateway are not provisioned due to permission errors. After testing with a local build of the fixed edgehub module on our side this setup is still not running with the same logs already provided in the issue: "edgeHub logs scenario 2 - two module identities - unauthorized". So my question is if the fix was supposed to fix 2nd scenario as well from your side? |
|
Hi @JanZachmann, This also should fix scenario 2. I was able to create a module trough edgeHub. This is the code I used in C#: I was able to establish a connection through edgeHub and create a new module with this code. Could you please give me more details/code on what you are doing in #2? |
|
@huguesBouvier Thanks for your feedback! Our setup on the leaf device is as follows:
What we tested today:
The following questions come to my mind:
|
|
Hello! I think I understand the confusion. There are 2 connection strings: This is how I was able to create new modules. The device connection string is used to authenticate.
Whether you use IS or connection string directly like I did is the same. IS is used as a mean to safely store connection string. What the C# is doing is identical. It uses the Device Connection string to generate a token and access IoTHub. |
|
Thanks for explaining details regarding module creation. Since we got leaf device modules working with connection string but not with IS we're pretty sure it must be sth. releated to the eis_utils of ADU: https://github.com/Azure/iot-hub-device-update/tree/main/src/utils/eis_utils That's what I meant in my last comment when I asked if you can confirm that the adu agent was ever successfully running as module identity on a leaf device? |
|
@JanZachmann I am adding members of the Device Update team here to verify if there is a reason eis_utils of ADU: https://github.com/Azure/iot-hub-device-update/tree/main/src/utils/eis_utils causing leaf modules not to connect for the AduIotAgent as module using the IoT Identity service. It should have just worked if it works with the connection string and the fix that @varunpuranik added to IoT Identity service. |
|
"That's what I meant in my last comment when I asked if you can confirm that the adu agent was ever successfully running as module identity on a leaf device?" Not to my knowledge but I didn't work much with ADU, I see you added the ADU team. They would be ale to provide an answer, let's have them confirm first. |
|
Should I close the ticket for now? Let's re-open it if there is a follow up. |
|
Please don't close yet. Next week @mlilien is back from holydays. Since he is the initiator of the issue and he is testing the setup with our yocto linux distribution (I just used ubuntu), I would like to wait for his analysis and feedback first. @ValOlson Do you think you ADU guys could provide some feedback on testing our setup on your side next week? |
|
Ok! I will be also on vacation next week, maybe someone else from the team will pick it up but otherwise it possible you'll get answers only when I get back |
|
Hi, I build the edge-hub 1.2.4 from release/1.2 branch for target aarch64. I can verify that in case 1 I don't see the suspicious log entries in edge-Hub anymore. edge-hub log for case 2
Basically the same as in case 1. The difference is that the leaf device never was connected directly to iothub before. I have an iot device with iot-identity-service and two applications configured with module identity behind an edge-gw. The authentication type is SaS. What also doesnt work and is a simpler setup: |
|
The patch made for edgeHub now allows module identity to be created from leaf devices, even when never connected directly to iotHub. So case 2 should work. I tested case2 (create module identity while never connecting directly to iothub) with the C# SDK and by creating my own project. If it still doesn't work, then there is probably an issue with how the tokens are generated, let's explore that. |
|
Hi Hugues, I did not get any answers from ADU team yet. leaf aziot system logs
Can you verify that iot-identity-service is supposed to do that in our described scenario?
Is there an existing script/application which I can use for that? |
|
Hi! You're right, I didn't use IS but it doesn't matter, IS is just safe keeping the secret key. In using C# I just put the key directly in plain text using in the code (see the xxx below). The important part is the API call to edgeHub and that API call is identical. Is there some piece of code that you can share, in how you use IS to generate token? This is the code I used: I'll test with IS. I'll post the code when I am done. |
|
@JanZachmann / @huguesBouvier: Can you confirm if you have the ADU agent working on the downstream device? ADU use IS to retrieve or create the provisioning information for the agents connection to the IOT Hub, so if you are not using IS then did you manually update ADU's config.txt file with the connection string? Is there open question do you have for the ADU team? |
|
@ValOlson Yes I can confirm that our downstream/leaf device has ADU running as module identity using IS. This causes the same misbehaviour as described by @mlilien and what we also see with other module identities behind a gateway. |
|
I am going to try with IS tomorrow. I'll let you know the result. |
|
Hey! So some results from the test. And the result I got was the edgeHub is ok with the token, but actually iothub is not: Can you confirm that you observe the same thing (edgeHub is ok but iotHub return status=unauthorized?) The "status=Unauthorized" seems to be the response from iotHub. The token is correctly validated by edgeHub though. I tried tampering the token and then edgeHub is unhappy: It looks like iothub doesn't like that edgeHub module on behalf of the leaf. I'll reach out to iotHub and let you know. |
|
Using Kusto and looking at the IoTHub code we have confirmed that some changes needs to be made on IoTHub side: I have created a ticket with the IoTHub though I don't have an ETA as to when it will be fixed. FYI: I also have created a ticket with the IoT SDK team to request support for gateway hostname in the SDK too: Azure/azure-iot-sdk-csharp#2175 |
|
Hello @huguesBouvier |
|
@JanZachmann I can only say we are discussing with them. It might take a while. |
|
I think I see the same error when I'm using AMQP in the following command line program with a module identity and no gateway: |
|
Are there any plan for a bug fix? |
|
There is a plan but It will take a while. It is not a simple fix. This involves edge, SDK and IoTHub. |
damonbarry
pushed a commit
to damonbarry/iotedge
that referenced
this issue
Apr 15, 2022
Fixing Azure#5155, it is now possible to connect device module through edgeHub as well as creating new modules. Test: Connected module through edgeHub using SAS token Created new module through edgeHub.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expected Behavior
Hi, I'm trying to follow the transparent gateway documentation with iotedge 1.2 (https://docs.microsoft.com/en-us/azure/iot-edge/how-to-create-transparent-gateway?view=iotedge-2020-11).
1.) I have an iot device with iot-identity-service and two applications configured with module identity. The authentication type is SaS.
If I connect this device directly with the iothub, the two module identities get provisioned.
If I use this iot device afterwards as a downstream device behind a gateway the two module identites get provisioned as well.
The edgehub log looks suspicous though. See in the log section below.
2.) If I use another iot device as a downstream device behind a gateway, that never was connected to the iothub, the provisioning of the module identites doesnt work. I get permission denied errors from the edgehub. The authentication type is Sas as well.
3.) If I use this device and configure one application as device identity. Only this application gets provisioned. The other application still gets an access denied error from the edgehub.
My goal is to achieve the provisioning of multiple module identities on a downstream iot device, without connecting this device directly to the iothub. The authentication type is Sas. Is that possible?
Output of
iotedge checkClick here
Device Information
Runtime Versions
iotedge version]: iotedge 1.2.2 (git revision is 70bc14c)docker version]:Client:
Version: 19.03.15
API version: 1.40
Go version: go1.14.15
Git commit: eb310fca49
Built: Tue Jun 22 12:08:06 2021
OS/Arch: linux/arm64
Experimental: false
Server:
Engine:
Version: 19.03.15
API version: 1.40 (minimum version 1.12)
Go version: go1.14.15
Git commit: 420b1d36250f9cfdc561f086f25a213ecb669b6f
Built: Tue Jun 22 12:07:16 2021
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: v1.2.14-3-g3b3e9d5f6.m
GitCommit: 3b3e9d5f62a114153829f9fbe2781d27b0a2ddac.m
runc:
Version: 1.0.0-rc8
GitCommit: 425e105d5a03fabd737a126ad93d62a9eeede87f-dirty
docker-init:
Version: 0.18.0
GitCommit: fec3683-dirty
Logs
suspicous edgehub logs for working scenario 1.)
edgeHub logs scenario 2 - two module identities - unauthorized
edge-hub logs szenario 3 - one device identity, one module identity - module unauthorized
identity principal configuration
The text was updated successfully, but these errors were encountered: