todo-nodejs-mongo-aks app not reachable - due to ingress networking security policy in microsoft tenants

[Menghua1]

Describe the issue:
After running the azd up command, click the api and web links output in the logs, and the pages fails to load as follows:

• API error:
  
• Web error:
  

Repro Steps:

1. Login in with command: azd auth login.
2. Execute command: azd init -t todo-nodejs-mongo-aks -b staging.
3. Run azd up.
4. Click web and api links.

Environment:

• Template: todo-nodejs-mongo-aks.
• Branch: pr/3976 and staging.
• OS: Windows, Codespaces, Devcontainer, Linux, Mac.
• Azd version: azd version 1.10.0-beta.1-daily.3947259 (commit 5bf8568b1566723be8bc2259c578df4f931cf430)

Expected behavior:
Web and api page can be loaded successful.

@jongio for notification.

[jongio]

Are these related? #4109

[jongio]

This may have been transient. Please re-test

[v-xuto]

Are these related? #4109

This issue should be unrelated to #4109. We have retested and it is persistent, not temporary.

[jongio]

@rajeshkamal5050 or @weikanglim @vhvb1989 Can you follow up?

[vhvb1989]

This is expected for todo-nodejs-mongo-aks, IIRC.

@wbreza knows the instructions for testing the ask template. There was something related to using a DevBox with access to CorpNet (when using playground sub)

[jongio]

I see this error too:

Which is why I think it's related to the other issue

[jongio]

I didn't run into that DevBox/CorpNet issue with the hello-ai aks project. So, I think the restriction Wallace was dealing was could have been resolved. This works:
https://github.com/jongio/hello-ai/

[vhvb1989]

I see this error too:

Which is why I think it's related to the other issue

oh! I will take a look to that!

[vhvb1989]

I didn't run into that DevBox/CorpNet issue with the hello-ai aks project. So, I think the restriction Wallace was dealing was could have been resolved. This works: https://github.com/jongio/hello-ai/

Did you set the azd env set WORKSPACE azure ?

[vhvb1989]

Here's an example,

After deploying aks template:

Deploying services (azd deploy)

  (✓) Done: Deploying service api
  - http://10.0.255.78:80 (Service: todo-api, Type: ClusterIP)
  - http://4.153.60.214/api (Ingress, Type: LoadBalancer)

  (✓) Done: Deploying service web
  - http://10.0.33.13:80 (Service: todo-web, Type: ClusterIP)
  - http://4.153.60.214 (Ingress, Type: LoadBalancer)

The ingress 4.153.60.214 is only accesible within the CorpNet. I can access it from my devBox:

But not from my host PC at home:

[vhvb1989]

I see this error too:

Which is why I think it's related to the other issue

fix for this: #4117

[jongio]

1. Let's see is this is expected behavior from @wbreza
2. Let's see if there's something that can be added to the readme and test plan updated for MS subs.

[wbreza]

@jongio This is an ingress networking security policy automatically configured against all Microsoft tenant subscriptions which block all inbound traffic to any VM backed resources.

Deploying this template to subscriptions outside of the Microsoft tenant will work as expected unless the subscription has similar policies in place.

[jongio]

Do we have anything documented for this in the README? What should we tell the end user?

If you are running on an internal sub, then you need to test this from a devbox. Here's the error you'll receive if you attempt to run outside of a devbox:

[jongio]

@Menghua1 - can you do a pr into azure-dev repo to add a note to the readme about this issue?

[Menghua1]

@Menghua1 - can you do a pr into azure-dev repo to add a note to the readme about this issue?

@jongio I created a pr here: #4235, please review.

[jongio]

Okay, let's close this now that we have something in the readme and please update the test cases to reflect this.

[Menghua1]

Okay, let's close this now that we have something in the readme and please update the test cases to reflect this.

@jongio Got it, I closed this issue. Could you please clarify what you mean by "the test cases"?

Additionally, in the latest test, when testing todo-nodejs-mongo-aks under on an internal sub and outside of the devbox, we do not encounter the error described in PR4235.