Service security

This document provides an overview of service security with Cloud Service Mesh. It isintended for Cloud Service Mesh users who want to add authentication, encryption,and authorization to their deployments. This document assumes that you arefamiliar withCloud Service Mesh overviewandwith proxyless gRPC applications.

Cloud Service Mesh lets you secure service-to-service communications in yourmesh. In the mesh, each service has an identity. The following features helpsupport secure communications:

• Authentication and encryption that use transport layer security (TLS) andmutual TLS (mTLS) for both Cloud Service Mesh with Envoy and Cloud Service Meshwith proxyless gRPC applications. Client TLS policies and server TLS policiescontrol whether services need to prove their identities to each other and useencrypted communication channels.
• Authorization, based on characteristics of the client and the request.Authorization policies control whether a service is permitted to accessanother service and which actions are allowed.

Using certificates and keys provided by a private certificate authority (CA),Google's Certificate Authority Service, makes iteasier for you to maintain service security. CA Service providesGKE mesh certificates. The GKE mesh certificatesfeature and Cloud Service Mesh enable you to automatically deploy thesecertificates and have workloads use them. You modify your Pods to allowworkloads to receive and use mTLS credentials. Cloud Service Mesh servicesecurity is currently available only for GKE-based workloads.

In modern microservice-based architectures, smaller, more focused servicesreplace large monolithic applications. Service calls communicate with each otherover the network. These calls, which were in-process calls in monolithicapplications, present security challenges, so it's best to authenticate,encrypt, and authorize them. These steps support thezero trust principle, inwhich all network traffic is assumed to be at risk, regardless of whether thetraffic originates inside or outside the network.

The service mesh design pattern separates any complexity related toservice-to-service communications from the business logic. Instead, the dataplane handles this complexity. In addition to reducing application complexity,the service mesh design pattern enables security patterns that might otherwisebe difficult to implement and manage.

In this model, proxyless gRPC or Envoy sidecars securely authenticate and encryptcommunications by obtaining configuration information from Cloud Service Mesh andcertificates from aCA Service pool.

These security features make your Cloud Service Mesh deployment process easierby providing the following:

• Automatic provisioning of keys and certificates to all services in your mesh.
• Automatic rotation of keys and certificates to provide additional security.
• Integration with Google Kubernetes Engine (GKE) to use all of its capabilities,such as deployment descriptors and labels.
• High availability of Google managed services, including Cloud Service Mesh andCA Service managed private certificate authority pools.
• Security tied to Google Identity and Access Management (IAM): service authorizationbased on authorized Google service accounts.
• Seamless interoperability with your Envoy-based and proxyless workloads. Forexample, a service can be behind an Envoy proxy, but the client uses gRPCproxyless service mesh security. Conversely, a service can be behind gRPCproxyless service mesh security, but the client uses an Envoy proxy.

Secure service-to-service communications

Cloud Service Mesh provides authorization as well as service-to-service securitywith encryption and authentication that use TLS. Client TLS policiesand server TLS policies let services do the following:

• Assert and validate their identities.
• Encrypt communication sessions by using TLS or mTLS.

In a service mesh, the data plane handles this type of security so thatapplications don't need to make special provisions to be secure.

Authorization policies enable you to deny or allow access according to rulesthat you define.

Use TLS for encryption

When a service calls on another service by using the HTTP, HTTP/2, or gRPCprotocol, traffic that transits the network is in plain text. This traffic might besubject toperson-in-the-middle attacks,in which an attacker intercepts the traffic and inspects or manipulates itscontents.

To mitigate this potential issue, you can use HTTP, HTTP/2, or gRPC over TLSwith Cloud Service Mesh. When you use these protocols over TLS, traffic betweenthe client and the server is encrypted by using TLS that is based on theserver's certificate. Traffic is no longer in plain text, reducing thelikelihood that an attacker can intercept and inspect or manipulate itscontents.

Use TLS for authentication

When a service calls on another service, consider the following questions:

• How does a client know that it is receiving a response from the correctserver rather than an imposter? For example, in a typical request-responseinteraction based on HTTP, the client does not verify the server's identity.

• What happens if an attacker intercepts that traffic? For example, HTTP trafficis not encrypted, so anyone who receives the traffic can inspect its contents.This is known as a person-in-the-middle attack.

To mitigate these issues, you can use HTTP, HTTP/2, and gRPC over TLS. In theseexchanges between a client and a server, the server must use a servercertificate to prove its identity to the client. Requests and responses are thenencrypted using TLS.

Mutual TLS authentication

When Cloud Service Mesh configures application networking for both the client andserver—for example, by configuring an Envoy proxy on the client side andanother Envoy proxy on the server side—you can take advantage of advancedauthentication patterns such as mutual authentication.

