Module 1: Exercises

This exercise section provides hands-on practice with OpenShift Service Mesh 3. You will learn how to enable sidecar injection and configure mutual TLS (mTLS) for your applications.

Prerequisites

Before starting these exercises, ensure you have:

Access to an OpenShift cluster with Service Mesh 3 installed
Cluster administrator or project administrator permissions
The oc CLI tool installed and configured
A project namespace where you can deploy applications

Exercise 1: Enable Sidecar Injection

In this exercise, you will enable automatic sidecar injection for a namespace in OpenShift Service Mesh 3.

Understanding Istio CNI

Before verifying the installation, it’s important to understand the role of Istio CNI (Container Network Interface) in the service mesh architecture.

Istio CNI is a critical component that handles network configuration for pods in the service mesh. Its primary purpose is to:

Traffic Redirection: Sets up rules to route pod traffic through the Envoy sidecar without needing extra privileges.
Security: Removes the need for NET_ADMIN and NET_RAW, making pods safer.
Transparency: Automatically intercepts all pod traffic.
Initialization: Prepares networking before the app starts.

Without Istio CNI, sidecar injection would require pods to run with elevated privileges. The CNI plugin configures networking securely at pod startup.

Step 1: Verify Service Mesh Installation

First, verify that OpenShift Service Mesh 3 is installed and all critical components are running. Check the Istio control plane pods:

oc get pods -n istio-system

You should see the Istio control plane components running, including istiod pods. Verify they are in Running state:

oc get pods -n istio-system -l app=istiod

Next, verify that Istio CNI is installed and running. The CNI components are deployed in the istio-cni namespace as DaemonSets to run on each node:

oc get pods -n istio-cni

You should see Istio CNI pods running on each node in your cluster. Verify they are in Running state:

oc get daemonset -n istio-cni

Step 2: Set Your Namespace

Set the NAMESPACE environment variable to your existing sandbox namespace. Replace {USER} with your actual username:

export NAMESPACE={USER}-sandbox

For example, if your username is jdoe, your namespace would be jdoe-sandbox:

export NAMESPACE=jdoe-sandbox

Verify that the namespace exists:

oc get namespace $NAMESPACE

Step 3: Enable Sidecar Injection

Enable automatic sidecar injection by adding the revision label to your namespace. The revision label specifies which Istio control plane revision to use for sidecar injection. For Istio version 1.23, use:

oc label namespace $NAMESPACE istio.io/rev=default-1.23.0

The revision value should match your Istio installation revision. This example uses default-1.23.0 for Istio version 1.23.

Step 4: Verify Sidecar Injection Label

Verify that the revision label has been applied:

oc get namespace $NAMESPACE --show-labels

You should see istio.io/rev=default-1.23.0 in the labels list.

Step 5: Deploy a Test Application

Deploy a simple application to verify that sidecar injection is working:

oc apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-app
  namespace: ${NAMESPACE}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test-app
  template:
    metadata:
      labels:
        app: test-app
    spec:
      containers:
      - name: test-container
        image: nginx:latest
        ports:
        - containerPort: 80
EOF

Step 6: Verify Sidecar Injection

Check that the Envoy sidecar has been injected into your pod:

oc get pods -n $NAMESPACE -l app=test-app

Describe the pod to see all containers:

oc describe pod -n $NAMESPACE -l app=test-app | grep -A 10 "Containers:"

You should see two containers: your application container and the istio-proxy sidecar container.

Exercise 2: Enable Mutual TLS (mTLS)

In this exercise, you will configure mutual TLS for your namespace using OpenShift Service Mesh 3.

Step 1: Create a PeerAuthentication Policy

Create a PeerAuthentication resource to enable strict mTLS for your namespace:

oc apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: ${NAMESPACE}
spec:
  mtls:
    mode: STRICT
EOF

This policy enforces mTLS for all traffic within your namespace.

Step 2: Verify PeerAuthentication Policy

Verify that the PeerAuthentication policy has been created:

