Andy•2mo ago

Azure Container Apps - 404 / cannot find well-known configuration paradox

Hey folks, i have Zitadel running within an azure container app and cant seem to make calls to its api suite from my dotnet application. I'm using Terraform to provision my Zitadel instance with the following (abstract) configuration:

env {
        name  = "ZITADEL_EXTERNALSECURE"
        value = "true"
      }

      env {
        name  = "ZITADEL_EXTERNALDOMAIN"
        value = "${var.container_app_name}.${var.domain}"
      }

      env {
        name  = "ZITADEL_EXTERNALPORT"
        value = "443"
      }

env {
        name  = "ZITADEL_EXTERNALSECURE"
        value = "true"
      }

      env {
        name  = "ZITADEL_EXTERNALDOMAIN"
        value = "${var.container_app_name}.${var.domain}"
      }

      env {
        name  = "ZITADEL_EXTERNALPORT"
        value = "443"
      }

where container app name is the name of my running container, and var.domain is the default_domain of my container app environment (funnelled into my module using the azurerm provider https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/data-sources/container_app_environment#default_domain-2) . Zitadel_ExternalSecure is set to true and tlsmode is set to external. Within my app, i have https://<containername>.<cae_domain> as my base url for Zitadel (e.g. this will yield https://zitadel.somecustomdomain.azurecontainerapp.io). I do not have the port suffixed as part of the configuration within the app here. Using the Smartive package for dotnet, when i make a call to the get organizations endpoint, I get a 404 back. When I add the port number (which works with my local docker setup) to my applications configuration, i get a "well-known config cant be found" error. Which I also get back when navigating in the browser to endpoint with the port number attached. My ACA replica is running green and I can navigate to the console, I just cant seem to call any APIs from my application. I am no doubt missing something glaringly obvious here. Does anyone know what has to be set as the external domain for Zitadel in relation to container apps, and what the configuration should be within any calling application in order to call the Zitadel apis?

Terraform Registry

11 Replies

Ask Inkeep•2mo ago

Hi @Andy, I'm an AI assistant for ZITADEL. While a team member reviews this question, I'll see if I can find relevant sources for your question. Answer Based on the sources, there are a few issues with your Azure Container Apps setup: Azure Container Apps Command Configuration Issue Your deployment might be failing due to incorrect command configuration. For Azure Container Apps, you should use args instead of command (1) :

args = ["start-from-init", "--masterkey", "MasterkeyNeedsToHave32Characters", "--tlsMode", "disabled"]

args = ["start-from-init", "--masterkey", "MasterkeyNeedsToHave32Characters", "--tlsMode", "disabled"]

External Domain Configuration Your ZITADEL configuration appears correct for Azure Container Apps. However, ensure your external domain matches exactly what's accessible from your .NET application (2) . The configuration should be: - ZITADEL_EXTERNALDOMAIN: Your container app's FQDN (without protocol) - ZITADEL_EXTERNALPORT: 443 for HTTPS - ZITADEL_EXTERNALSECURE: true API Client Configuration For .NET API integration, the client should be configured with the complete API URL (3) :

var client = Clients.AuthService(new(apiUrl, ITokenProvider.Static(personalAccessToken) ) ) ;

var client = Clients.AuthService(new(apiUrl, ITokenProvider.Static(personalAccessToken) ) ) ;

Where apiUrl should be your complete ZITADEL domain (e.g., `https://zitadel.somecustomdomain.azurecontainerapp.io%60) . Common Issues Behind Reverse Proxies The 404 errors and "well-known config can't be found" suggest ZITADEL might not be correctly identifying the external domain. This is similar to reverse proxy issues where the API endpoints return incorrect URLs (4) . If you continue experiencing issues, click the "Ask for help" button to tag a team member for more specific Azure Container Apps guidance. To learn more, see the sources I considered: [1] Deployment of Zitadel to Azure Container apps is failing [2] Expose Zitadel UI to AWS ALB [3] Integrate ZITADEL APIs into a .NET Application [4] environment.json has wrong API endpoints behind reverse proxy and I can't log in Feel free to tag @Ask Inkeep with additional questions. Got it. Tagging @Rajat for additional help.

FFO•2mo ago

Hm what does the zitadel container print to stdout? You should be able to see if it picks up on the config there.

AndyOP•2mo ago

Hey @FFO i dont get anything back in the Zitadel logs unfortunately as it looks like the request is failing to even get as far as hitting the instance. I've been debugging the grpc calls being made to the remote instance this morning and found that the following call is created (which yields the 404). Where i've redacted, the fqdns all match up. The exact error I get is the "bad grpc response" (i've attached this too), but this is caught in my application vs appearing in the logs of Zitadel.

AndyOP•2mo ago

My Zitadel instance is alive and well, and i can navigate to the console in the browser etc. Its just my application making calls to the remote instance that is causing the bother which makes me think its configuration somewhere, but Im in the dark atm

FFO•2mo ago

Hm that unimplemented looks weird. Some thoughts that come to mind: 1) Either HTTP2 breaks which is needed for the call to work (can you do a simple curl to the endpoint?) 2) The zitadel version does not have that specific endpoint yet -> what version are you using?

Xorling•2mo ago

I'm trying to deploy Zitadel to an Azure Container App as well. Thanks for the pioneers that have gone before me. I'm hoping I can get this working. 🤞

AndyOP•2mo ago

@ffo it was indeed the http2 problem! Our ACA had the ingress transport protocol as "auto" so it must not have been binding the grpc endpoints. Changing this to explicitly target http worked a treat! @Xorling happy to share how we've managed to get ours up and running in our dev environment if it helps you out any!

FFO•2mo ago

Great, thanks for sharing! Can you share a screenshot or something where this setting is for all the non azure specilist like me 😄

Xorling•2mo ago

I would love and appreciate any direction! I haven't been working on this long and already have battle wounds from beating my head against my desk. This is not for the faint of heart.

AndyOP•2mo ago

@ffo of course, under any container app in the Azure portal, you can search in the bar on the left of the container app itself for "Ingress" which presents this screen. The transport setting can be set using the dropdown. Setting via terraform can be done using the azurerm provider and adding the http2 value for the transport prop as part of the rule. If this is not set it will default to "auto" (which was the root cause of our headache!) https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/container_app#transport-4 For anyone using Bicep, then the same can be done in there too. https://learn.microsoft.com/en-us/azure/templates/microsoft.app/containerapps?pivots=deployment-language-bicep#ingress

Microsoft.App/containerApps - Bicep, ARM template & Terraform AzAPI...

Azure Microsoft.App/containerApps syntax and properties to use in Azure Resource Manager templates for deploying the resource. API version latest

Terraform Registry

AndyOP•2mo ago

I'll send you a DM @Xorling !

Azure Container Apps - 404 / cannot find well-known configuration paradox

Did you find this page helpful?