Istio’s configuration doesn’t automatically apply to all namespaces in your cluster; it needs to be explicitly told which ones to manage.
Let’s see how this plays out. Imagine you have a simple Istio setup with a default namespace and a staging namespace. You want to apply a PeerAuthentication policy to only your staging environment.
First, let’s check what policies are currently active and where.
istioctl analyze --all-namespaces
This command will scan your Istio configuration and report any potential issues or show you what’s applied where. If you haven’t scoped anything yet, you’ll likely see very little or no output related to policies, or perhaps some default warnings about missing configurations.
Now, let’s create a PeerAuthentication policy that will only apply to the staging namespace.
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: require-mtls
namespace: staging # <-- This is the key!
spec:
mtls:
mode: STRICT
Apply this to your cluster:
kubectl apply -f peer-authn-staging.yaml
If you were to run istioctl analyze --all-namespaces again, you would now see output indicating the require-mtls policy is active within the staging namespace. If you had another namespace, say production, and no policy was applied there, istioctl analyze would reflect that.
This scoping is fundamental to how Istio manages security and traffic. When Istio’s control plane (Istiod) watches for resources, it’s configured to look for these Istio-specific Custom Resource Definitions (CRDs) within specific namespaces. When you define a resource like PeerAuthentication or AuthorizationPolicy with a metadata.namespace field, you’re telling Istiod, "Monitor this resource and apply its rules to workloads within this specific namespace."
The primary mechanism for this is the metadata.namespace field on virtually all Istio CRDs. When Istiod starts, it registers watches for these CRDs. It doesn’t just watch for all CRDs cluster-wide; it’s designed to be namespace-aware. If a CRD is created without a namespace field (making it a cluster-scoped resource, which is rare for Istio policies), or if it’s in a namespace that Istio isn’t configured to manage, Istiod will simply ignore it.
Think of it like a librarian. Istiod is the librarian, and the namespaces are different sections of the library. When you place a book (an Istio configuration resource) in a specific section (a namespace), the librarian only looks for and organizes books within that section when asked to do so for that specific section. If you put a book in a section the librarian doesn’t care about, it’s as if the book isn’t there for the librarian’s purposes.
This namespace scoping is crucial for multi-tenancy and for managing different environments (dev, staging, prod) within the same Kubernetes cluster. You can enforce strict mTLS in production while allowing permissive mTLS in development, all by carefully placing your PeerAuthentication resources in the correct namespaces.
What most people don’t realize is that this scoping isn’t just about where the configuration is defined, but also about how Istio’s sidecars are instructed to behave. When a sidecar proxy in a pod within the staging namespace starts, it receives its configuration from Istiod. This configuration includes the policies that apply to its namespace, but not policies from other namespaces unless explicitly included via a DestinationRule or similar resource that references services across namespaces. The sidecar doesn’t get a giant dump of all Istio configurations in the cluster; it gets what’s relevant to its service and its namespace.
The next thing you’ll likely encounter is understanding how to apply configurations across namespaces, for example, when a service in one namespace needs to communicate with a service in another and you want to enforce policies between them.