Cloud Service Mesh security overview

Note: This guide only supports Cloud Service Mesh with Istio APIs and doesnot support Google Cloud APIs. For more information see,Cloud Service Mesh overview.

Cloud Service Mesh with Istio APIs security helps youmitigate insider threatsandreduce the risk of a data breach by ensuring that all communicationsbetween workloads are encrypted, mutually authenticated, and authorized.

Traditionally, micro-segmentation that uses IP-based rules has been used tomitigate insider risks. However, the adoption of containers, shared services,and distributed production environments spread across multiple clouds makes thisapproach harder to configure and even harder to maintain.

With Cloud Service Mesh, you can configure a layer ofservicecontext-aware andrequest context-aware network security that is independentof the security of the underlying network. Because of this,Cloud Service Mesh lets you adopt a defense-in-depth posture that isconsistent withZero Trust security principles. It lets you achieve thisposture through declarative policies and without modifying any application code.

mutual TLS

Cloud Service Mesh uses mutual TLS (mTLS) for peer authentication.Authentication refers to identity: who is this service? who is this end-user?and can I trust that they are who they say they are?

mTLS makes it possible for workloads to verify each other's identities andauthenticate with each other. You might be familiar with simple TLS through itsuse in HTTPS to allow browsers to trust web servers and to encrypt the data thatis exchanged. When simple TLS is used, the client establishes that the servercan be trusted by validating its certificate. mTLS is an implementation of TLSin which both client and server present certificates to each other and verifyeach other's identities.

mTLS is the means by which Cloud Service Mesh implements bothauthentication andencryption between services.

In Cloud Service Mesh, auto mTLS is enabled by default. With auto mTLS, aclient sidecar proxy automatically detects if the server has a sidecar. Theclient sidecar sends mTLS to workloads with sidecars and sends plain text toworkloads without sidecars. Note, however, servicesaccept both plain-text andmTLS traffic. To secure your service mesh, we recommend that you migrate yourservices to only accept mTLS traffic.

For more information on enforcing only mTLS, seeCloud Service Mesh by example: mTLS.

Security benefits

Cloud Service Mesh provides the following security benefits:

• Mitigates risk of replay or impersonation attacks that use stolencredentials. Cloud Service Mesh relies on mTLS certificates toauthenticate peers, rather than bearer tokens such asJSON Web Tokens (JWT).Because mTLS certificates are bound to the TLS channel, it is not possible foran entity within your production environment to impersonate another byreplaying the authentication token without access to the private keys.

• Ensures encryption in transit. Using mTLS for authentication also ensuresthat all TCP communications are encrypted in transit.

• Ensures that only authorized clients can access a service with sensitivedata. Only authorized clients can access a service with sensitive datairrespective of the network location of the client and the application-levelcredentials. You can specify that only clients with authorized serviceidentities or in authorized Kubernetes namespaces can access a service. Youcan also use IP-based access policies to grant access to clients deployedoutside the clients outside the mesh.

• Mitigates the risk of user data breach within your production network. Youcan ensure that insiders can only access sensitive data through authorizedclients. Furthermore, you can ensure that certain clients can only gain accessto user data if the client can present a valid and short-lived user token.This mitigates the risk that the compromise of a single client credentialgrants an attacker access to all user data.

• Identifies which clients accessed a service with sensitive data.Cloud Service Mesh access logging captures the mTLS identity of theclient in addition to the IP address. Thus, you can understand which workloadaccessed a service even if the workload is ephemeral and dynamicallydeployed, and in a different cluster or Virtual Private Cloud (VPC) network.

Features

This section describes the features that Cloud Service Mesh provides torealize its security benefits.

Automatic certificate and key rotation

Using mTLS based on service identities makes it possible to encrypt all TCPcommunications and provides a more secure non-replayable credential for accesscontrol. One of the key challenges of using mTLS at scale is managing the keysand certificates for all target workloads. Cloud Service Mesh takes care ofrotating mTLS keys and certificates for mesh workloads without disruptingcommunications. Configuration of smaller cert refresh intervals is possible toreduce risk.

