Private link support for Workload Profiles

mortenf1984 commented 10 months ago

Any new information on this? It is needed for FrontDoor support with Consumption + Dedicated and internal vNet only

trylvis commented 8 months ago

Any estimates on when this will become available?

wsloth commented 7 months ago

Looking for a status update on this as well. I'm aiming to run Azure Container Apps behind an Azure Firewall with UDR's, which leaves me no choice but to use Workload Profiles (serverless only would be fine, but it doesn't support UDR's according to this doc).

Workload profiles luckily also supports a serverless variation, but now I'm struggling on how to set up some form of inbound internet connectivity, ideally using Azure Frontdoor. The one guide from Microsoft which details on how to set this up assumes the exposed loadbalancer is called kubernetes-internal, which is not applicable to the Workload Profiles load balancer as it's called capp-svc-lb and is an IP-based backend pool, which is not supported by the Private Link Service.

mortenf1984 commented 7 months ago

Can we please get a update on this?

mortenf1984 commented 6 months ago

Are there any new information on the progress to get PLS support to CA with internal LB?

tasdflkjweio commented 5 months ago

Can we get an update on this? This seems like basic functionality that's missing.

alhardy commented 5 months ago

I am wanting to migrate from consumption only to dedicated since I need:

UDR support
increased Cores per replica

I don't think there are plans for a migration from consumption only to dedicated?

I am using front door for ingress to my consumption only plan, I cannot migrate due to lack of support for private links i.e. connecting front door where apis are on the same domain

jjindrich commented 4 months ago

My customer has same problem. Any estimates ?

MrImpossibru commented 4 months ago

+1 waiting for the implementation. P.S. There're some workarounds if needed: 1) use an Application Gateway, which supports a private endpoint (expensive), 2) custom forwarder based on VMSS and a HAProxy + a Standard Load Balancer + Private Link Service (requires some work to do)

mitchdowd commented 4 months ago

I'd like to use workload profiles to have NAT gateway support, but then I can't have the environments private which is a big downside.

rambo108 commented 4 months ago

Any update on when the fix will be ready for this?

jackcaplin commented 3 months ago

Is there an update or ETA?

jsheetzmt commented 3 months ago

Also looking for an update

falsadoo commented 3 months ago

Hi all can we get an eta for this?

cachai2 commented 3 months ago

Hi folks, we are targeting end of Q2 CY2024 for this feature.

KaiWalter commented 3 months ago

So CY = Calendar Year, hence Apr-Jun I assume. And when @cachai2 @paulyuk do you think, we have this for Azure China / 21vianet? We cannot proceed with our Service Fabric migration to ACA as we will wait for a clean Private Link solution in China.

ardeshir commented 2 months ago

This is the error we get when attempting to build one directly:

NemSimpraga commented 1 month ago

It's mid May, any update on this?

chinadragon0515 commented 1 month ago

We are ready for private preview, if you are interested in private preview, can you help to fill this form https://forms.office.com/r/fuhKa4UMy6 We will whitelist your sub for private preview. Public preview still need some time.

vandanchev commented 1 month ago

We are ready for private preview, if you are interested in private preview, please send you subscription id to acasupport(at)microsoft(dot)com and we can whitelist your sub for private preview. Public preview still need some time.

Would this be available for private preview in China also?

ardeshir commented 1 month ago

Cargill Development Group:

fsdi-dev-unity https://portal.azure.com/: a3cfee58-9860-4304-8f70-04e60a850479

fsdi-shared-services https://portal.azure.com/: 0c5f9978-efb7-42a1-a3d7-f2240c797607

fsdi-unity-prod https://portal.azure.com/: 50966e37-8361-4b25-a3d6-12cbed1fb293

fsdi-unity-stage-uat https://portal.azure.com/: f9c39143-872d-4e2a-9a10-cd13d1612e3c

fsdi-unity-test https://portal.azure.com/: 29d150d3-e2c1-4864-8f1a-bc68d4685a54

https://ardeshir.io @. https://github.com/ardeshir @. https://www.linkedin.com/in/ardeshir https://sepahsalar.substack.com/

On Fri, May 31, 2024 at 8:27 AM Vincent He @.***> wrote:

