Modern microservice applications contain multiple services that communicate with one another over internal networks. Although these services may operate inside the same Kubernetes cluster or service mesh, network-level reachability does not necessarily mean that one workload should be permitted to access another workload.
Istio provides security controls for authenticating workloads and enforcing authorization policies between services. Istio mutual TLS can provide authenticated workload identity, while authorization policies can use the authenticated source identity to control access to target workloads. When peer authentication with mutual TLS is used, Istio exposes the authenticated workload identity through the `source.principal` authorization attribute.
In this use case, a controlled Istio service mesh is deployed on Ubuntu Linux inside an isolated VirtualBox laboratory. Multiple synthetic microservices are deployed to represent legitimate service-to-service communication.
A controlled unauthorized service-to-service access scenario is created by allowing a workload with a valid mesh identity to attempt communication with a protected service for which that workload has no authorization. The assessment verifies whether network reachability alone permits the unauthorized service to communicate with the protected workload and whether Istio can distinguish the authenticated workload identity from the authorization policy assigned to the target service.
Istio PeerAuthentication is used to enforce mutual TLS for protected workloads. Istio AuthorizationPolicy is then used to permit only explicitly authorized workload identities to access the protected service. Istio authorization policies support ALLOW, DENY, and CUSTOM actions, with DENY evaluated before ALLOW.
The controlled access attempt is generated from a test workload representing an unauthorized service. The workload possesses a valid Istio identity but attempts to access a service outside its permitted service-to-service authorization boundary. Kali Linux is used as the external security-testing environment for controlled service-discovery and validation activities, while Kubernetes test workloads generate the actual service-to-service requests inside the mesh.
Wazuh monitors relevant Ubuntu, Kubernetes, and security activity, while OpenSearch provides centralized investigation and correlation of the generated security telemetry. The same access attempts are repeated after the Zero Trust controls are configured to verify that unauthorized workload identities are denied while authorized service-to-service communication remains functional.
Complete Zero Trust Security Workflow: Istio Service Mesh → Workload Deployment → Workload Identity Assignment → Service-to-Service Communication → Unauthorized Access Attempt → mTLS Identity Verification → Source Workload Identification → Authorization Policy Evaluation → Unauthorized Request Denied → Security Event Monitoring → Authorized Communication Validation → Post-Remediation Verification
Istio is the target service-mesh platform in this use case. It provides service-to-service traffic management and security capabilities for workloads participating in the mesh. Istio authentication policies can enforce mutual TLS between workload proxies, while authorization policies can restrict access to workloads according to authenticated source identities and other request attributes.
Microservices may be able to establish network connections to other services even when the calling workload should not have permission to access the destination. If service-to-service authorization is not sufficiently restrictive, a compromised, misused, or unauthorized workload may attempt to communicate with protected internal services.
The security problem is therefore:
The proposed solution introduces workload identity verification, mutual TLS enforcement, source-principal validation, least-privilege authorization policies, unauthorized-request blocking, security monitoring, and post-remediation validation. The protected service evaluates the authenticated source workload identity against its authorization policy before permitting access.
The controlled attack evaluates whether a workload with valid mesh connectivity but without authorization to access a protected service can communicate with that service. The attacking workload is not required to forge or steal an identity. Instead, it represents a legitimate mesh workload whose identity is not authorized for the requested destination. This models a Zero Trust scenario in which a compromised or incorrectly authorized service attempts to move laterally toward another internal service. The assessment verifies whether Istio evaluates the identity of the requesting workload rather than relying only on network location or service reachability.
The primary security concept is workload identity-based Zero Trust authorization. The security decision is based on the identity of the workload initiating the connection rather than simply trusting that the request originated from inside the cluster or service mesh. Istio peer authentication can enforce mutual TLS between workloads. When mutual TLS is used, Istio can extract the peer workload identity and expose it as `source.principal` for authorization decisions.The authorization layer then determines whether the authenticated source workload is permitted to access the destination workload.Istios authorization model supports workload selectors and source conditions such as principals, allowing policies to restrict which service identities may access a protected workload.
The secure processing flow is:
Istio verifies the identity of workloads participating in service-to-service connections through the configured mesh authentication mechanism.
Ensure that service-to-service access decisions are associated with an authenticated workload identity rather than relying only on network location.
Strict mutual TLS is applied to protected workloads so that incoming service-to-service connections require authenticated mTLS. Istio PeerAuthentication supports STRICT mode, which requires mTLS for incoming connections to the selected workload.
Prevent protected workloads from accepting unauthenticated plaintext service-to-service connections.
The authenticated source workload identity is evaluated through Istio authorization attributes such as `source.principal`.
Associate each service-to-service request with the authenticated workload identity that initiated it.
Authorization policies are configured so that protected services accept requests only from explicitly authorized workload identities.
Restrict service-to-service communication to the minimum required workload relationships.
Requests from authenticated workloads that do not satisfy the target service authorization policy are denied.
Prevent valid but unauthorized workload identities from accessing protected services.
Permitted workload-to-service relationships are explicitly defined instead of relying on implicit internal-network trust.
Establish a controlled service communication boundary for the Zero Trust architecture.
Relevant access-control and workload activity is collected for security monitoring and investigation.
Provide visibility into unauthorized service-to-service access attempts and policy enforcement.
The same unauthorized and authorized access scenarios are repeated after policy enforcement.
Verify that unauthorized service identities remain blocked while approved service communication continues to operate.
Istio provides the service-mesh security architecture used to authenticate workloads and enforce service-to-service authorization.
Kubernetes hosts the controlled microservices used to demonstrate authorized and unauthorized service-to-service communication.
Istio mutual TLS provides authenticated communication between participating workloads. Istio can use the authenticated peer identity when processing authorization decisions.
`AuthorizationPolicy` defines which workload identities can access the protected service. Istio authorization policies support ALLOW, DENY, and CUSTOM actions and can evaluate source workload identity attributes.
Kubernetes service accounts provide the workload identity association used by the laboratory services and are represented in Istio workload identity information.
Kali Linux provides the controlled security-testing environment for service discovery and application-level validation.
Ubuntu Linux hosts the controlled Kubernetes and Istio security laboratory.
Wazuh monitors relevant Ubuntu, Kubernetes, and security activity associated with the controlled service-mesh assessment.
OpenSearch provides centralized investigation of the security telemetry generated during the assessment.
VirtualBox provides the isolated laboratory infrastructure for the controlled Zero Trust service-mesh assessment.
Research Breakthrough Possible @S-Logix