Failed to connect to MSI. Please make sure MSI is configured correctly. Get Token request returned: <Response [405]>

[Falven]

Please provide us with the following information:

This issue is a: (mark with an x)

• [ X] bug report -> please search issues before submitting
• [ ] documentation issue or request
• [ ] regression (a behavior that used to work and stopped in a new release)

Issue description

When attempting to authenticate using a MSI and a container using the Azure CLI, az login --identity returns the following error: Failed to connect to MSI. Please make sure MSI is configured correctly. Get Token request returned: <Response [405]>

Steps to reproduce

1. Deploy the Azure CLI container from Microsoft to an ACA https://hub.docker.com/_/microsoft-azure-cli or other container with the Azure CLI.
2. Connect to the container and attempt to authenticate with az login --identity

Expected behavior [What you expected to happen.]

The container should be able to authenticate using the MSI.

Actual behavior [What actually happened.]

Failed to connect to MSI. Please make sure MSI is configured correctly. Get Token request returned: <Response [405]>

Additional Information

MSI Authentication endpoints seem reachable from the container and MSI metadata seems correct in the environment variables. Additionally, I tested dotnet and python containers and both work with MSI authentication in ACA.

[Falven]

I created a repo to make it easy to illustrate the issue:

https://github.com/Falven/az-aca-msi

It deploys 2 Azure Container Apps - one with the Az CLI container (MSI doesn't work) and one with a Dotnet container (MSI works).

[vturecek]

@Falven this is unfortunately an issue with the Python SDK that is used by the Az CLI - it does not correctly detect that it is running inside a Container App, and so it uses the wrong Managed Identity endpoint.

As a work-around for now, you can trick the Az CLI into thinking that it is running inside an App Service container, which uses the same Managed Identity endpoint as Container Apps, to login with a managed identity, by setting the following environment variable on your Container App:

APPSETTING_WEBSITE_SITE_NAME

For example:

        "template":{
            "containers":[
                {
                    "image":"mcr.microsoft.com/azure-cli",
                    "name":"cli",
                    "command":[
                        "/bin/sleep",
                        "3650d"
                    ],
                    "env":[
                        {
                            "name":"APPSETTING_WEBSITE_SITE_NAME",
                            "value":"azcli-workaround"
                        }
                    ]
                }
            ],

The value can be whatever you want; the Python SDK just looks for the existence of this environment variable.

[vturecek]

Tracking in the AZ CLI repo: https://github.com/Azure/azure-cli/issues/22677

[jemrpo]

@Falven this is unfortunately an issue with the Python SDK that is used by the Az CLI - it does not correctly detect that it is running inside a Container App, and so it uses the wrong Managed Identity endpoint.

As a work-around for now, you can trick the Az CLI into thinking that it is running inside an App Service container, which uses the same Managed Identity endpoint as Container Apps, to login with a managed identity, by setting the following environment variable on your Container App:

APPSETTING_WEBSITE_SITE_NAME

For example:

        "template":{
            "containers":[
                {
                    "image":"mcr.microsoft.com/azure-cli",
                    "name":"cli",
                    "command":[
                        "/bin/sleep",
                        "3650d"
                    ],
                    "env":[
                        {
                            "name":"APPSETTING_WEBSITE_SITE_NAME",
                            "value":"azcli-workaround"
                        }
                    ]
                }
            ],

The value can be whatever you want; the Python SDK just looks for the existence of this environment variable.

I confirm this works, just added these env vars to my environment and I'm finally able to use a UAMI on ACA.

[mingue]

Hi, I'm facing the same issue than @Falven but unfortunately the workaround doesn't seem to work for me on a container app job.

I'm getting this error when trying to run a job with a user assigned identity

ERROR: Failed to connect to MSI. Please make sure MSI is configured correctly and check the network connection. Error detail: HTTPConnectionPool(host='localhost', port=42356): Max retries exceeded with url: /msi/token (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fd5ab4c10f0>: Failed to establish a new connection: [Errno 111] Connection refused'))

Adding the following to the script export APPSETTING_WEBSITE_SITE_NAME=DUMMY changes the error message but it still seems to try to connect to the same endpoint.

RuntimeError: MSI: Failed to retrieve a token from 'http://localhost:42356/msi/token/?resource=https://management.core.windows.net/&api-version=2017-09-01' with an error of 'HTTPConnectionPool(host='localhost', port=42356): Max retries exceeded with url: /msi/token/?resource=https://management.core.windows.net/&api-version=2017-09-01 (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f93e6cb6a70>: Failed to establish a new connection: [Errno 111] Connection refused'))'.

Any idea what that might be?

[letmaik]

I'm seeing the same issue but simply using the Python SDK's AzureDefaultCredential() while having system-assigned managed identity enabled for the container app:

023-09-20T09:34:59.768397028Z [09:34:59] DEBUG    msrestazure.azure_active_direc azure_active_directory.py:485
2023-09-20T09:34:59.768404903Z                     tory MSI: Retrieving a token                                
2023-09-20T09:34:59.768411014Z                     from                                                        
2023-09-20T09:34:59.768417106Z                     http://localhost:42356/msi/tok                              
2023-09-20T09:34:59.768422666Z                     en, with payload {'resource':                               
2023-09-20T09:34:59.768428186Z                     'https://management.core.windo                              
2023-09-20T09:34:59.768433867Z                     ws.net/'}                                                   
2023-09-20T09:34:59.771123714Z            WARNING  msrestazure.azure_active_direc azure_active_directory.py:488
2023-09-20T09:34:59.771140505Z                     tory MSI: Failed to retrieve a                              
2023-09-20T09:34:59.771171934Z                     token from                                                  
2023-09-20T09:34:59.771178687Z                     'http://localhost:42356/msi/to                              
2023-09-20T09:34:59.771183986Z                     ken' with an error of '405                                  
2023-09-20T09:34:59.771189627Z                     Client Error: Method Not                                    
2023-09-20T09:34:59.771194486Z                     Allowed for url:                                            
2023-09-20T09:34:59.771199956Z                     http://localhost:42356/msi/tok                              
2023-09-20T09:34:59.771205546Z                     en'. This could be caused by                                
2023-09-20T09:34:59.771210566Z                     the MSI extension not yet                                   
2023-09-20T09:34:59.771215785Z                     fully provisioned.     

EDIT: Adding APPSETTING_WEBSITE_SITE_NAME=DUMMY fixed it for us. Can a fix like this be implemented in Container Apps while an upstream fix is pending?

[micheleietri]

tried your fix, but still having issues:

in my script i run

az login --identity -u $env:uamiId

and passing the resource id for the uami, but still getting this error

ERROR: The command failed with an unexpected error. Here is the traceback: ERROR: "client_id" is the only supported explicit identity option on WebApp

[jaromirmikulik]

@micheleietri You should use client_id, not resourceId.

I have tried it. If I use resourceId, the behaviour was same as yours. If I change to client_id, it works correctly.

[micheleietri]

@micheleietri You should use client_id, not resourceId.

I have tried it. If I use resourceId, the behaviour was same as yours. If I change to client_id, it works correctly.

actually i should've read better the error, i tried to change it too and confirm it worked!