We are ready for private preview, if you are interested in private preview, please send you subscription id to acasupport(at)microsoft(dot)com and we can whitelist your sub for private preview. Public preview still need some time.

— Reply to this email directly, view it on GitHub https://github.com/microsoft/azure-container-apps/issues/867#issuecomment-2142165197, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAQCDR6TYVFENUUWAIB6C3ZFB3DBAVCNFSM6AAAAAA3KJBMG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBSGE3DKMJZG4 . You are receiving this because you commented.Message ID: @.***>

chinadragon0515 commented 1 month ago

@vandanchev we do not open Azure China for private preview now, thanks

mortenf1984 commented 1 month ago

I have sent a E-Mail and used the form, we are ready for Private Preview testing of this functionality

NemSimpraga commented 1 month ago

I've tested out the functionality, but either I am missing something or this does not address the issue at hand:

The added functionality enables creating a private endpoint for the Container App Environment in Workload Profiles mode
As far as I can see, this does not enable the private link service support that's needed to route traffic from Front Door to the Container Apps in the Container App environment

The Container Apps need to be added as origins to Front Door via a private link service, which is still not doable due to the original issue of Workload Profiles Container App Environment's managed Load Balancers using the IP based backend pool.

jackcaplin commented 1 month ago

Is there any documentation? I cant see how to add a private endpoint on my workload profile ACA

