Accessing IoT edge device's managed Identity from IoT edge module

Question

Accessing IoT edge device's managed Identity from IoT edge module

Tobias Quadfasel 70

Hello! I am currently having a problem with my Azure IoT setup.

I have an edge device that runs several IoT modules based on docker containers which run python code. Within this code, I need to authenticate against other Azure resources. Ideally I would like to use Managed Identity Authentication to do this.

I got the answer that the recommended solution in this case is to get managed identity support by enabling azure arc on the edge device (see answer by @Suwarna S Kale in the question here: https://learn.microsoft.com/en-us/answers/questions/2264733/receive-credentials-from-keyvault-within-an-iot-hu).

I installed azure arc on the device and it works fine, showing up in the azure portal. I also verified I can access the managed identity endpoint (localhost:40342) from a local shell on the edge device.

My question is: How can I access the endpoint on the host edge device from within an IoT edge module? I have tried host.docker.internal:40342 as well as 172.17.0.1:40342 , but I always get connection refused errors. Are there additional settings to be made to the edgeAgent and/or edgeHub modules for this to work?

Thank you for your help!

Sander van de Velde | MVP 36,766 Reputation points MVP Volunteer Moderator

2025-05-21T22:04:31.1233333+00:00

Hello @Tobias Quadfasel ,

have you tried the local network IP address?

Did you also check the prerequisites regarding the groups? For example, on Linux, your application/docker container seems to be a member of the himds group.
VSawhney 795 Reputation points Microsoft External Staff Moderator

2025-05-22T02:43:10.6633333+00:00
Hello Tobias Quadfasel,

It sounds like you're trying to access the managed identity endpoint from within your IoT Edge module, and you're hitting some connection refused errors. That can be frustrating!

Since you’ve already installed Azure Arc and verified the managed identity endpoint is accessible locally, let’s look at a few things that might help you connect from your IoT module:

Networking Mode: Make sure your IoT Edge module is running in the correct networking mode. If it's running in bridge mode, it may not have access to host.docker.internal. You might want to try setting it to host mode for the module. This can be done in your deployment manifest under the "Host" section.

Firewall Rules: Check if there are any firewall settings on your device that could be blocking traffic to port 40342. Ensure that the port is open both ways.

Azure IoT Edge Configuration: Confirm that both edgeAgent and edgeHub are properly configured. Sometimes, issues can arise from the settings defined in the IoT Edge deployment manifest. Double-check to ensure there aren’t any configurations that might prevent internal network access.

Using Container's Internal Network: If you’re trying to connect to the host from a module, consider using localhost since the module and the identity endpoint should be accessible on the same local network.

Group Membership: As mentioned by Sander van de Velde | MVP , make sure your container is part of the necessary groups, especially for Linux-based devices, which might include the himds group so it has permission to access the endpoint.

Hope this helps, and please let me know if you have any other questions!

Thank you!
Tobias Quadfasel 70 Reputation points

2025-05-22T15:53:17.21+00:00
Hello all! I finally managed to get this to work, looking forward to your feedback from a security point of view.

In general, I am a bit puzzled why using the managed identity of the device for module-level MSI authentication is the recommended method, because getting it to work properly requires quite some hacking, opening up other security issues on the way.

So the problem is that the azure arc install script sets up the IMDS endpoint to 127.0.0.1:40342 and NOT to 0.0.0.0.40342. This is probably done for security reasons, such that you can only access the managed identity when on the actual machine (which makes sense). On the other hand, it renders the identity useless when working with containers like in my case using the IoT Hub, because the host 127.0.0.1 can't be accessed (except setting network=host, which is also not optimal in my view).

In order to use the managed Identity I had to expose the local endpoint somehow such that docker containers could access it. Here is what I did:

I created a daemon on my machine that uses socat to create a TCP relay between some (unused) port bound to 0.0.0.0 and 127.0.0.1:40342 . Note that this will expose the identity endpoint to your local network. It is fine for my use-case. In more critical use-cases, one should probably take measures to block acces to this port except for the docker host local IP (172.17.0.1).

Then, all containers that need to access the identity must have at least read-only access to /var/opt/azcmagent/tokens on the host system. Therefore, in the "container create options" in the IoT Hub, you need to include:

"Mounts": [ { "Target": "/var/opt/azcmagent/tokens", "Source": "/var/opt/azcmagent/tokens", "Type": "bind", "ReadOnly": true } ]

in the "HostConfig" section.

Finally, if you don't want to rely on REST API calls in your code but use azure.identity.DefaultAzureCredential or azure.identity.ManagedIdentityCredential, you need to set some environment variables. Let's assume for the free port I mentioned above in the TCP relay I used 0.0.0.0:12345, then the following variables need to be set in the container:

IMDS_ENDPOINT needs to be set to http://172.17.0.1:12345 and IDENTITY_ENDPOINT needs to be set to http://172.17.0.1:12345/metadata/identity/oauth2/token. Only then everything will work and you can access azure.identity -based managed identity credentials in your code on an IoT edge module to authenticate against other resources.
Sander van de Velde | MVP 36,766 Reputation points MVP Volunteer Moderator

2025-05-22T16:01:40.8933333+00:00

Hello @Tobias Quadfasel ,

great to see you shared your recipe for getting this setup using Azure Arc.

Thanks.

I take the liberty to duplicate the solution so it can be accepted as solution (original posters cannot accept their own answers)

Accepted answer

0 additional answers

Your answer

Sander van de Velde | MVP 36,766 Reputation points MVP Volunteer Moderator

2025-05-21T22:04:31.1233333+00:00

Hello @Tobias Quadfasel ,

have you tried the local network IP address?

Did you also check the prerequisites regarding the groups? For example, on Linux, your application/docker container seems to be a member of the himds group.
VSawhney 795 Reputation points Microsoft External Staff Moderator

2025-05-22T02:43:10.6633333+00:00

Hello Tobias Quadfasel,

It sounds like you're trying to access the managed identity endpoint from within your IoT Edge module, and you're hitting some connection refused errors. That can be frustrating!

Since you’ve already installed Azure Arc and verified the managed identity endpoint is accessible locally, let’s look at a few things that might help you connect from your IoT module:

Networking Mode: Make sure your IoT Edge module is running in the correct networking mode. If it's running in bridge mode, it may not have access to host.docker.internal. You might want to try setting it to host mode for the module. This can be done in your deployment manifest under the "Host" section.

Firewall Rules: Check if there are any firewall settings on your device that could be blocking traffic to port 40342. Ensure that the port is open both ways.

Azure IoT Edge Configuration: Confirm that both edgeAgent and edgeHub are properly configured. Sometimes, issues can arise from the settings defined in the IoT Edge deployment manifest. Double-check to ensure there aren’t any configurations that might prevent internal network access.

Using Container's Internal Network: If you’re trying to connect to the host from a module, consider using localhost since the module and the identity endpoint should be accessible on the same local network.

Group Membership: As mentioned by Sander van de Velde | MVP , make sure your container is part of the necessary groups, especially for Linux-based devices, which might include the himds group so it has permission to access the endpoint.

Hope this helps, and please let me know if you have any other questions!

Thank you!
Sander van de Velde | MVP 36,766 Reputation points MVP Volunteer Moderator

2025-05-22T16:01:40.8933333+00:00

Hello @Tobias Quadfasel ,

great to see you shared your recipe for getting this setup using Azure Arc.

Thanks.

I take the liberty to duplicate the solution so it can be accepted as solution (original posters cannot accept their own answers)

Answer 1

Below you find the solution as shared by the original poster @Tobias Quadfasel :

In general, I am a bit puzzled why using the managed identity of the device for module-level MSI authentication is the recommended method, because getting it to work properly requires quite some hacking, opening up other security issues on the way.

So the problem is that the azure arc install script sets up the IMDS endpoint to 127.0.0.1:40342 and NOT to 0.0.0.0.40342. This is probably done for security reasons, such that you can only access the managed identity when on the actual machine (which makes sense). On the other hand, it renders the identity useless when working with containers like in my case using the IoT Hub, because the host 127.0.0.1 can't be accessed (except setting network=host, which is also not optimal in my view).

In order to use the managed Identity I had to expose the local endpoint somehow such that docker containers could access it. Here is what I did:

I created a daemon on my machine that uses socat to create a TCP relay between some (unused) port bound to 0.0.0.0 and 127.0.0.1:40342 . Note that this will expose the identity endpoint to your local network. It is fine for my use-case. In more critical use-cases, one should probably take measures to block acces to this port except for the docker host local IP (172.17.0.1).

Then, all containers that need to access the identity must have at least read-only access to /var/opt/azcmagent/tokens on the host system. Therefore, in the "container create options" in the IoT Hub, you need to include:

"Mounts": [ 
  { 
    "Target": "/var/opt/azcmagent/tokens", 
    "Source": "/var/opt/azcmagent/tokens", 
    "Type": "bind", 
    "ReadOnly": true 
  } 
]

in the "HostConfig" section.

Finally, if you don't want to rely on REST API calls in your code but use azure.identity.DefaultAzureCredential or azure.identity.ManagedIdentityCredential, you need to set some environment variables. Let's assume for the free port I mentioned above in the TCP relay I used 0.0.0.0:12345, then the following variables need to be set in the container:

IMDS_ENDPOINT needs to be set to http://172.17.0.1:12345 and IDENTITY_ENDPOINT needs to be set to http://172.17.0.1:12345/metadata/identity/oauth2/token.

Only then everything will work and you can access azure.identity -based managed identity credentials in your code on an IoT edge module to authenticate against other resources.

If the response helped, do "Accept Answer". If it doesn't work, please let us know the progress. All community members with similar issues will benefit by doing so. Your contribution is highly appreciated.

Tobias Quadfasel 70 Reputation points

2025-05-22T16:23:09.3866667+00:00

Thank you Sander! I would still be happy to receive feedback from you or other security experts on whether this is a viable approach or if it introduces unforeseen security risks. For my case, I can say it seems to work very well.

I'll also try out your module twin method at some point :)
Sander van de Velde | MVP 36,766 Reputation points MVP Volunteer Moderator

2025-05-23T06:13:06.6+00:00

Hi @Tobias Quadfasel ,

thanks for sharing this alternative solution and explaining how to get it working in detail.

Using Azure Arc as a second secured channel for getting access to (managed identity) credentials is a smart solution.

I have to check this out but as you said, that endpoint exposing tokens must not be accessible for everyone. So, this needs more attention to protect it on the local network for inbound calls.

Share via

Accessing IoT edge device's managed Identity from IoT edge module

0 additional answers

Your answer