Backend Access Control with Envoy Proxy and Google Cloud Service Accounts

In this blog post, we’ll explore how to configure Envoy Proxy to add an authorization header to all incoming requests and efficiently route traffic to your backend services. This setup enhances security and streamlines your application’s architecture.

Understanding Envoy Proxy

Envoy is a high-performance, open-source edge and service proxy designed for cloud-native applications. It provides a powerful way to manage traffic routing, observability, and security within your microservices environment.

Why Add an Authorization Header?

Authorization headers are frequently used to manage authentication and authorization processes within applications. These headers typically include a token or other credential that backend services can use to confirm the identity and permissions of the client making the request.

Use Case — Restricting Backend Access to Envoy Proxy Service Account

This blog will try to address the issue of adding GCP service account OAUTH2.0 header token in coming requests instead of setting up the envoy proxy or how to call backend services.

In the microservice or multiple services architecture where services need to communicate with each other to achieve the functionality. Authentication between service to service calls is required and few services are private and need an authentication header for access. If there is no authentication token retrieved from the incoming request then the service call is rejected.

In this scenario, the organization maintains a policy prohibiting unauthenticated connections to the Cloud Run service (backend service). Additionally, organizational policies restrict the implementation of Envoy Proxy using hardened images. To address these constraints, a decision has been made to deploy a hardened Envoy Proxy image on a Managed Instance Group (MIG). The ALB will be configured to direct valid incoming requests to the Envoy Proxy MIG. The Envoy Proxy will then evaluate the request and add an OAuth 2.0 token to the header for the associated service account. The Envoy Proxy service account is granted the Invoker role for the Cloud Run service.

Fig: Basic Setup for the Ingress connection from On premises machine to Cloud Run

GCP Authentication Filter

This filter fetches the authentication tokens from Google Compute Engine Metadata Server. More details can be found on the GCP Authentication Filter on this page.

If no authorization token header is present in requests then this filter can be configured to add authorization token header into incoming requests.

Configuration Steps

Let’s dive into the configuration steps to achieve this functionality with Envoy:

1. Install and Deploy Envoy

First, ensure you have Envoy Proxy installed and deployed in your environment. You can refer to the official Envoy documentation for installation instructions.

2. Define the Envoy Configuration

Create an Envoy configuration file (typically in YAML format) to specify the desired behavior. Here’s a basic example:

static_resources:
  listeners:
  - name: http_listener
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 80
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          codec_type: auto
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: backend_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: demoservice_cluster
        http_filters:
          - name: "envoy.filters.http.gcp_authn"
            typed_config:
"@type":type.googleapis.com/envoy.extensions.filters.http.gcp_authn.v3.GcpAuthnFilterConfig
              http_uri:
                uri: "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=[AUDIENCE]"
               cluster: "gcp_authn"
               timeout: 10s
   - name: envoy.filters.http.router
typed_config: "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

  clusters:
  - name: demoservice_cluster
    connect_timeout: 0.25s
    type: logical_dns
    lb_policy: round_robin
    load_assignment:
      cluster_name: demoservice_cluster
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: your_backend_service
                port_value: 8080
    typed_extension_protocol_options:
     envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
       "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
       explicit_http_config:
         http2_protocol_options:
           {}
    metadata:
     typed_filter_metadata:
       envoy.filters.http.gcp_authn:
         "@type": type.googleapis.com/envoy.extensions.filters.http.gcp_authn.v3.Audience
         url: http://demo-service.run2.app
# Cluster for GCE metadata server
 - name: gcp_authn
   type: STRICT_DNS
   connect_timeout: 5s
   dns_lookup_family: V4_ONLY
   load_assignment:
     cluster_name: "gcp_authn"
     endpoints:
     - lb_endpoints:
       - endpoint:
           address:
             socket_address:
               address: "metadata.google.internal"
               port_value: 80

In this configuration:

• Listeners: Define how Envoy listens for incoming traffic (e.g., on port 80).
• Filter Chains: Specify the filters to apply to the traffic.
• HTTP Connection Manager: Manages HTTP traffic and routing.
• Route Configuration: Defines how to route requests to different clusters (backend services).
• Header to Metadata Filter: Adds the authorization header to requests.
• Clusters: Define the backend services (e.g., `your_backend_service` on port 8080).

The Envoy proxy, with its flexible YAML configuration, uses HTTP filters for functions like authentication. The GCP authentication filter, “envoy.filters.http.gcp_authn”, simplifies authentication for GCP applications. It interacts with the GCP metadata server to retrieve service account credentials, get authorization tokens, and attach them to requests. This streamlines authentication, enhances security, and integrates easily into Envoy. It’s useful in microservices, API gateways, and service-to-service communication.

3. Start Envoy

Once you’ve created the configuration file, start the Envoy Proxy:

envoy -c /path/to/your/config.yaml

Key Benefits of GCP Authentication Filter in Envoy Proxy

• Simplified Token Fetching: The GCP Authentication Filter automates the process of fetching authentication tokens from Google Compute Engine Metadata Server. This simplifies the configuration and management of authentication in Envoy Proxy.
• Improved Security: By adding an authorization header to incoming requests, the GCP Authentication Filter enhances the security of your application by ensuring that only authorized clients can access your backend services.
• Enhanced Control: The filter provides granular control over the token fetching process, allowing you to specify the target audience and the timeout for token retrieval.
• Reduced Development Effort: The GCP Authentication Filter eliminates the need for custom code or complex configurations for token management, making it easier for developers to implement authentication in their applications.
• Seamless Integration: The filter seamlessly integrates with Envoy Proxy, making it easy to add authentication to your existing Envoy-based deployments.

Conclusion

Envoy Proxy provides a powerful and flexible way to add authorization headers to incoming requests and route traffic to your backend services. By implementing this configuration, you can enhance the security and manageability of your application’s architecture.

Feel free to experiment with different authorization mechanisms and routing strategies to suit your specific requirements.

Let me know if you have any questions or specific scenarios you’d like to explore!