From: NemSimpraga @.> Sent: 03 June 2024 12:09 To: microsoft/azure-container-apps @.> Cc: Jack Caplin @.>; Comment @.> Subject: Re: [microsoft/azure-container-apps] Private link support for Workload Profiles (Issue #867)

NOTICE! This email was sent from outside Paxton.

Please do not click links or open attachments unless you recognise the sender and know the content is safe.

I've tested out the functionality, but either I am missing something or this does not address the issue at hand:

The added functionality enables creating a private endpoint for the Container App Environment in Workload Profiles mode
As far as I can see, this does not enable the private link service support that's needed to route traffic from Front Door to the Container Apps in the Container App environment

The Container Apps need to be added as origins to Front Door via a private link service, which is still not doable due to the original issue of Workload Profiles Container App Environment's managed Load Balancers using the IP based backend pool.

— Reply to this email directly, view it on GitHubhttps://github.com/microsoft/azure-container-apps/issues/867#issuecomment-2144920536, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A2AWLZWGAY33P4OUGGI2MTTZFRFH5AVCNFSM6AAAAAA3KJBMG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBUHEZDANJTGY. You are receiving this because you commented.Message ID: @.***>

Jack Caplin Chief IT Architect

[https://public.paxton-access.co.uk/public/emailfooterimages/image001.png]https://www.paxton-access.com/?utm_source=staff-signature&utm_medium=email&utm_campaign=staff-signature Phone: 01273 811011 Mobile: 07534563400 Web: www.paxton-access.comhttps://www.paxton-access.com/?utm_source=staff-signature&utm_medium=email&utm_campaign=staff-signature Email: @.**@.> Paxton House, Brighton, BN1 9HU Find us on the maphttps://goo.gl/maps/9vNLzgN1qR1zNg9A9

[https://public.paxton-access.co.uk/public/emailfooterimages/image002.png] https://www.facebook.com/PaxtonAccessLtd/ [https://public.paxton-access.co.uk/public/emailfooterimages/image003.png] https://www.linkedin.com/company/paxton-access-ltd/ [https://public.paxton-access.co.uk/public/emailfooterimages/image004.png] https://twitter.com/paxtonaccess [https://public.paxton-access.co.uk/public/emailfooterimages/image005.png] @.***/>

[https://www.paxton-access.com/wp-content/uploads/2024/04/Tech-Tour-2024-%E2%80%93-Email-Signature-1.png]https://www.paxton-access.com/tech-tour/?utm_source=emailsig&utm_medium=email&utm_campaign=techtour&utm_id=techtour

NSimpragaVolur commented 1 month ago

Is there any documentation? I cant see how to add a private endpoint on my workload profile ACA

You need to apply for the private preview, and you'll be able to create a private endpoint for your Container App Environment. The problem is that it doesn't really seem to solve anything, as you just get a private endpoint to your Environment in a subnet of your choosing. The same can be accomplished by simply creating an Environment with internalOnly mode, where you get an L4 LB with a private IP.

That, or I am just missing something :)

jackcaplin commented 1 month ago

My subscriptions have been whitelisted for the preview.

What is the pre-release feature called you enabled?

From: Nemanja Simpraga @.> Sent: 03 June 2024 12:34 To: microsoft/azure-container-apps @.> Cc: Jack Caplin @.>; Comment @.> Subject: Re: [microsoft/azure-container-apps] Private link support for Workload Profiles (Issue #867)

NOTICE! This email was sent from outside Paxton.

Please do not click links or open attachments unless you recognise the sender and know the content is safe.

Is there any documentation? I cant see how to add a private endpoint on my workload profile ACA

You need to apply for the private preview, and you'll be able to create a private endpoint for your Container App Environment. The problem is that it doesn't really seem to solve anything, as you just get a private endpoint to your Environment in a subnet of your choosing. The same can be accomplished by simply creating an Environment with internalOnly mode, where you get an L4 LB with a private IP.

That, or I am just missing something :)

NSimpragaVolur commented 1 month ago

You don't need to enable anything, you're just able to create a private endpoint to your ACA Environment, as I said. That's about it.

jackcaplin commented 1 month ago

Ok, I have created the private endpoint for the workload profile.

I have added this endpoint as an origin group in Azure Front Door.

Looks good so far

otuerker commented 1 month ago

Hi! We need this Feature also whitelisted for our Subscription. Can you please Whitelist us? Subscription: 4adbcf85-ddca-4471-aaf1-0ee7488ae1b9

chinadragon0515 commented 4 weeks ago

@ardeshir @otuerker can you help to fill the form here so I can send you the instructions how to set up private endpoint with ACA.

NSimpragaVolur commented 2 weeks ago

I have been playing with this functionality, and I have to say there are some very weird points to consider about the implementation around this feature.

Primarily, how the public availability of the application is influenced by the creation of a private endpoint.

Example:

Created a private endpoint in my VNet for my Container App Environment
Connected via VNet Gateway into the same VNet where the private endpoint is
I can see that when calling the FQDN of my Container App deployed to that Environment, it resolves to the private IP of my environment's private endpoint and I can successfully connect to my application
When not connected to the VPN, the FQDN of my Container App resolves to a random Azure public IP
- importantly, not the actual public IP of the deployed Container App Environment!
this means my application is not publically available over its FQDN, if I am not connected to my VPN (and configured private DNS resolution)

Here's the kicker: I can still reach the Container App over the public IP of the Container App environment! All I have to do is issue an HTTP request directly to the public IP of the Container App Environment (instead of the FQDN of the Container App) while setting the "Host" header to the FQDN of my deployed Container App, and I will be able to successfully reach the Container App.

This seems like a very weird setup as the application is not completely private (which we can see from the fact that it's available over its public IP), but it is also not available over the public internet when trying to resolve its actual FQDN.

What I expected to get after creating a private endpoint for the Container App Environment:

a way into the Container Apps of the Environment via the private network the private endpoint is in
by default, the Container Apps would stay publically available over their FQDN if the access was not specifically restricted to a private IP range via the Container Apps ingress IP restriction

What we get is a partial solution: public access is restricted only on the DNS level for the Container Apps since their FQDNs won't resolve to the public IP of the Container App Environment. But, crucially, they will stay available by directly accessing the public IP with a properly set "Host" header.

This does not make sense if you ask me, hope it helps in figuring our which direction this feature needs to go.

jackcaplin commented 2 weeks ago

Doesn't this depend on how you created the Container App Environment?

Do you have a Workload Profile with ingress set to internal only?

Sent from Outlook for Androidhttps://aka.ms/AAb9ysg

From: Nemanja Simpraga @.> Sent: Friday, June 14, 2024 5:47:00 PM To: microsoft/azure-container-apps @.> Cc: Jack Caplin @.>; Comment @.> Subject: Re: [microsoft/azure-container-apps] Private link support for Workload Profiles (Issue #867)

NOTICE! This email was sent from outside Paxton.

Please do not click links or open attachments unless you recognise the sender and know the content is safe.

I have been playing with this functionality, and I have to say there are some very weird points to consider about the implementation around this feature.

Primarily, how the public availability of the application is influenced by the creation of a private endpoint.

Example:

Created a private endpoint in my VNet for my Container App Environment
Connected via VNet Gateway into the same VNet where the private endpoint is
I can see that when calling the FQDN of my Container App deployed to that Environment, it resolves to the private IP of my environment's private endpoint and I can successfully connect to my application
When not connected to the VPN, the FQDN of my Container App resolves to a random Azure public IP
- importantly, not the actual public IP of the deployed Container App Environment!
this means my application is not available by resolving its FQDN, if I am not connected to my VPN (and configured private DNS resolution)

Here's the kicker: I can still reach the Container App over the public IP of the Container App environment! All I have to do is issue an HTTP request directly to the public IP (not the FQDN) of the Container App while setting the "Host" header to the FQDN of my deployed Container App, and I will be able to successfully reach the Container App.

This seems like a very weird setup as the application is not completely private (which we can see from the fact that it's available over its public IP), but it is also not available over the public internet when trying to resolve its actual FQDN.

What I expected to get after creating a private endpoint for the Container App Environment:

a way into the Container Apps of the Environment via the private network the private endpoint is in
by default, the Container Apps would stay publically available over their FQDN if the access was not specifically restricted to a private IP range via the Container Apps ingress IP restriction

What we get is a partial solution: public access is restricted only on the DNS level for the Container Apps since their FQDNs won't resolve to the public IP of the Container App Environment. But, crucially, they will stay available by directly accessing the public IP with a properly set "Host" header.

This does not make sense if you ask me, hope it helps in figuring our which direction this feature needs to go.

cachai2 commented 2 weeks ago

Hi @NSimpragaVolur, thank you for the feedback and for the detailed writeup with repro steps. We'll investigate this to verify the behavior and whether we need to make updates to align with expectations for the feature.

NemSimpraga commented 2 weeks ago

Doesn't this depend on how you created the Container App Environment? Do you have a Workload Profile with ingress set to internal only? Sent from Outlook for Androidhttps://aka.ms/AAb9ysg … ____ From: Nemanja Simpraga @.> Sent: Friday, June 14, 2024 5:47:00 PM To: microsoft/azure-container-apps @.> Cc: Jack Caplin @.>; Comment @.> Subject: Re: [microsoft/azure-container-apps] Private link support for Workload Profiles (Issue #867) NOTICE! This email was sent from outside Paxton. Please do not click links or open attachments unless you recognise the sender and know the content is safe. I have been playing with this functionality, and I have to say there are some very weird points to consider about the implementation around this feature. Primarily, how the public availability of the application is influenced by the creation of a private endpoint. Example: Created a private endpoint in my VNet for my Container App Environment Connected via VNet Gateway into the same VNet where the private endpoint is I can see that when calling the FQDN of my Container App deployed to that Environment, it resolves to the private IP of my environment's private endpoint and I can successfully connect to my application When not connected to the VPN, the FQDN of my Container App resolves to a random Azure public IP importantly, not the actual public IP of the deployed Container App Environment! this means my application is not available by resolving its FQDN, if I am not connected to my VPN (and configured private DNS resolution) Here's the kicker: I can still reach the Container App over the public IP of the Container App environment! All I have to do is issue an HTTP request directly to the public IP (not the FQDN) of the Container App while setting the "Host" header to the FQDN of my deployed Container App, and I will be able to successfully reach the Container App. This seems like a very weird setup as the application is not completely private (which we can see from the fact that it's available over its public IP), but it is also not available over the public internet when trying to resolve its actual FQDN. What I expected to get after creating a private endpoint for the Container App Environment: a way into the Container Apps of the Environment via the private network the private endpoint is in by default, the Container Apps would stay publically available over their FQDN if the access was not specifically restricted to a private IP range via the Container Apps ingress IP restriction What we get is a partial solution: public access is restricted only on the DNS level for the Container Apps since their FQDNs won't resolve to the public IP of the Container App Environment. But, crucially, they will stay available by directly accessing the public IP with a properly set "Host" header. This does not make sense if you ask me, hope it helps in figuring our which direction this feature needs to go. — Reply to this email directly, view it on GitHub<#867 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A2AWLZQZBZDXCUNGZERXMOTZHMNAJAVCNFSM6AAAAAA3KJBMG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRYGQYTCMRXHA. You are receiving this because you commented.Message ID: @.> Jack Caplin Chief IT Architect [https://public.paxton-access.co.uk/public/emailfooterimages/image001.png]https://www.paxton-access.com/?utm_source=staff-signature&utm_medium=email&utm_campaign=staff-signature Phone: 01273 811011 Mobile: 07534563400 Web: www.paxton-access.com<https://www.paxton-access.com/?utm_source=staff-signature&utm_medium=email&utm_campaign=staff-signature> Email: @*.**@*.> Paxton House, Brighton, BN1 9HU Find us on the maphttps://goo.gl/maps/9vNLzgN1qR1zNg9A9 [https://public.paxton-access.co.uk/public/emailfooterimages/image002.png] https://www.facebook.com/PaxtonAccessLtd/ [https://public.paxton-access.co.uk/public/emailfooterimages/image003.png] https://www.linkedin.com/company/paxton-access-ltd/ [https://public.paxton-access.co.uk/public/emailfooterimages/image004.png] https://twitter.com/paxtonaccess [https://public.paxton-access.co.uk/public/emailfooterimages/image005.png] @./> [https://www.paxton-access.com/wp-content/uploads/2024/04/Tech-Tour-2024-%E2%80%93-Email-Signature-1.png]https://www.paxton-access.com/tech-tour/?utm_source=emailsig&utm_medium=email&utm_campaign=techtour&utm_id=techtour

That is true, if you create a Container App Environment with properties.vnetConfiguration.internal as true, the L4 LB you get with the environment has a private IP, and there's no way to reach it directly from the public. But in such Container App Environments, you mostly don't really have a need to create a private endpoint. Perhaps to expose your Container Apps privately to VNets other than the one you integrated the Container App Environment with.

My issue is primarily with ACA Envs with public IPs (i.e. properties.vnetConfiguration.internal = false). If creating a private endpoint will make the FQDNs non-routable publically, then the public IP should not accept internet traffic at all, not let in traffic if someone is pointing calls to the public IP of you environment directly.

The better option, if you ask me (and no one is : ]), is leaving the internet route intact even with a created private endpoint. That is, the FQDNs resolve to the actual public IP of the environment when called from the internet, but when the FQDNs resolve from a VNet, they will resolve to the private IP of the endpoint. This is similar to other private endpoint implementations.

Example: the FQDN of an Azure Flex Postgres server will resolve to the private IP of a private endpoint when the DNS resolution call comes from inside a VNet, but will resolve to the public IP of the server when it comes from the internet. Then on the server itself you can configure firewall rules for the public IP, i.e. let in whatever you want from the public, while private access is handled by the private endpoint.

Container Apps themselves have IP restriction rules, which might be used similarly as a Postgres Flex server firewall rule.

jackcaplin commented 2 weeks ago

"But in such Container App Environments, you mostly don't really have a need to create a private endpoint."

I do if I want to use Azure Front Door.

This was my use case for a private endpoint, as my environments must have properties.vnetConfiguration.internal set as true. I've been using Application Gateway as interim hops.

For my case, this is all working as expected

Sent from Outlook for Androidhttps://aka.ms/AAb9ysg

From: NemSimpraga @.> Sent: Saturday, June 15, 2024 1:36:22 PM To: microsoft/azure-container-apps @.> Cc: Jack Caplin @.>; Comment @.> Subject: Re: [microsoft/azure-container-apps] Private link support for Workload Profiles (Issue #867)

NOTICE! This email was sent from outside Paxton.

Please do not click links or open attachments unless you recognise the sender and know the content is safe.

Doesn't this depend on how you created the Container App Environment? Do you have a Workload Profile with ingress set to internal only? Sent from Outlook for Androidhttps://aka.ms/AAb9ysg … ____ From: Nemanja Simpraga @.> Sent: Friday, June 14, 2024 5:47:00 PM To: microsoft/azure-container-apps @.> Cc: Jack Caplin @.>; Comment @.> Subject: Re: [microsoft/azure-container-apps] Private link support for Workload Profiles (Issue #867https://github.com/microsoft/azure-container-apps/issues/867) NOTICE! This email was sent from outside Paxton. Please do not click links or open attachments unless you recognise the sender and know the content is safe. I have been playing with this functionality, and I have to say there are some very weird points to consider about the implementation around this feature. Primarily, how the public availability of the application is influenced by the creation of a private endpoint. Example: Created a private endpoint in my VNet for my Container App Environment Connected via VNet Gateway into the same VNet where the private endpoint is I can see that when calling the FQDN of my Container App deployed to that Environment, it resolves to the private IP of my environment's private endpoint and I can successfully connect to my application When not connected to the VPN, the FQDN of my Container App resolves to a random Azure public IP importantly, not the actual public IP of the deployed Container App Environment! this means my application is not available by resolving its FQDN, if I am not connected to my VPN (and configured private DNS resolution) Here's the kicker: I can still reach the Container App over the public IP of the Container App environment! All I have to do is issue an HTTP request directly to the public IP (not the FQDN) of the Container App while setting the "Host" header to the FQDN of my deployed Container App, and I will be able to successfully reach the Container App. This seems like a very weird setup as the application is not completely private (which we can see from the fact that it's available over its public IP), but it is also not available over the public internet when trying to resolve its actual FQDN. What I expected to get after creating a private endpoint for the Container App Environment: a way into the Container Apps of the Environment via the private network the private endpoint is in by default, the Container Apps would stay publically available over their FQDN if the access was not specifically restricted to a private IP range via the Container Apps ingress IP restriction What we get is a partial solution: public access is restricted only on the DNS level for the Container Apps since their FQDNs won't resolve to the public IP of the Container App Environment. But, crucially, they will stay available by directly accessing the public IP with a properly set "Host" header. This does not make sense if you ask me, hope it helps in figuring our which direction this feature needs to go. — Reply to this email directly, view it on GitHub<#867 (comment)https://github.com/microsoft/azure-container-apps/issues/867#issuecomment-2168411278>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A2AWLZQZBZDXCUNGZERXMOTZHMNAJAVCNFSM6AAAAAA3KJBMG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRYGQYTCMRXHA. You are receiving this because you commented.Message ID: @.> Jack Caplin Chief IT Architect [https://public.paxton-access.co.uk/public/emailfooterimages/image001.png]https://www.paxton-access.com/?utm_source=staff-signature&utm_medium=email&utm_campaign=staff-signature Phone: 01273 811011 Mobile: 07534563400 Web: www.paxton-access.comhttps://www.paxton-access.com/?utm_source=staff-signature&utm_medium=email&utm_campaign=staff-signature<http://www.paxton-access.com%3Chttps://www.paxton-access.com/?utm_source=staff-signature&utm_medium=email&utm_campaign=staff-signature> Email: @.@.> Paxton House, Brighton, BN1 9HU Find us on the maphttps://goo.gl/maps/9vNLzgN1qR1zNg9A9 [https://public.paxton-access.co.uk/public/emailfooterimages/image002.png] https://www.facebook.com/PaxtonAccessLtd/ [https://public.paxton-access.co.uk/public/emailfooterimages/image003.png] https://www.linkedin.com/company/paxton-access-ltd/ [https://public.paxton-access.co.uk/public/emailfooterimages/image004.png] https://twitter.com/paxtonaccess [https://public.paxton-access.co.uk/public/emailfooterimages/image005.png] @./> [https://www.paxton-access.com/wp-content/uploads/2024/04/Tech-Tour-2024-%E2%80%93-Email-Signature-1.png]https://www.paxton-access.com/tech-tour/?utm_source=emailsig&utm_medium=email&utm_campaign=techtour&utm_id=techtour

That is true, if you create a Container App Environment with properties.vnetConfiguration.internal as true, the L4 LB you get with the environment has a private IP, and there's no way to reach it directly from the public. But in such Container App Environments, you mostly don't really have a need to create a private endpoint. Perhaps to expose your Container Apps privately to VNets other than the one you integrated the Container App Environment with.

My issue is primarily with ACA Envs with public IPs (i.e. properties.vnetConfiguration.internal = false). If creating a private endpoint will make the FQDNs non-routable publically, then the public IP should not accept internet traffic at all, not let in traffic if someone is pointing calls to the public IP of you environment directly.

The better option, if you ask me (and no one is : ]), is leaving the internet route intact even with a created private endpoint. That is, the FQDNs resolve to the actual public IP of the environment when called from the internet, but when the FQDNs resolve from a VNet, they will resolve to the private IP of the endpoint. This is similar to other private endpoint implementations.

Example: the FQDN of a Flex Postgres server will resolve to the private IP of a private endpoint when the DNS resolution call comes from inside a VNet, but will resolve to the public IP of the server when it comes from the internet. Then on the server itself you can configure firewall rules for the public IP, i.e. let in whatever you want from the public, while private access is handled by the private endpoint.

Container Apps themselves have IP restriction rules, which might be used similarly as a Postgres Flex server firewall rule.

— Reply to this email directly, view it on GitHubhttps://github.com/microsoft/azure-container-apps/issues/867#issuecomment-2169489219, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A2AWLZVT7H267LFYI2FCVXDZHQYMNAVCNFSM6AAAAAA3KJBMG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRZGQ4DSMRRHE. You are receiving this because you commented.Message ID: @.***>

NSimpragaVolur commented 2 weeks ago

I've been using Application Gateway as interim hops.

But if you're using AppGw for interim hops between Front Door and your internal Container App environment, then you don't need the private endpoint. You just put your AppGw in the same VNet as your Container App Environment and route traffic to its IP, which is already private anyways.

Only if your AppGw is integrated into a VNet other than the one your Container App Environment is, private endpoint becomes useful. Which is what I meant by:

Perhaps to expose your Container Apps privately to VNets other than the one you integrated the Container App Environment with.

jackcaplin commented 2 weeks ago

But with the private endpoints, I no longer need the app gateways. Until private endpoint support for workload profiles, they were the only method (apart from app proxies) to integrate front door.

I have now removed the app gateways. One per region. Less infrastructure to maintain and less cost.

Sent from Outlook for Androidhttps://aka.ms/AAb9ysg

From: Nemanja Simpraga @.> Sent: Saturday, June 15, 2024 3:12:58 PM To: microsoft/azure-container-apps @.> Cc: Jack Caplin @.>; Comment @.> Subject: Re: [microsoft/azure-container-apps] Private link support for Workload Profiles (Issue #867)

NOTICE! This email was sent from outside Paxton.

Please do not click links or open attachments unless you recognise the sender and know the content is safe.

I've been using Application Gateway as interim hops.

But if you're using AppGw for interim hops between Front Door and your internal Container App environment, then you don't need the private endpoint. You just put your AppGw in the same VNet as your Container App Environment and route traffic to its IP, which is already private anyways.

Only if your AppGw is integrated into a VNet other than the one your Container App Environment is, private endpoint becomes useful. Which is what I meant by:

Perhaps to expose your Container Apps privately to VNets other than the one you integrated the Container App Environment with.

— Reply to this email directly, view it on GitHubhttps://github.com/microsoft/azure-container-apps/issues/867#issuecomment-2169736327, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A2AWLZVCW2RDTJRALDPRICLZHRDWVAVCNFSM6AAAAAA3KJBMG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRZG4ZTMMZSG4. You are receiving this because you commented.Message ID: @.***>

Jack Caplin Chief IT Architect

[https://public.paxton-access.co.uk/public/emailfooterimages/image001.png]https://www.paxton-access.com/?utm_source=staff-signature&utm_medium=email&utm_campaign=staff-signature Phone: 01273 811011 Mobile: 07534563400 Web: www.paxton-access.comhttps://www.paxton-access.com/?utm_source=staff-signature&utm_medium=email&utm_campaign=staff-signature Email: @.**@.> Paxton House, Brighton, BN1 9HU Find us on the maphttps://goo.gl/maps/9vNLzgN1qR1zNg9A9

[https://public.paxton-access.co.uk/public/emailfooterimages/image002.png] https://www.facebook.com/PaxtonAccessLtd/ [https://public.paxton-access.co.uk/public/emailfooterimages/image003.png] https://www.linkedin.com/company/paxton-access-ltd/ [https://public.paxton-access.co.uk/public/emailfooterimages/image004.png] https://twitter.com/paxtonaccess [https://public.paxton-access.co.uk/public/emailfooterimages/image005.png] @.***/>

[https://www.paxton-access.com/wp-content/uploads/2024/04/Tech-Tour-2024-%E2%80%93-Email-Signature-1.png]https://www.paxton-access.com/tech-tour/?utm_source=emailsig&utm_medium=email&utm_campaign=techtour&utm_id=techtour

NSimpragaVolur commented 2 weeks ago

But with the private endpoints, I no longer need the app gateways. Until private endpoint support for workload profiles, they were the only method (apart from app proxies) to integrate front door. I have now removed the app gateways. One per region. Less infrastructure to maintain and less cost. Sent from Outlook for Androidhttps://aka.ms/AAb9ysg … ____ From: Nemanja Simpraga @.> Sent: Saturday, June 15, 2024 3:12:58 PM To: microsoft/azure-container-apps @.> Cc: Jack Caplin @.>; Comment @.> Subject: Re: [microsoft/azure-container-apps] Private link support for Workload Profiles (Issue #867) NOTICE! This email was sent from outside Paxton. Please do not click links or open attachments unless you recognise the sender and know the content is safe. I've been using Application Gateway as interim hops. But if you're using AppGw for interim hops between Front Door and your internal Container App environment, then you don't need the private endpoint. You just put your AppGw in the same VNet as your Container App Environment and route traffic to its IP, which is already private anyways. Only if your AppGw is integrated into a VNet other than the one your Container App Environment is, private endpoint becomes useful. Which is what I meant by: Perhaps to expose your Container Apps privately to VNets other than the one you integrated the Container App Environment with. — Reply to this email directly, view it on GitHub<#867 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A2AWLZVCW2RDTJRALDPRICLZHRDWVAVCNFSM6AAAAAA3KJBMG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRZG4ZTMMZSG4. You are receiving this because you commented.Message ID: @.> Jack Caplin Chief IT Architect [https://public.paxton-access.co.uk/public/emailfooterimages/image001.png]https://www.paxton-access.com/?utm_source=staff-signature&utm_medium=email&utm_campaign=staff-signature Phone: 01273 811011 Mobile: 07534563400 Web: www.paxton-access.com<https://www.paxton-access.com/?utm_source=staff-signature&utm_medium=email&utm_campaign=staff-signature> Email: @*.**@*.> Paxton House, Brighton, BN1 9HU Find us on the maphttps://goo.gl/maps/9vNLzgN1qR1zNg9A9 [https://public.paxton-access.co.uk/public/emailfooterimages/image002.png] https://www.facebook.com/PaxtonAccessLtd/ [https://public.paxton-access.co.uk/public/emailfooterimages/image003.png] https://www.linkedin.com/company/paxton-access-ltd/ [https://public.paxton-access.co.uk/public/emailfooterimages/image004.png] https://twitter.com/paxtonaccess [https://public.paxton-access.co.uk/public/emailfooterimages/image005.png] @./> [https://www.paxton-access.com/wp-content/uploads/2024/04/Tech-Tour-2024-%E2%80%93-Email-Signature-1.png]https://www.paxton-access.com/tech-tour/?utm_source=emailsig&utm_medium=email&utm_campaign=techtour&utm_id=techtour

Really? I am really curious how you send traffic from Front Door to the private endpoint directly. You usually do it via Private Link Service and the Container App's L4 load balancer with a non IP-based backend pool, which is only applicable for Consumption-only environments. Workload profiles still have the IP-based backend pool L4 LB, so I don't understand how a private endpoint helps overcome this issue?

microsoft / azure-container-apps

Private link support for Workload Profiles #867