Skip to content

feat: Restrict backend Container App access in WAF deployment#939

Merged
Roopan-Microsoft merged 2 commits intodev-v4from
feature/39249-waf-api-private-access-clean
Apr 22, 2026
Merged

feat: Restrict backend Container App access in WAF deployment#939
Roopan-Microsoft merged 2 commits intodev-v4from
feature/39249-waf-api-private-access-clean

Conversation

@Prajwal-Microsoft
Copy link
Copy Markdown
Contributor

Purpose

When enablePrivateNetworking (WAF mode) is active, the backend Container App URL should not be exposed to the browser. This PR adds an application-layer proxy so the browser only communicates with the frontend App Service.

Changes

Infrastructure (infra/main.bicep & infra/main_custom.bicep):

  • Added PROXY_API_REQUESTS env var to frontend App Service (true in WAF mode)

Frontend (src/App/):

  • frontend_server.py: Added httpx-based reverse proxy for /api/* routes. /config returns same-origin /api URL in WAF mode so the browser never sees the Container App URL
  • requirements.txt: Added httpx dependency

Post-deploy scripts:

  • Both PowerShell and Bash scripts detect WAF mode (checks PROXY_API_REQUESTS setting) and route API calls through the frontend proxy

Architecture (WAF mode)

Browser -> Frontend App (public) -> FastAPI /api/* proxy -> Container App (VNet)

Non-WAF deployments are unchanged — browser calls backend directly.

Resolves AB#39249

Does this introduce a breaking change?

  • Yes
  • No

How to Test

Deploy with WAF parameters and verify:

  • /config returns {"API_URL":"/api"} (same-origin)
  • All use cases work through the frontend proxy
  • Post-deploy script detects WAF mode and routes through frontend

What to Check

  • Frontend proxies API calls correctly in WAF mode
  • Non-WAF deployment still works as before
  • Post-deploy scripts upload team configs successfully

Other Information

Related PRs: microsoft/customer-chatbot-solution-accelerator#173, microsoft/Conversation-Knowledge-Mining-Solution-Accelerator#861
Replaces PR #904 (which had unrelated merge commits from dev-v4)

When enablePrivateNetworking (WAF mode) is active:

Infrastructure:
- Set Container App Environment to internal with public access disabled
- Create private DNS zone for the CAE default domain linked to VNet
- Add wildcard A record pointing to CAE static IP for DNS resolution
- Frontend App Service gets PROXY_API_REQUESTS=true env var

Frontend:
- FastAPI server proxies /api/* requests to backend via httpx over VNet
- /config endpoint returns same-origin /api URL in WAF mode
- Added httpx dependency

Post-deploy scripts:
- Detect internal ingress / IP restrictions / PROXY_API_REQUESTS
- Route API calls through frontend App Service proxy

Non-WAF deployments remain unchanged.

Resolves AB#39249

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The frontend proxy only handled HTTP requests but MACAE uses WebSocket
connections for real-time agent streaming. Add a WebSocket proxy route
that forwards wss:// connections to the private backend Container App
over the VNet using the websockets library.

Also fix Dockerfile BuildKit --mount issue for ACR Task builds.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@Roopan-Microsoft Roopan-Microsoft merged commit 22a8688 into dev-v4 Apr 22, 2026
17 of 19 checks passed
@Prajwal-Microsoft Prajwal-Microsoft deleted the feature/39249-waf-api-private-access-clean branch April 22, 2026 16:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants