Service authentication in the mesh
1. Service authentication in the mesh
Cloud Service Mesh offers a managed CA and tools to control the communication protocol. The certificate authority in a service mesh is called Mesh CA. And it's responsible for distributing, rotating, and managing certificates to provide identity. When pods are created, Mesh CA shares certificates and keys that are later used to verify identity in the network. Administrators control the communication protocol using destination rules and authentication policies. These policies are applied to the sidecar proxies and act as Policy Enforcement Endpoints, PEPs, to secure communication between the client and the server. Then traffic between services in the mesh can be secured with mTLS. The Mesh CA provisioning process consists of four steps. First, when a pod is created, a sidecar proxy is injected into the pod, containing an envoy proxy and an istio agent. The istio agent communicates with the control plane over gRPC, and issues a certificate-signing request so that the control plane can communicate with Mesh CA. Then Mesh CA sends the X.509 certificates to the istio agent. The istio agent uses the Envoy SDS API to send the certificates and the private key to Envoy. Finally, the istio agent monitors the expiration of the certificate. The process repeats periodically for certificate and key rotation. To confirm that the server is authorized to run the workload, its identity needs to be verified by Envoy using a feature called secure naming. Say a malicious user intercepts traffic to service B, and redirects it to a fake server. In this example, the user interfered with the DNS service. We see a compromised DNS service. But an attacker could have also compromised the BGP or ARP protocol. Because pod 3's certificate cannot be verified by the proxy's secure naming feature, any connection attempts from other services will be blocked. Administrators can use destination rules and peer authentication policies to specify the protocol used in the mesh. Destination rules offer granular control over communication by allowing you to specify the protocol TLS, mTLS, or plain text used for connections to specific services. And peer authentication policies provide broader control, enabling you to enforce protocols across an entire mesh, namespace, or specific workload. You can choose from several destination rule options. ISTIO_MUTUAL, establish secure connections to the upstream service using mutual TLS with client certificate authentication. MUTUAL is the same as ISTIO_MUTUAL, but with custom certificates. SIMPLE, it originates a TLS connection to the upstream endpoint. And DISABLE does not set up a TLS connection to the upstream endpoint. Peer authentication policies determine the level of TLS in the mesh. Workload-specific policies are specified with a namespace and a selector. Namespace-specific policies have a namespace, but not a selector. And mesh-wide policies don't have a namespace, but they can have a selector. Mesh-wide policies apply to all workloads across all namespaces in your service mesh. Use cases on why we would use such a broad policy include setting default security policies for the entire mesh, enforcing global authentication requirements, and providing a fallback mechanism when no namespace-specific or workload-specific policies are defined. For example, you might want to enable permissive mutual TLS mesh-wide, allowing services to gradually adopt stricter authentication. Then there are namespace-specific policies, which apply to all workloads within a specific namespace. Use cases include establishing a common security baseline for services within a namespace and simplifying policy management when all services in a namespace share similar security requirements. You could have a namespace-wide policy for your internal services where mutual TLS is strictly enforced, while another namespace for external-facing services might have more relaxed authentication. These policies are the most specific. They apply to individual workloads, pods within a namespace. These policies have a very narrow scope, and are ideal for fine-grained control over authentication requirements for a particular service; use of different authentication policies for different versions of the same service, for example, canary deployments; and isolation of specific workloads with stricter security requirements. For example, you might have a workload running a payment service that requires stronger authentication, for example, client certificate validation, than other workloads in the same namespace. If there are conflicts across policies, the workload-specific policy will take priority, followed by namespace-specific, and finally, mesh-wide. If a single level has multiple policies, for example, two policies that span across the mesh, the oldest policy will take effect. By strategically combining these policy scopes, you can create a layered security model that effectively protects your services in cloud service mesh. You can also specify the level of TLS enforcement. STRICT mandates mTLS for all communication. Both the client and server must present valid certificates to establish a connection. If a workload can't use mTLS, communication will be blocked. PERMISSIVE automatically negotiates the highest level of TLS supported by all communicating clients, allowing for connections ranging from plain text to full mTLS. This is ideal for gradually introducing mTLS into your environment, as it allows teams to enable TLS on their workloads at their own pace. DISABLE turns off TLS encryption entirely, leaving communication vulnerable to eavesdropping and tampering, and is strongly discouraged except in very specific testing or debugging scenarios. And UNSET disables pure authentication. Services don't need to present certificates to communicate. As with DISABLE, this mode is strongly discouraged outside of debugging scenarios.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.