Traffic Director service security

Traffic Director lets you secure service-to-service communications in your mesh. In the mesh, each service has an identity. The following features help support secure communications:

  • Authentication and encryption that use transport layer security (TLS) and mutual TLS (mTLS) for both Traffic Director with Envoy and Traffic Director with proxyless gRPC applications. Client TLS policies and server TLS policies control whether services need to prove their identities to each other and use encrypted communication channels.
  • Authorization, based on characteristics of the client and the request. Authorization policies control whether a service is permitted to access another service and which actions are allowed. Authorization is available only for Traffic Director with Envoy.

Using certificates and keys provided by a private certificate authority (CA), Google's Certificate Authority Service, makes it easier for you to maintain service security. CA Service provides GKE workload certificates, which enable you to manually configure credential provisioning for mTLS communication between workloads. You modify your Pods to allow workloads to receive and use mTLS credentials. Traffic Director service security is currently available only for GKE-based workloads.

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

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

In this model, proxyless gRPC or Envoy sidecars securely authenticate and encrypt communications by obtaining configuration information from Traffic Director and certificates from a private CA managed by Certificate Authority Service.

These security features make your Traffic Director deployment process easier by 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 Traffic Director and CA Service.
  • Security tied to Google Identity and Access Management (IAM): service authorization based on authorized Google service accounts.
  • Seamless interoperability with your Envoy-based and proxyless workloads. For example, a service can be behind an Envoy proxy, but the client uses gRPC proxyless service mesh security. Conversely, a service can be behind gRPC proxyless service mesh security, but the client uses an Envoy proxy.

Service mesh overview

This review of the Compute Engine API resources required to configure Traffic Director helps to explain the semantics of the security resources. Here is a simple case: a mesh consisting of two services whose sidecar proxies are configured by Traffic Director. A mesh with proxyless gRPC applications is similarly configured.

Basic Traffic Director service mesh.
Basic Traffic Director service mesh (click to enlarge)

You deploy the preceding pattern by configuring the following Compute Engine API resources.

Compute Engine resources required for a mesh.
Compute Engine resources required for a mesh (click to enlarge)

This model has the following characteristics:

  • Each service has its own global forwarding rule with a virtual IP address (VIP). This VIP enables other clients in the mesh to call this service. When a client in the mesh calls this service, your data plane sends traffic to an appropriate endpoint or virtual machine (VM) instance for the service. The global forwarding rule must have the load-balancing scheme INTERNAL_SELF_MANAGED.

  • These global forwarding rules reference the same target HTTPS proxy.

  • The target HTTPS proxy references a URL map, which contains host rules that resolve traffic to a global backend service.

  • The global backend services each reference a global network endpoint group (NEG), which contains network endpoints. Each global backend service must have the load-balancing scheme INTERNAL_SELF_MANAGED.

  • The network endpoints point to specific GKE Pods, which run your application code.

Securing service-to-service communications

Traffic Director provides authorization as well as service-to-service security with encryption and authentication that use TLS. Client TLS policies and server TLS policies let services to do the following:

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

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

Authorization policies, which are available only with Envoy, enable you to restrict or allow access according to rules that you define.

Using TLS for encryption

When a service calls on another service by using the HTTP protocol, traffic that transits the network is in plain text. This traffic might be subject to person-in-the-middle attacks, in which an attacker intercepts the traffic and inspects or manipulates its contents.

To mitigate this potential issue, you can use HTTP over TLS with Traffic Director. When you use HTTP over TLS, traffic between the client and the server is encrypted by using TLS that is based on the server's certificate. Traffic is no longer in plain text, reducing the likelihood that an attacker can intercept and inspect or manipulate its contents.

Using TLS for authentication

When a service calls on another service by using the HTTP protocol, consider the following questions:

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

  • What happens if an attacker intercepts that traffic? HTTP traffic is 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 over TLS. In an HTTP-over-TLS exchange between a client and a server, the server must use a server certificate to prove its identity to the client. Requests and responses are then encrypted by using TLS.

For gRPC applications, HTTP/2 and gRPC communications can also be encrypted and authenticated by using TLS.

Mutual TLS authentication

When Traffic Director configures application networking for both the client and server—for example, by configuring an Envoy proxy on the client side and another Envoy proxy on the server side—you can take advantage of advanced authentication patterns such as mutual authentication.

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

When mutual authentication is enabled, the client also has a certificate. The client 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 server certificates are used to encrypt the communication channel. This also enables the server to authorize clients based on verified client identity.

Mutual TLS (mTLS) authentication in a service mesh.
Mutual TLS (mTLS) authentication in a service mesh (click to enlarge)

Authorizing service calls

