Cloud Service Mesh security overview

Cloud Service Mesh security helps youmitigate insider threats andreduce therisk of a data breach by ensuring that all communications between workloadsare 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 ofservice context-awareandrequest context-aware network security that is independent of the securityof the underlying network. Because of this, Cloud Service Mesh lets you adopt adefense-in-depth posture that is consistent withZero Trust securityprinciples. It lets you achieve this posture through declarative policiesand without modifying any application code.

mutual TLS

Cloud Service Mesh uses mutual TLS (mTLS) for peer authentication. Authenticationrefers to identity: who is this service? who is this end-user? and can I trustthat 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 1.6 and later, auto mTLS is enabled by default. With automTLS, a client sidecar proxy automatically detects if the server has a sidecar.The client 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.

Cipher suite configuration

The following list includes Cloud Service Mesh's default, FIPS-compliant ciphersuites:

ECDHE-ECDSA-AES128-GCM-SHA256ECDHE-RSA-AES128-GCM-SHA256ECDHE-ECDSA-AES256-GCM-SHA384ECDHE-RSA-AES256-GCM-SHA384

For improved security, the server-side minimum TLS version supported byCloud Service Mesh workloads is 1.2, which supports customizing cipher suites.Note that Cloud Service Mesh also supports TLS v1.3, which hard-codes cipher suitesanddoes not support changing them.

For more information on cipher suites, seeEnvoy's common TLS configuration andIstio's Mutual TLS authentication.

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 to authenticatepeers, 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 by simplyreplaying 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. You canalso use IP-based access policies to grant access to clients deployed outsidethe GKE Enterprise environment.

• 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. Thismitigates the risk that the compromise of a single client credential grants anattacker access to all user data.

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

Features

This section describes the features that Cloud Service Mesh provides to realizeits 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 of rotatingmTLS keys and certificates for GKE Enterprise 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 private certificateauthority,Cloud Service Mesh certificate authority, for issuing certificates for mTLS.Cloud Service Mesh certificate authority is a highly reliable and scalable service that isoptimized 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 GKE Enterprise clusters. When using Cloud Service Mesh certificate authority, you canrely on workload identity pools to provide coarse-grained isolation. Bydefault, authentication fails 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

• privateca.workloadCertificateRequester
• privateca.auditor

Identity-aware access control (firewall) policies

With Cloud Service Mesh, you can configure network security policies that arebased on the mTLS identity versus the IP address of the peer. This lets youcreate policies that are independent of the network location of the workload.Only communications across clusters in the same Google Cloud project are currentlysupported.

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 you assertthat a JWT is signed by a trusted entity. This means that you can configurepolicies that allow access from certain clients only if a request claim existsor matches a specified value.

User authentication with Identity-Aware Proxy

You authenticate users that are accessing any service exposed on anCloud Service Mesh ingress gateway by usingIdentity-Aware Proxy (IAP). IAP can authenticate usersthat 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 to providebrowser-based end-user authentication and access control to your deployedworkloads. 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. Youcan also choose to configure a private destination. Cloud Service Mesh letsyou reduce noise in access logs by only logging successful accesses once in aconfigurable time window. Requests that are denied by a security policy orresult in an error are always logged. This lets you significantly reduce thecosts associated with ingesting, storing, and processing logs, without the lossof key security signals.

FIPS compliant

All in-cluster control plane components and proxies on x86 architecture useFIPS 140-2 validated encryptionmodules.

Limitations

Cloud Service Mesh security currently has the following limitation:

• User authentication that uses IAP requires that a service bepublished to the internet. IAP and Cloud Service Mesh let youconfigure policies that can restrict access to authorized users and clients in anallowed IP range. If you choose to only expose the service to clients withinthe same network, you need to configure a custom policy engine for userauthentication and token issuance.

What's next

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