Verify our Red Hat Service Mesh integration

Since verifying full Service Mesh integration often depends on your specific microservices, we'll focus on two key checks: confirming the Secure Production Identity Framework for Everyone (SPIFFE) identity material and performing a basic header verification test against an existing mesh-integrated service.

Prerequisites:

• Red Hat OpenShift Container Platform (OCP) 4.16 or higher
• Red Hat OpenShift Service Mesh (OSSM) 3.x
• Red Hat OpenShift Virtualization

In this lesson, you will:

• Confirm the SPIFFE identity material within your Service Mesh integration.
• Perform a basic header verification test against an existing integrated service.

Confirm SPIFFE authorization material

The core of the VM's zero trust identity within the mesh relies on the correct certificate being issued and placed on the system. This key authorizes the VM's service account identity according to the SPIFFE specification.

On your VM, confirm the existence of the critical private key file:

ls -l /etc/certs/

Expected result: You should find a key.pem file (and likely an associated cert-chain.pem and root-cert.pem).

• key.pem: The private key used by the Envoy proxy to authenticate the VM's ServiceAccount identity.
• cert-chain.pem: The trust of the Certificate Chain.
• root-cert.pem: The mesh-wide root certificate used to validate the Pilot and other workloads.

Verify mesh connectivity (Header echo test)

To confirm the VM is not only in the mesh but can communicate securely with other services, you can attempt to access an existing mesh-integrated service that echoes back request headers. This confirms mutual Transport Layer Security (mTLS) and traffic routing are functional.

Use curl on your VM to access an internal service (a simple Hello World application) and check for the presence of specific headers:

curl mockbin.ns1.svc:8080 -s | \
  jq -r '.headers."x-forwarded-client-cert"'

Example output:

By=spiffe://cluster.local/ns/ns1/sa/default;Hash=85dd5eb222addf71e695d40c2b14de71f811b4f543cf9b9da769749362f071e5;Subject="";URI=spiffe://cluster.local/ns/vms/sa/mesh

The output values of spiffe://cluster.local/ns/vms/sa/mesh indicate that the request originated from the VM workload, successfully finding the source identity. Meanwhile, the output of  spiffe://cluster.local/ns/ns1/sa/default means that the target microservice, or destination identity, received the request successfully. 

This confirms the following critical successes:

• Mutual TLS (mTLS) is active: The communication was not plain HTTP; it was secured and authenticated via Istio's mTLS.
• Identity propagation: The Istio control plane successfully issued and validated the VM's secure identity (ns/vms/sa/mesh).
• Cross-Namespace communication: The legacy workload in the vms namespace can securely interact with containerized microservices in the ns1 namespace.

Welcome your virtual machine to your microservice service mesh! 

Summary

Congratulations. You have successfully bridged the gap, transforming a legacy VM into a fully compliant, zero trust workload within your Red Hat OpenShift Service Mesh. This methodology now opens the door to applying uniform security, telemetry, and traffic policies across your entire fleet, regardless of any underlying compute infrastructure.

Ready to learn more about VMs and service meshes?

Check out these learning resources: