Service security use cases

This document describes common Cloud Service Mesh security use cases. Use thisinformation to help you determine which security model best suits your needs.This document also provides a high-level overview of what you need to configurefor each use case.

For an overview of service security, seeCloud Service Mesh service security.

Enabling mutual TLS for services in the mesh

In a service mesh, you can enable mutual TLS (mTLS) so that both the client andthe server in a communication must prove their identities and encryptcommunications.

The following section omits discussion of theMesh,Gateway andRouteresources. These API resources are required to create your mesh and routetraffic, but you don't need to update them to enable mTLS.

The preceding pattern can be achieved by configuring the followingCompute Engine API resources. This diagram uses sidecar proxies, butconfiguring a proxyless gRPC application with mTLS uses the same resources.

To create this model, do the following:

1. Create a client transport layer security (TLS) policy.
2. Create a server TLS policy.
3. Update thesecuritySettings field in your existing global backend servicesto reference the new client TLS policy.

4. Create an endpoint policy:

   1. Reference the server TLS policy in theserver_tls_policy field.

   2. Define anEndpointMatcher to select the Cloud Service Mesh clients thatshould enforce authentication on inbound traffic.

      Selecting Cloud Service Mesh clients is based on labels specified inthe Cloud Service Mesh client's bootstrap configuration. These labelscan be supplied manually or populated automatically based on labelssupplied to your Google Kubernetes Engine (GKE) deployments.

      In the preceding diagram, the labels"mesh-service":"true" areconfigured on the endpoint policy and the Cloud Service Mesh clients.You can choose labels that suit your deployment.

   3. Optionally, define aTrafficPortSelector that applies the policies onlywhen inbound requests are made to the specified port on the data planeentity.

The following diagram shows the Compute Engine resources that youconfigure for mTLS, regardless of whether you use Envoy or a proxyless gRPCapplication.

The following diagram shows traffic flow and lists the Compute Engine APIresources that you configure to enable mTLS. The local sidecar proxy that sitsalongside Service B's GKE Pod is the endpoint in thecommunication.

The endpoint policy does the following:

1. Selects a set of endpoints by using an endpoint matcher and, optionally,ports on those endpoints.

   1. The endpoint matcher lets you specify rules that determinewhether a Cloud Service Mesh client receives the configuration.These rules are based on the xDS metadata that the dataplane entity provides to the control plane—in this case,Cloud Service Mesh.

      You can add labels to the Cloud Service Mesh client as follows:

      • You can manually specify this metadata in yourCloud Service Mesh client's bootstrap file.

      • Alternatively, the metadata can be automatically populated whenyou use GKE by adding the key-value pairs to theenv section of thedemo_server.yaml ordemo_client.yamlfiles. These values are provided in theEnvoy setup guideandproxyless gRPC setup guide.

        For example, with Envoy only, you can prefix the key with theISTIO_META_ prefix. Proxy environment variable names thatstart withISTIO_META_ are included in the generated bootstrapand sent to the xDS server.

        - name: ISTIO_META_app  value: 'review'- name: ISTIO_META_version  value: 'canary'

   2. If you specify a port, the policies referenced in the endpoint policyare only enforced on inbound requests that specify the same port. Ifyou don't specify a port, the policies are enforced on inbound requeststhat specify a port that is also in theTRAFFICDIRECTOR_INBOUND_BACKEND_PORTS field, which is providedto the Cloud Service Mesh client in its bootstrap information.

2. References client TLS, server TLS, and authorization policies that configurethe endpoints to which requests resolve.

Configuring incompatible TLS modes might result in a disruption ofcommunications. For example, settingOPEN on the global backend service orleaving the client TLS policy field empty, and settingMTLS as the value ofthe server TLS policy on the endpoint policy, results in failed communicationattempts. This is because endpoints that are configured to only accept mTLSreject attempts to establish unauthenticated communication channels.

Note the distinction between a client TLS policy and a server TLS policyattached to a global backend service and endpoint policy, respectively:

• The client TLS policy is applied to the global backend service. It tellsthe Envoy proxy or proxyless client which TLS mode, identity, and peervalidation approach to use when addressing the service.
• The server TLS policy is attached to the endpoint policy. It tells theserver which TLS mode, identity, and peer validation approach to use forincoming connections.

Enabling TLS for an ingress gateway

After you set up mTLS for in-mesh communications, you might want tosecure traffic that is entering your mesh, known asingress traffic.Cloud Service Mesh can configure your data plane to require ingress traffic touse TLS-encrypted communications channels.

To achieve this goal, choose one of the following architecture options:

• Services in the mesh terminate TLS for traffic from a load balancer. Inthis model, each service in the mesh is configured as a backend in the loadbalancer's configuration—specifically, in the load balancer's URL map.
• An ingress gateway terminates TLS for traffic from a load balancerbefore forwarding traffic to services in the mesh. In this model, adedicated service in the mesh, theingress gateway, is configured as abackend in the load balancer's configuration—specifically, in the loadbalancer's URL map.

Both options are explained in this section.

Services in the mesh terminate TLS for traffic from a load balancer

If you want to make your services available to clients outside ofGoogle Cloud, you might use anexternal Application Load Balancer.Clients send traffic to the load balancer's global Anycast virtual IP address(VIP), which then forwards that traffic to services in your mesh. This meansthat there are two connections when an external client needs to reach a servicein the mesh.

The same pattern applies when you use aninternal Application Load Balancer.Traffic from internal clients first reaches the load balancer, which thenestablishes a connection to the backend.

To secure both connections, do the following:

1. Secure the connection between the client and the load balancer by usingan external Application Load Balancer.
2. Configure the load balancer to use the HTTPS or HTTP/2 protocols whenit attempts toestablish a connection with services in the mesh.
3. Configure Cloud Service Mesh so that your Cloud Service Mesh clients terminateHTTPS and present certificates to the client, which, in this case, is theload balancer.

For more information about steps 1 and 2, seeSetting up a multi-region, content-based external HTTPS load balancer.

When you set up Cloud Service Mesh security, you configure variousCompute Engine API resources. These resources are separate from theresources that you configure for the load balancer. You create a set ofCompute Engine API resources (global forwarding rule, target proxy, URL map,and global backend services) for the load balancer and configureCloud Service Mesh with the service routing APIs. In addition, in the backendservice resource, the load balancer has the load balancing schemeINTERNAL_MANAGED and Cloud Service Mesh has the load balancing schemeINTERNAL_SELF_MANAGED.

In step 3, you configure Cloud Service Mesh so that your Cloud Service Meshclients terminate HTTPS and present certificates to clients.

In this model, you do the following:

1. Create aserverTlsPolicy: configureserverCertificate ontheserverTlsPolicy resource.
2. Create an endpoint policy:
   1. Reference the server TLS policy in theauthentication field.
   2. Define anEndpointMatcher to select the xDS data planeentities that should enforce authentication on inbound traffic.
   3. Optionally, define aTrafficPortSelector that applies thepolicies only when inbound requests are made to the specified port onthe Cloud Service Mesh client.

Because the external Application Load Balancer is already configured to initiateTLS connections to services in your mesh, Cloud Service Mesh only needs toconfigure your Cloud Service Mesh clients to terminate TLS connections.

Ingress gateway terminates TLS for traffic from a load balancer before forwarding traffic to services in the mesh

If you only want to expose an ingress gateway to your load balancer, you can usethe ingress gateway deployment pattern. In this pattern, the load balancerdoes not directly address services in your mesh. Instead, a middle proxy sitsat the edge of your mesh and routes traffic to services inside the mesh, basedon the configuration that it receives from Cloud Service Mesh. The middle proxycan be an Envoy proxy that you deployed on virtual machine (VM) instances in aCompute Engine managed instance group.

From a security perspective, you configure the ingress gateway to terminate TLS,and then optionally configure connections within your mesh so that they areprotected by mTLS. These include connections between the ingress gateway andyour in-mesh services, and connections among your in-mesh services.

From a configuration perspective, you do the following:

1. Configure your service mesh and enable mTLS for communications withinthe mesh(as explained earlier).
2. Configure your load balancer to route traffic to the ingress gateway andinitiate connections by using the HTTPS protocol(as explained earlier).
3. Create a set of Compute Engine API resources that represent the ingressgateway and its server TLS policy.

For the third step, configure Cloud Service Mesh to terminate HTTPS andpresent certificates as follows:

1. Create aMesh resource to represent the mesh.

2. Create aRoute resource that points to the correct global backendservices and attach theRoute resource to theMesh resource.

3. Create a server TLS policy: configureserverCertificate.

4. Create aGateway resource to represent the Cloud Service Mesh managedingress gateway.

5. Attach the server TLS policy resource to theGateway resource.

The ingress gateway pattern is especially useful in large organizations that useShared VPC. In such a setting, a team might onlyallow access to its services through an ingress gateway. In the precedingdiagram, when you configure the global forwarding rule for the load balancer,you supply a different IP address (in this example,10.0.0.2) than the onesupplied when you configure the mesh (in this example, the mesh address is10.0.0.1). Clients that communicate through a Cloud Service Mesh-configured xDSdata plane entity can use this address to access the ingress gateway.

As an example, assume the following:

• Two service projects (1 and 2), both attached to the same Shared VPCnetwork.

• Service project 1 contains a service mesh configured by Cloud Service Mesh.

  Service project 1 has configured a mesh and an ingress gateway.This ingress gateway is reachable on the10.0.0.2 address/VIP.

• Service project 2 contains a service mesh configured by Cloud Service Mesh.

  Service project 2 might or might not have its own ingress gateway.

• Cloud Service Mesh configures the Cloud Service Mesh clients in each serviceproject. The clients are bootstrapped to use the same network.

Given this configuration, clients in service project 2's mesh can communicatewith the ingress gateway in service project 1 by using the10.0.0.2 VIP. Thisenables the owners of service project 1 to configure routing, security, and otherpolicies that are specific to traffic entering the mesh. In effect, the ownersof service project 1 can tell others thatclients in your mesh can reach myservices on10.0.0.2.

Limitations

Cloud Service Mesh service security is supported only withGKE. You cannot deploy service security with Compute Engine.

What's next

• To configure Cloud Service Mesh service security with Envoy proxies, seeSetting up Cloud Service Mesh service security with Envoy.
• To configure Cloud Service Mesh service security with proxyless gRPC applications,seeSetting up Cloud Service Mesh service security with proxyless gRPC.