This demonstration highlights the differences between no Peer Authentication Policy and enforcing Mutual TLS in an Istio-enabled environment.
In this demonstration, we explore the differences between having no Peer Authentication Policy and enforcing Mutual TLS (mTLS) in an Istio-enabled environment. You will see how applying a STRICT mTLS policy to the default namespace prevents services from unauthorized access by workloads from other namespaces.
Step 2: Setting Up the Bar Namespace and Deploying HTTP Bin
Create a separate namespace named “Bar” to deploy the HTTP Bin application. This application will allow you to perform curl requests between namespaces. If Istio auto-injection is disabled in your environment, manually inject the Istio sidecar using this command:
Copy
Ask AI
kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n bar
This command ensures that the Istio proxy is properly injected into the HTTP Bin deployment. The output should be similar to:
Copy
Ask AI
serviceaccount/httpbin createdservice/httpbin createddeployment.apps/httpbin created
With HTTP Bin deployed in the Bar namespace, you can now test connectivity to the product page in the default namespace. Initially, you might encounter an error if the Istio proxy container is still initializing. Once the container is ready, execute the following command:
Copy
Ask AI
kubectl exec -it "$(kubectl get pod -l app=httpbin -n bar -o jsonpath={.items[0].metadata.name})" -c istio -- curl "http://productpage.default:9080" -s -o /dev/null -w "%{http_code}\n"
A response with an HTTP status code of 200 confirms that the Bar namespace can successfully access the product page in the default namespace.
Step 4: Enforcing Mutual TLS with a Peer Authentication Policy
To secure communications, apply a Peer Authentication Policy to enforce STRICT Mutual TLS in the default namespace. This configuration ensures that only workloads with valid mTLS certificates can communicate within the namespace.Apply the policy with the following command:
The output should confirm that the policy was successfully created:
Copy
Ask AI
peerauthentication.security.istio.io/default created
Enforcing STRICT mTLS means that any workload without the proper mTLS configuration will be unable to communicate with services in the default namespace.
This command should now fail with exit code 56, indicating that the communication attempt was blocked because the workload in the Bar namespace is not secured with mTLS.
Before enforcing STRICT mTLS, ensure that all relevant workloads are properly configured with mTLS to prevent unintended service disruptions.
This demonstration highlights how enabling STRICT Mutual TLS via Istio’s Peer Authentication Policy can help secure your environment by ensuring that only authorized, mTLS-enabled traffic is allowed between namespaces.