oc get peerauthentication -n $NAMESPACE

Step 3: Create a DestinationRule (Optional but Recommended)

While PeerAuthentication enables mTLS, it’s a best practice to also create a DestinationRule to explicitly specify the TLS mode:

oc apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: default
  namespace: ${NAMESPACE}
spec:
  host: "*.${NAMESPACE}.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
EOF

This DestinationRule ensures that all services in the namespace use Istio-managed certificates for mTLS.

Step 4: Verify mTLS Configuration

Check the Istio configuration to verify mTLS is enabled:

oc get peerauthentication -n $NAMESPACE -o yaml
oc get destinationrule -n $NAMESPACE -o yaml

Step 5: Test mTLS Connection

Deploy a second application to test mTLS communication:

oc apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-app-2
  namespace: ${NAMESPACE}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test-app-2
  template:
    metadata:
      labels:
        app: test-app-2
    spec:
      containers:
      - name: test-container
        image: curlimages/curl:latest
        command: ["sleep", "3600"]
EOF

Wait for the pod to be ready, then exec into it and test connectivity:

POD_NAME=$(oc get pod -n $NAMESPACE -l app=test-app-2 -o jsonpath='{.items[0].metadata.name}')
oc exec -n $NAMESPACE $POD_NAME -c test-container -- curl -v http://test-app:80

The connection should succeed, and you can verify in the Envoy access logs that mTLS is being used.

Step 6: View Envoy Access Logs

To verify mTLS is working, check the Envoy sidecar logs:

POD_NAME=$(oc get pod -n $NAMESPACE -l app=test-app-2 -o jsonpath='{.items[0].metadata.name}')
oc logs -n $NAMESPACE $POD_NAME -c istio-proxy | tail -20

Look for log entries indicating TLS connections.

Exercise 3: Verify mTLS Configuration

In this exercise, you will verify mTLS configuration using various methods.

Step 1: Check PeerAuthentication and DestinationRule Resources

Verify the mTLS policies are correctly applied by checking the resources:

oc get peerauthentication -n $NAMESPACE -o yaml
oc get destinationrule -n $NAMESPACE -o yaml

This shows the PeerAuthentication and DestinationRule configurations that enforce mTLS.

Step 2: Verify mTLS in Envoy Configuration

Check the Envoy sidecar configuration to verify mTLS is enabled. Get the name of a pod:

POD_NAME=$(oc get pod -n $NAMESPACE -l app=test-app -o jsonpath='{.items[0].metadata.name}')

If istioctl is available, you can check the proxy configuration:

istioctl proxy-config cluster $POD_NAME -n $NAMESPACE | grep -i tls

This shows the TLS settings for outbound clusters.

Step 3: Verify mTLS from Application Logs

Check the Envoy access logs to verify mTLS connections. The logs should show TLS protocol information:

POD_NAME=$(oc get pod -n $NAMESPACE -l app=test-app-2 -o jsonpath='{.items[0].metadata.name}')
oc logs -n $NAMESPACE $POD_NAME -c istio-proxy | grep -i tls

You can also check for successful mTLS handshakes in the logs.

Summary

In these exercises, you have:

Enabled automatic sidecar injection for a namespace
Verified that the Envoy sidecar is injected into application pods
Configured mutual TLS (mTLS) using PeerAuthentication and DestinationRule resources
Tested mTLS communication between services
Verified mTLS configuration using istioctl

These foundational skills will be essential as you progress through the remaining modules of this workshop.

Troubleshooting

If you encounter issues:

Sidecar not injecting: Verify the namespace revision label is correct (istio.io/rev=<revision>) and matches your Istio installation revision. Ensure the Istio control plane is running.
mTLS not working: Ensure both PeerAuthentication and DestinationRule are properly configured
Connection failures: Check that both pods have sidecars injected and are in the same namespace (or that proper policies exist for cross-namespace communication)
Access denied: Verify that the Istio control plane pods (istiod) are running and that certificates are being issued by checking the istiod logs