azure front door
3 TopicsGet ClientIp in backend service (behind FrontDoor and APIM)
Context: Azure Front Door connects to APIM (external mode) that forwards the requests to services inside AKS. Services are monitored with Application Insights. The target is to be able to retrieve client IP in our backend service thanks to an Header. Situation: We have tested multiple ways to do so: - via the header X-Forwarded-For - via the header X-Azure-ClientIP - via a policy in APIM with the following field: "<value>@(context.Request.IpAddress)</value>" None of these methods works to retrieve the clientIP, we get Microsoft datacenters IPs instead. Do you have an idea to be able to get this clientIP in backend service? Thank you for any tips!1.9KViews0likes1CommentAzure Static Web Apps - New comic
☁ La minute Cloud de Jules & Léa ☁ - You are a Cloud lover? - But you prefer Azure? - Learning with fun? - And most of all, static web applications are you favorite hobby after Tiktok? Maybe you'll like the last Azure Static Web Apps comic provided by Jules&Léa. 🥰 If you want to deep dive, do not hesitate to visit the official Microsoft documentation: https://learn.microsoft.com/en-us/azure/container-registry/container-registry-intro/?WT.mc_id=AZ-MVP-5005062 ++966Views0likes0CommentsFrontdoor Certificate Validation Process
Hi I'm working as an IT Architect for a Web-Agency, and I'm faced with a challenge on how to use the certification service with Front Door. With every Environment and Platform, I'm deploying we also deploy a public DNS zone. This helps a lot to deploy and provide services and changes independently to other DNS systems and zones. So for example, I deploy a platform 'alpha' with two environments. I would deploy two DNS zones: alpha.dev.dns.com alpha.prod.dns.com From now on, I can deploy services for these platforms, change public IPs etc. without having to care about the end-customer DNS. The endcustomer is just pointing his DNS http://www.customer.com to http://www.alpha.dev.dns.com. (lets not talk about SOA records for now 🙂 ) For Frontdoor this workes quite well. So during the Front Door provishioning I create dns records for every domain pointing to the Endpoint www-customer-com.xyz.azurefd.net. DNS Type Value http://www.customer.com CNAME http://www.alpha.dev.dns.com http://www.alpha.dev.dns.com CNAME www-customer-com.xyz.azurefd.net _dnsauth.http://www.customer.com CNAME _dnsauth.http://www.alpha.dev.dns.com _dnsauth.http://www.alpha.dev.dns.com TXT <validationcode> So the validation process runs his check on _dnsauth.http://www.customer.com - follows the CNAME to _dnsauth.http://www.alpha.dev.dns.com and validates the certificate request. Now there is an issue with the re-validation process. Because Front Door suddenly can not handle the fact that http://www.customer.com is a CNAME and not directly pointing to the Front Door Endpoint: www-customer-com.xyz.azurefd.net. This means, to keep valide Certificates, we have to introduce a process to revalidate the certificate requests and update the DNS records. Fortunatly they are in our own hands - and not on the customer domain. But do you know why this limitation existis? and what do you think about this architecture?1.4KViews0likes0Comments