Anthos Service Mesh security helps you mitigate insider threats and reduce the risk of a data breach by ensuring that all communications between workloads are encrypted, mutually authenticated, and authorized.
Traditionally, micro-segmentation that uses IP-based rules has been used to mitigate insider risks. However, the adoption of containers, shared services, and distributed production environments spread across multiple clouds makes this approach harder to configure and even harder to maintain.
With Anthos Service Mesh, you can configure a layer of service context-aware and request context-aware network security that is independent of the security of the underlying network. Because of this, Anthos Service Mesh lets you adopt a defense-in-depth posture that is consistent with Zero Trust security principles. It lets you achieve this posture through declarative policies and without modifying any application code.
mutual TLS
Anthos Service Mesh uses mutual TLS (mTLS) for peer authentication. mTLS makes it possible for workloads to verify each other's identities and authenticate with each other. You might be familiar with simple TLS through its use in HTTPS to allow browsers to trust web servers and to encrypt the data that is exchanged. When simple TLS is used, the client establishes that the server can be trusted by validating its certificate. mTLS is an implementation of TLS in which both client and server present certificates to each other and verify each other's identities.
mTLS is the means by which Anthos Service Mesh implements both authentication and encryption between services.
Security benefits
Anthos Service Mesh provides the following security benefits:
Mitigates risk of replay or impersonation attacks that use stolen credentials. Anthos Service Mesh relies on mTLS certificates to authenticate peers, rather than bearer tokens such as JWT tokens. Because mTLS certificates are bound to the TLS channel, it is not possible for an entity within your production environment to impersonate another by simply replaying the authentication token without access to the private keys.
Ensures encryption in transit. Using mTLS for authentication also ensures that all TCP communications are encrypted in transit.
Ensures that only authorized clients can access a service with sensitive data. Only authorized clients can access a service with sensitive data irrespective of the network location of the client and the application-level credentials. You can specify that only clients with authorized service identities or in authorized Kubernetes namespaces can access a service. You can also use IP-based access policies to grant access to clients deployed outside the GKE Enterprise environment.
Mitigates the risk of user data breach within your production network. You can ensure that insiders can only access sensitive data through authorized clients. Furthermore, you can ensure that certain clients can only gain access to 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 credential grants an attacker access to all user data.
Identifies which clients accessed a service with sensitive data. Anthos Service Mesh access logging captures the mTLS identity of the client in addition to the IP address. Thus, you can easily understand which workload accessed a service even if the workload is ephemeral and dynamically deployed, and in a different cluster or Virtual Private Cloud (VPC) network.
Features
Anthos Service Mesh provides the following features to realize its security benefits:
Automatic certificate and key rotation. Using mTLS based on service identities makes it possible to encrypt all TCP communications and provides a more secure non-replayable credential for access control. One of the key challenges of using mTLS at scale is managing the keys and certificates for all target workloads. Anthos Service Mesh manages the rotation of mTLS keys and certificates for GKE Enterprise workloads without disrupting communications. This lets you configure smaller invalidation intervals, thus further reducing risk.
Managed private certificate authority (Mesh CA). Anthos Service Mesh includes a Google-managed multi-regional private certificate authority, Mesh CA, for issuing certificates for mTLS. Mesh CA is a highly reliable and scalable service that is optimized for dynamically scaled workloads on a cloud platform. With Mesh CA, Google manages the security and availability of the CA backend. Mesh CA lets you rely on a single root of trust across GKE Enterprise clusters. When using Mesh CA, you can rely on workload identity pools to provide coarse-grained isolation. By default, authentication fails if the client and the server are not in the same workload identity pool.
Certificates from Mesh CA include the following data about your application's services:
- The Google Cloud project ID
- The GKE namespace
- The GKE service account name
Identity-aware access control (firewall) policies. With Anthos Service Mesh, you can configure network security policies that are based on the mTLS identity versus the IP address of the peer. This lets you create policies that are independent of the network location of the workload. Only communications across clusters in the same Google Cloud project are currently supported.
Request claims-aware access control (firewall) policies. In addition to the mTLS identity, you can grant access based on request claims in the JWT header of HTTP or gRPC requests. Anthos Service Mesh lets you assert that a JWT is signed by a trusted entity. This means that you can configure policies that allow access from certain clients only if a request claim exists or matches a specified value.
User authentication with Identity-Aware Proxy. You authenticate users that are accessing any service exposed on an Anthos Service Mesh ingress gateway by using Identity-Aware Proxy (IAP). IAP can authenticate users that 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 grant access at the Ingress gateway or a downstream service (by using a side-car).
Access logging and monitoring. Anthos Service Mesh ensures that access logs and metrics are available in Google Cloud Observability, and provides an integrated dashboard to understand access patterns for a service or workload based on this data. You can also choose to configure a private destination. Anthos Service Mesh lets you reduce noise in access logs by only logging successful accesses once in a configurable time window. Requests that are denied by a security policy or result in an error are always logged. This lets you significantly reduce the costs associated with ingesting, storing, and processing logs, without the loss of key security signals.
FIPS compliant. All in-cluster control plane components and proxies use FIPS 140-2 validated encryption modules.
Limitations
Anthos Service Mesh security currently has the following limitations:
Mesh CA is only supported on GKE.
User authentication that uses IAP requires that a service be published to the internet. IAP and Anthos Service Mesh let you configure policies that can restrict access to authorized users and clients in an allowed IP range. If you choose to only expose the service to clients within the same network, you need to configure a custom policy engine for user authentication and token issuance.