Allow permissive traffic through the mesh

What you’ll accomplish

After completing this guide, you will have relaxed Istio’s strict authorization policies at the appropriate scope so that specific workloads or namespaces can receive traffic that would otherwise be denied by the mesh’s default deny-all model.

Prerequisites

• UDS CLI installed
• Access to a Kubernetes cluster with UDS Core deployed
• Confirmation that Package CR expose and allow rules cannot satisfy your traffic requirements

Before you begin

Danger

This guide is for exceptional cases only. UDS Core’s default deny-all authorization model exists to enforce zero-trust networking. Relaxing these policies weakens your security posture. Before proceeding, verify that your application truly cannot work within the standard model by declaring its traffic in the Package CR using expose and allow rules. In most cases, the correct solution is to properly declare your application’s traffic requirements — not to bypass the authorization model.

UDS Core uses Istio’s authorization policy model to enforce a deny-all posture by default. The UDS Operator automatically generates ALLOW authorization policies based on your Package CR expose and allow declarations. Any traffic not explicitly allowed is denied.

Some workloads need traffic that falls outside this model. Common examples include:

• Applications with unusual TLS handling — workloads that perform their own mTLS or have TLS configurations that conflict with Istio’s automatic mTLS, preventing the mesh from properly identifying the traffic source
• Traffic from sources outside the mesh — requests originating from components that are not part of the Istio service mesh (e.g., infrastructure controllers, legacy services, or external systems routing directly to pods)

In these cases, you can layer additional ALLOW authorization policies on top of the operator-generated ones. Istio evaluates DENY policies first, then ALLOW policies, so your additional ALLOW rules will not override any existing DENY policies.

Note

These authorization policies control the mTLS identity and authorization posture of the mesh. Kubernetes network policies still independently restrict pod-to-pod connectivity — traffic must be allowed by both layers. Any explicit allow entries in your Package CR are still required for Kubernetes-level network policy access.

Steps

1. Choose and apply your AuthorizationPolicy

   The options below are ordered from least permissive to most permissive. Always use the narrowest scope that meets your needs.

   Specific port

   This is the most restrictive option. It allows any source to reach a specific port on a specific workload:

   authz-policy.yaml

   apiVersion: security.istio.io/v1
   kind: AuthorizationPolicy
   metadata:
     name: permissive-ap-workload-port
     namespace: <package-namespace>
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app: my-app  # Your workload selector
     rules:
       - to:
           - operation:
               ports:
                 - "1234"

   Entire workload

   Allows any source to reach any port on a specific workload:

   authz-policy.yaml

   apiVersion: security.istio.io/v1
   kind: AuthorizationPolicy
   metadata:
     name: permissive-ap-workload
     namespace: <package-namespace>
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app: my-app  # Your workload selector
     rules:
       - {}

   Entire namespace

   Allows any source to reach any workload in the namespace:

   authz-policy.yaml

   apiVersion: security.istio.io/v1
   kind: AuthorizationPolicy
   metadata:
     name: permissive-ap-namespace
     namespace: <package-namespace>
   spec:
     action: ALLOW
     rules:
       - {}

2. Apply a PeerAuthentication policy

   Without a permissive PeerAuthentication, Istio will still enforce strict mTLS and reject connections from sources that cannot present a valid mesh identity — even if the AuthorizationPolicy allows them. Match the scope of your PeerAuthentication to the AuthorizationPolicy you chose in step 1.

   Specific port

   Use portLevelMtls to relax mTLS on only the specific port, keeping strict mTLS on all other ports:

   peer-auth.yaml

   apiVersion: security.istio.io/v1
   kind: PeerAuthentication
   metadata:
     name: permissive-pa
     namespace: <package-namespace>
   spec:
     selector:
       matchLabels:
         app: my-app  # Match the same workload as your AuthorizationPolicy
     mtls:
       mode: STRICT  # Keep strict mTLS as the default
     portLevelMtls:
       1234:  # Only this port accepts non-mTLS traffic
         mode: PERMISSIVE

   Entire workload

   Set the workload-level mode to PERMISSIVE for all ports on the selected workload:

   peer-auth.yaml

   apiVersion: security.istio.io/v1
   kind: PeerAuthentication
   metadata:
     name: permissive-pa
     namespace: <package-namespace>
   spec:
     selector:
       matchLabels:
         app: my-app  # Match the same workload as your AuthorizationPolicy
     mtls:
       mode: PERMISSIVE

   Entire namespace

   Omit the selector to apply permissive mTLS to all workloads in the namespace:

   peer-auth.yaml

   apiVersion: security.istio.io/v1
   kind: PeerAuthentication
   metadata:
     name: permissive-pa
     namespace: <package-namespace>
   spec:
     mtls:
       mode: PERMISSIVE

   See the Istio PeerAuthentication documentation for details on scoping options.

3. Include manifests in your Zarf package and deploy

   Add the AuthorizationPolicy and PeerAuthentication manifests to your application’s Zarf package, then build and deploy:

   uds zarf package create --confirm && uds zarf package deploy zarf-package-*.tar.zst --confirm

Verification

After applying the policies, verify they exist:

uds zarf tools kubectl get authorizationpolicy -n <namespace>
uds zarf tools kubectl get peerauthentication -n <namespace>

Test that the previously-blocked traffic now flows as expected.

Troubleshooting

Policy not taking effect

Symptoms: Traffic is still being denied after applying the authorization policy.

Solution:

• Verify the policy is in the correct namespace (must match the workload’s namespace)
• Check the selector labels match your workload: uds zarf tools kubectl get pods -n <namespace> --show-labels
• Remember that Istio evaluates DENY policies before ALLOW policies — if a DENY policy exists, your ALLOW policy will not override it
• Ensure you have also applied a permissive PeerAuthentication if the traffic source cannot present a valid mesh identity

Scope too broad

Symptoms: Unintended services are now receiving traffic they shouldn’t.

Solution:

• Narrow the scope: add a selector to target specific workloads, or add port restrictions
• Move from a namespace-scoped policy to a workload-scoped one

Related documentation

• Package CR Reference
• Istio Authorization Policy Documentation
• Istio PeerAuthentication Documentation

Next steps

These guides and concepts may be useful to explore next:

Networking & Service Mesh Concepts Learn how the service mesh, gateways, and authorization model work.

Define network access Configure intra-cluster and external network access for your application.