You can run a publicly hosted application (for example, an application hosted in Azure) that accesses a SAS Viya endpoint that is reachable on only a private network. When the request originates from a public site and targets a private-network address, Chromium-based browsers can apply Local Network Access (LNA), or earlier Private Network Access (PNA), security protections.
Chrome and Microsoft Edge document that these protections apply when a public origin makes network requests to private IP address space or loopback targets.
Cause
Chromium browsers introduced Private Network Access (PNA) to restrict public-origin access to private-network resources. Although the original PNA experiment was later superseded by Local Network Access (LNA), the same public-to-private request class remains the relevant security boundary for this use case.
When the browser uses the PNA preflight flow, it sends an HTTP OPTIONS request that includes Access-Control-Request-Private-Network: true. In that case, the target server must respond to the preflight request with the following header:
Access-Control-Allow-Private-Network: true
This requirement applies both to the original PNA preflight-only model and to current LNA enforcement when that preflight path is used. If the required response header is missing, the browser blocks the request before it reaches SAS Viya.
Resolution
For SAS Viya deployments that use ingress-nginx, configure the ingress-nginx controller to add the following response header:
Access-Control-Allow-Private-Network: true
You can add this response header by using the ingress-nginx controller-level add-headers configuration. The ingress-nginx documentation describes add-headers as the supported mechanism for injecting custom HTTP response headers before traffic is returned to the client.
Note: The add-headers setting applies at the controller level and injects the configured headers into all responses handled by that controller. Browsers evaluate Access-Control-Allow-Private-Network only when processing applicable PNA or LNA preflight requests.
This SAS KB article describes one supported implementation path.
Configure ingress-nginx to Add the Response Header
- Create a ConfigMap that contains the custom header.
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-headers
namespace: ingress-nginx
data:
Access-Control-Allow-Private-Network: "true"
This approach uses the standard ingress-nginx custom-headers pattern, where a ConfigMap defines the response headers that the controller adds to outgoing responses.
Security Note: If the environment also uses CORS, review the configured Access-Control-Allow-Origin values and avoid overly broad origin settings.
- Update the ingress-nginx controller ConfigMap.
apiVersion: v1
kind: ConfigMap
metadata:
name: ingress-nginx-controller
namespace: ingress-nginx
data:
add-headers: "ingress-nginx/custom-headers"
The ingress-nginx documentation specifies that response headers injected by the controller must be referenced using the add-headers key pointing to the namespace and name of the header ConfigMap.
- Restart the ingress-nginx controller.
Changes to custom-header ConfigMaps do not automatically reload running ingress-nginx controller pods. Perform a rolling restart of the ingress-nginx controller deployment so that the updated configuration is applied.
Additional Browser Policy Requirement for Managed Google Chrome and Microsoft Edge Environments
In managed Google Chrome and Microsoft Edge environments, administrators typically must also allowlist the public application origin by using Local Network Access browser policy, which complements the ingress-nginx response-header configuration.
Google Chrome
Use the LocalNetworkAccessAllowedForUrls policy to allowlist the public application origin.
- The policy is supported starting with Chrome 139.
- Local Network Access permission prompting and enforcement begin with Chrome 142.
- Origins matching this policy are exempt from Local Network Access checks.
Microsoft Edge
The applicable policy depends on the Microsoft Edge version in use:
- Microsoft Edge versions 140–145: Use LocalNetworkAccessAllowedForUrls.
- Microsoft Edge version 146 and later: Use LocalNetworkAllowedForUrls, which has higher precedence when multiple local-network policies are configured. LocalNetworkAccessAllowedForUrls remains documented as an older related policy.
For managed browser deployments, configure both:
- the SAS Viya ingress-nginx response header described in this article
- the appropriate browser allowlist policy for the public application origin
This approach aligns the SAS Viya response with browser-documented PNA preflight behavior and addresses current Local Network Access enforcement in managed Chromium browsers.
Verification
You can verify the ingress-nginx configuration by examining the generated nginx.conf file in an ingress-nginx controller pod and confirming that the custom header ConfigMap is referenced.
kubectl exec <ingress-nginx-controller-pod> -n ingress-nginx -- cat /etc/nginx/nginx.conf
To confirm the behavior from the client perspective, inspect the HTTP response returned through the ingress and verify that it includes the following:
Access-Control-Allow-Private-Network: true
You can do this validation by using browser developer tools or other HTTP header inspection tools during a test request.
Additional Notes
This SAS KB article is intentionally limited to the SAS Viya use case where a publicly hosted application accesses a private-network SAS Viya endpoint and where ingress-nginx is used as the ingress controller.
If the public application is embedded inside a cross-origin iframe, additional browser configuration might be required. Chromium browsers document that the embedding document must explicitly delegate permission to the iframe using the following:
allow="local-network-access"
In this scenario, the ingress response header and browser allowlist policy alone might not be sufficient.