If you are using Traffic Director with Envoy proxies, you can choose to allow or deny service access by using authorization policies. Using Traffic Director, you can define allow and deny rules to authorize access based on request parameters. You can base these rules on Layer 3 and Layer 7 parameters, including source IP address, host match, method match, and header match. Authorization policies are not available for proxyless gRPC applications.

Authorization in a service mesh.
Authorization in a service mesh (click to enlarge)

Restricting access using authorization

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

With Traffic Director, you can configure authorization policies that enable your 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 is sent, the Traffic Director client on the called service determines whether the request matches a rule. If a match is found, the request is allowed or denied. You can define a rule to match on attributes such as the following:

  • 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, and user-defined HTTP headers

Secure naming

As an extra security mechanism, you can configure secure naming with Traffic Director. This enables you to define a list of allowed names, or SPIFFE (Secure Production Identity Framework for Everyone) identities, for a particular service that a client is attempting to connect to. During the TLS exchange, the service's backend returns an X.509 certificate to the client. The client then inspects the certificate to confirm that the X.509 certificate matches one of the names or SPIFFE identities. For more information about SPIFFE identities, see Secure Production Identity Framework for Everyone.

Securing traffic at a gateway

To configure your gateways, you can use Traffic Director. A gateway is a standalone Envoy proxy that typically acts as one of the following:

  • An ingress gateway that handles traffic that is entering a mesh or some other domain
  • An egress gateway that handles traffic that is exiting a mesh or some other domain
  • A reverse proxy or middle proxy that distributes inbound traffic among one or more services

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

Security components

Traffic Director service security supports client TLS policies, server TLS policies, and authorization policies. You create these policies so that Traffic Director can configure your data plane and enable security capabilities. To create or update these policies, you don't need to make changes to your applications.

Encryption and supported authentication modes

When a service calls on another service, the first step in establishing secure communications 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 TLS mode 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 the client initiates the connection

Certificates and certificate authorities

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

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

Traffic Director is not a certificate authority. To enable secure communications, you must set up a mechanism that does the following:

  • Provisions identities and certificates
  • Makes the certificates available to Traffic Director clients, such as Envoy proxies, that Traffic Director configures

Traffic Director supports Google's CA Service. The setup guides for Envoy and proxyless gRPC include instructions for setting this up (for details, see What's next).

Architecture and resources

Traffic Director includes the Network Security API namespace, which consists of three Google Cloud API resources that let you specify the security 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 authorization policy, supports authorization.

The Network Services API namespace includes the endpoint policy resource, which enables Traffic Director to supply configuration (server TLS, client TLS, and authorization policies) to endpoints. Endpoints are the Traffic Director clients that terminate an inbound communication from another Traffic Director client.

To enable the security service, use the target HTTPS proxy or target gRPC proxy in your deployment. You cannot use the target HTTP proxy or target TCP proxy.

Client TLS policy

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

When you configure TLS, you must provide a mechanism by which the client validates the certificate that it receives from the server during the TLS exchange by using the serverValidationCa API field. The client uses this information to obtain a validation certificate that it can use to validate the server certificate.

When you configure mTLS, you must also provide a mechanism by which the client obtains its certificate and private key by using the clientCertificate API field. The client uses this information to present a certificate to the server during the TLS handshake.

In this release, Traffic Director supports a managed certificate authority, CA Service. Configuration is straightforward: you specify the google_cloud_private_spiffe plugin name when you configure the certificate provider. This causes your xDS clients to load certificates and keys from a static location. As prerequisites, you must configure CA Service and enable workload certificates on your GKE cluster.

Server TLS policy

A server TLS policy (ServerTlsPolicy resource) lets you specify the server-side TLS mode and the certificate provider information to be applied to your data plane. Server TLS policies support TLS, mTLS, and, with Envoy only, Open_or_mTLS authentication. Server TLS policies can be attached to the target HTTPS proxy resource or an endpoint policy resource.

Subject alternative names

When you configure a global backend service's securitySettings field, you can supply a list of subject alternative names in the subjectAltNames field. When a client initiates a TLS handshake with one of the service's backends, the server presents its X.509 certificate. The client inspects the certificate's subjectAltName field. If the field contains one of the specified values, the communication continues. This mechanism is described earlier in Secure naming.

Authorization policy

An authorization policy (AuthorizationPolicy resource) specifies how a server authorizes incoming connections. It can be configured to allow or deny an incoming request based on various parameters, such as the identity of the client that sent the request, host, headers, and other HTTP attributes. An authorization policy can be attached to the target HTTPS proxy resource or an endpoint policy resource.

Authorization policies are available only with Envoy.

Limitations with proxyless gRPC applications

Service security for proxyless gRPC services has the following limitations:

  • Authorization policies are not supported with proxyless gRPC.
  • This release is limited to Java, Python, Go, and C++.

What's next