Cloud Service Mesh certificate authority

Cloud Service Mesh includes a managed multi-regional privatecertificate authority,Cloud Service Mesh certificate authority, for issuing certificates formTLS. Cloud Service Mesh certificate authority is a highly reliable and scalable service thatis optimized for dynamically scaled workloads on a cloud platform. WithCloud Service Mesh certificate authority, Google manages the security and availability of theCA backend. Cloud Service Mesh certificate authority lets you rely on a single root of trustacross clusters. When using Cloud Service Mesh certificate authority, you can rely on workloadidentity pools to provide coarse-grained isolation. By default, authenticationfails if the client and the server are not in the same workload identity pool.

Certificates from Cloud Service Mesh certificate authority include the following data aboutyour application's services:

• The Google Cloud project ID
• The GKE namespace
• The GKE service account name

Important: The certificates issued by Cloud Service Mesh certificate authority should only beused to enable secure service-to-service communication within your service mesh,and not be used for any other purpose. These certificates are sent wheneverservices attempt to communicate with each other using mutual TLS. Make sure thatyou don't inadvertently expose confidential information by using thesecertificates when communicating outside your service mesh.

Certificate Authority Service

As an alternative to Cloud Service Mesh certificate authority, you can configureCloud Service Mesh to use Certificate Authority Service, which is suitable forthe following use cases:

• If you need different certificate authorities to sign workload certificates ondifferent clusters.
• If you need to back your signing keys in a managed HSM.
• If you are in a highly regulated industry and are subject to compliance.
• If you want to chain your Cloud Service Mesh CA to a customenterprise root certificate to sign workload certificates.

The cost of Cloud Service Mesh certificate authority is included in theCloud Service Mesh pricing. The cost of CA Service isn'tincluded in the base Cloud Service Mesh price and is chargedseparately. Additionally, CA Service comes with an explicit SLA,but Cloud Service Mesh certificate authority does not.

For this integration, all workloads in Cloud Service Mesh are granted twoIAM roles:

• privateca.workloadCertificateRequester
• privateca.auditor

Identity-aware access control (firewall) policies

With Cloud Service Mesh, you can configure network security policiesthat are based on the mTLS identity versus the IP address of the peer. This letsyou create policies that are independent of the network location of the workload.Only communications across clusters in the same Google Cloud project are supported.

Request claims-aware access control (firewall) policies

In addition to the mTLS identity, you can grant access based on request claimsin the JWT header of HTTP or gRPC requests. Cloud Service Mesh lets youassert that a JWT is signed by a trusted entity. This means that you canconfigure policies that allow access from certain clients only if a requestclaim exists or matches a specified value.

User authentication with Identity-Aware Proxy

You authenticate users who are accessing any service exposed on aCloud Service Mesh ingress gateway by usingIdentity-Aware Proxy (IAP). IAP can authenticate userswho are logging in from a browser, integrate with custom identity providers,and issue a short-lived JWT token or an RCToken that can then be used to grantaccess at the Ingress gateway or a downstream service (by using a side-car).For more information, seeIntegrating IAP with Cloud Service Mesh.

User authentication with your existing Identity Provider

You can integrate your existing Identity Provider with Cloud Service Mesh toprovide browser-based end-user authentication and access control to yourdeployed workloads. For more information, seeConfiguring Cloud Service Mesh user authentication.

Access logging and monitoring

Cloud Service Mesh ensures that access logs and metrics are available inGoogle Cloud Observability, and provides an integrated dashboardto understand access patterns for a service or workload based on this data.

FIPS compliant

The data plane component usesFIPS 140-2 validated encryptionmodules.

Limitations

Cloud Service Mesh security has the following limitation:

• User authentication that uses IAP requires that a service bepublished to the internet. IAP and Cloud Service Meshlet you configure policies that can restrict access to authorized users andclients in an allowed IP range. If you choose to only expose the service toclients within the same network, you need to configure a custom policy enginefor user authentication and token issuance.

What's next

• Cloud Service Mesh security best practices
• Configure transport security
• Update your authorization policies