In a typical HTTP over TLS exchange, which is not based on mutualauthentication, the server has a certificate that it uses to encryptcommunications between the client and the server. The client can verify theserver's identity by checking the signature that the server sends back duringthe TLS handshake. However, the server does not verify the client's identity.

When mutual authentication is enabled, the client also has a certificate. Theclient verifies the server's identity, as described in the previous paragraph,and the server can also verify the client's identity. Both the client and servercertificates are used to encrypt the communication channel. This also enablesthe server to authorize clients based on verified client identity.

Authorize service calls

You can choose to allow or deny service access by using authorization policies.Using Cloud Service Mesh, you can define allow and deny rules to authorize accessbased on request parameters. You can base these rules on Layer 3 and Layer 7parameters, including client ID, which is derived from theclient-cert in anmTLS connection, source IP address, host match, method match, and headermatch. The following diagram shows authorization with Envoy proxies. The processis similar with gRPC clients.

Restrict access using authorization

A best practice within a service mesh is to adhere to the principle of leastprivilege. You can adhere to this principle by restricting service access toonly those callers that depend on the service. When a caller attempts to accessa service for which it is not authorized, the attempt is rejected.

With Cloud Service Mesh, you can configure authorization policies that enableyour data plane to allow or deny service access based on rules that you define.These policies consist of two components:

• An action: allow or deny
• A list of rules

When a request or RPC is sent, the Cloud Service Mesh client on the calledservice determines whether there is a rule match. If a match is found, therequest or RPC is allowed or denied. You can define a rule to match onattributes such as the following:

• When mTLS is used, the calling service's Kubernetes service account
• The calling service's IP address (or range of addresses)
• The destination service's ports
• The request's HTTP attributes, including hostnames, methods, anduser-defined HTTP headers.

As an extra security mechanism, you can configuresecure naming withCloud Service Mesh. This lets you define a list of allowed names, or SPIFFE(Secure Production Identity Framework for Everyone) identities, for a particularservice that a client is attempting to connect to. During the TLS exchange, theservice's backend returns an X.509 certificate to the client. The client theninspects the certificate to confirm that the X.509 certificate matches one ofthe names or SPIFFE identities. For more information about SPIFFE identities, seeSecure Production Identity Framework for Everyone.

Secure traffic at a gateway

To configure yourgateways, you can use Cloud Service Mesh. A gateway is astandalone Envoy proxy that typically acts as one of the following:

• Aningress gateway that handles traffic that is entering a meshor some other domain
• Anegress gateway that handles traffic that is exiting a mesh or some otherdomain
• A reverse proxy or middle proxy that distributes inbound traffic among one ormore services

Clients that want to send traffic into the mesh or out of the mesh send trafficto the gateway. The gateway then handles requests according to the rules thatyou have set up with Cloud Service Mesh. For example, you can enforce that trafficentering your mesh (though the ingress gateway) must be encrypted by using TLS.

Security components

Cloud Service Mesh service security supports client TLS policies, server TLSpolicies, and authorization policies. You create these policies so thatCloud Service Mesh can configure your data plane and enable securitycapabilities. To create or update these policies, you don't need to makechanges to your applications.

Encryption and supported authentication modes

When a service calls on another service, the first step in establishing securecommunications is to have each service prove its identity to the other service.The degree to which a service needs to prove its identity is based on the TLSmode that you configure.

You can configure the following levels of security:

• Unencrypted/unauthenticated
• TLS
• Mutual TLS (mTLS)
• Permissive: mTLS or unencrypted/unauthenticated, depending on how theclient initiates the connection

Certificates and certificate authorities

Certificates and a trusted certificate authority (CA) provide the foundationfor trust in a distributed system such as a service mesh. Using certificates,services can prove their identities and verify the identities presented tothem in the following ways:

• A service that wants to prove its identity to another service presentsits certificate to the other service. A CA that both services trustcryptographically signs and issues this certificate.
• The service that receives this certificate can verify that thecertificate originated from a CA that it trusts.

Cloud Service Mesh is not a certificate authority. To enable securecommunications, you must set up a mechanism that does the following:

• Provisions identities and certificates
• Makes the certificates available to Cloud Service Mesh clients, such as Envoyproxies, that Cloud Service Mesh configures

Cloud Service Mesh supports Google's CA Service. The setup guidesfor Envoy and proxyless gRPC include instructions for setting this up (fordetails, seeWhat's next).

Architecture and resources

Cloud Service Mesh includes the Network Security API namespace, which consists ofthree Google Cloud API resources that let you specify thesecurity policies that should be applied to your data plane.

Two Google Cloud API resources support authentication in the mesh:client TLS policies and server TLS policies. A third resource, the authorizationpolicy, supports authorization.

The Network Services API namespace includes the endpoint policy resource, whichenables Cloud Service Mesh to supply configuration (server TLS, client TLS, andauthorization policies) toendpoints. Endpoints are the Cloud Service Meshclients that terminate an inbound communication from another Cloud Service Meshclient.

Client TLS policy

A client TLS policy lets you specify the client-side TLS mode and thecertificate provider information to be applied to your data plane. Client TLSpolicies support TLS and mTLS authentication. Client TLS policies must beattached to a global backend service resource.

When you configure TLS, you must provide a mechanism by which the clientvalidates the certificate that it receives from the server during the TLSexchange by using theserverValidationCa API field. The client uses thisinformation to obtain a validation certificate that it can use to validate theserver certificate.

When you configure mTLS, you must also provide a mechanism by which the clientobtains its certificate and private key by using theclientCertificate APIfield. The client uses this information to present a certificate to the serverduring the TLS handshake.

In this release, Cloud Service Mesh supports a managed certificate authority,CA Service. Configurationis straightforward: you specify thegoogle_cloud_private_spiffe plugin namewhen you configure the certificate provider. This causes your xDS clients toload certificates and keys from a static location. As prerequisites, you mustconfigure CA Service pools and enable mesh certificates on yourGKE cluster.

Server TLS policy

A server TLS policy (ServerTlsPolicy resource) lets you specify theserver-side TLS mode and the certificate provider information to be applied toyour data plane. Server TLS policies support TLS, mTLS, and, with Envoy only,Open_or_mTLS authentication. You attach server TLS policies to an endpointpolicy resource.

Subject alternative names

When you configure a global backend service'ssecuritySettings field, you cansupply a list of subject alternative names in thesubjectAltNames field. Whena client initiates a TLS handshake with one of the service's backends, theserver presents its X.509 certificate. The client inspects the certificate'ssubjectAltName field. If the field contains one of the specified values,the communication continues. This mechanism is described earlier inSecure naming.

Authorization policy

An authorization policy (AuthorizationPolicy resource) specifies how a serverauthorizes incoming requests or RPCs. It can be configured to allow or deny anincoming request or RPC based on various parameters, such as the identity of the clientthat sent the request, host, headers, and other HTTP attributes. You attachauthorization policies to an endpoint policy resource.

An authorization policy rule has the following components:

• from: specifies the identity of the client that is allowed by the rule.The identity can be derived from a client certificate in a mutual TLSconnection, or it can be the ambient identity associated with the clientVM, such as from a service account or a secure tag.
• to: specifies the operations allowed by the rule, such as the URLs thatcan be accessed or the HTTP methods allowed.
• when: lets you define additional constraints that must be met. You can useCommon Expression Language(CEL) expressionsto define the constraints.
• action: specifies the action of the rule. It can be one ofALLOW,DENY, orCUSTOM.

• ALLOW: grants access to the requested resource if the request matches thedefined rules within the authorization policy. The authorization policyblocks access to the requested resource if the request doesn't match anydefined rules within the authorization policy. A request is denied if itdoesn't match anALLOW policy, even if other policies allow it.

• DENY: blocks access to the resource if a request matches any of the rulesspecified within aDENY policy. The authorization policy grants access tothe requested resource if the request doesn't match any defined rules withinthe authorization policy. A request is denied if it matches aDENY policy,even if other policies allow it.

• CUSTOM (Unsupported on Cloud Service Mesh): enables integration withexternal authorization systems for complex authorization decisions.CUSTOMactions are used for policies that use service extensionsfor authorization decisions.

  Note: You can define only one authorization policy with theCUSTOM actionfor a given forwarding rule or gateway.

Authorization policy evaluation order

When multiple authorization policies are associated with a single resource, theyare evaluated in the following order to determine whether a request is allowedor denied.

1. Policies withCUSTOM actions: if theCUSTOM policy denies therequest, the request is rejected immediately.DENY orALLOW policiesaren't evaluated, even if any are configured.

2. Policies withDENY actions: if anyDENY policies match the request,the request is denied. AnyALLOW policies aren't evaluated, even if anyare configured.

3. Policies withALLOW actions: if there are noALLOW policies or ifanyALLOW policy matches the request, the request is allowed. However, ifnoALLOW policies match the request, the request is denied.

Limitations with proxyless gRPC applications

Service security for proxyless gRPC services has the following limitations:

• This release is limited to Java, Python, C++, and Go.

AuthzPolicy Quotas

• You are limited to a total of 5 authorization policies per Gateway.
• You are limited to 20 AuthzPolicy resources per project.
• A single AuthzPolicy can point to up to 100 Gateways.

What's next

• To learn more about configuration options, seeCloud Service Mesh service security use cases.
• To learn more about authorization policies, seeAuthorization policy overview.
• To configure service security with Envoy proxies, seeSetting up Cloud Service Mesh service security with Envoy.
• To configure service security with proxyless gRPC applications, seeSetting up Cloud Service Mesh service security with proxyless gRPC applications.