Implementing Proxy Access Management with Envoy

Envoy HTTP Proxy Access Management

Envoy is a layer 7 proxy designed for modern large-scale microservices architectures. In most architectures, Envoy is designed to run “alongside” or next to the services it is proxying. In addition, it is sometimes advantageous to unite or orchestrate requests for services written in different programming languages. The use of Envoy in this manner can help you form a “service mesh” while leveraging your existing services without service rewrites.

The solution outlined in this post will show how SGNL can help reduce security exposure in your cloud-native workloads through centralizing access management, including microservice architectures. SGNL’s solution will increase the resiliency and availability of microservices-based workloads with clear policy definitions, policy enforcement, and auditing of policies for both legacy and cloud-native workloads.

Solution Benefits

As in other integrations with similar proxy-based solutions (e.g., API gateways), SGNL can help secure your Envoy-proxied services and guard against:

1. Unauthorized access from parties that should not have access to specific proxied resources
2. Accidental sensitive data leakage
3. Inadvertently elevated permissions for a principal
4. Stale permission sets
5. Stale and inaccurate access policies

SGNL provides continuous access management by building a dynamic graph directory through continuous data ingestion from systems of record. With SGNL, access control is enforced consistently and easily across all protected services, applications, and data using human-readable policies. With the Envoy proxy and SGNL, you can externalize access management to a scalable and modern platform, minimize security exposure, and implement a truly least-privileged approach to securing your microservices.

With the Envoy proxy and SGNL, you can externalize access management to a scalable and modern platform, minimize security exposure, and implement a truly least-privileged approach to securing your microservices.

What Is A Service Mesh

A service mesh is a cloud-native architecture for externalized traffic management, observability, security, networking, availability, and monitoring services in modern microservices-based workloads and applications. Many large enterprises are evaluating service meshes as their “next generation” enterprise architecture for enterprise applications. Since service meshes such as Istio commonly use Envoy, the solution explained in this post may be applied to an Istio-based service mesh architecture in today’s enterprise.

Envoy Authorization Considerations

Enterprise-scale access management must be considered as a part of an overall security strategy for Envoy proxied services. Here are some points to consider:

• Access is more than just service-level authentication - Review your security requirements and strategy for protected services. Determine the level of authorization controls, audit, logging, and centralized policy management you need. These requirements exceed OAuth 2.0, OpenID Connect, and mutual TLS.
• RBAC is no longer sufficient - As you may know, you can implement the Envoy RBAC filter with Common Expression Language (CEL) policies. This works great for static coarse-grained authorization and a small set of protected resources, but in most cases, you need dynamic, fine-grained permissions to prevent unauthorized access. For example, your organization may have multiple partners, and each partner may have a license to use different features exposed by the same or different service. RBAC is insufficient to handle such use cases, or the manual management overhead of creating CEL policies may become too heavy for RBAC to be viable.
• Extend security to the backend - It is good to think about authentication and authorization from the front end to the back end. In other words, consider the impact of the front-end Envoy security controls and determine if the same requirements exist for the backend service. Will you need coarse-grained authorization or fine-grained authorization, or both?

How It Works

The solution consists of an Envoy gRPC AuthZ service, Envoy external authorization filter configuration, and the SGNL platform. The Envoy proxy is configured to send authorization requests to the external Envoy gRPC AuthZ service. The Envoy gRPC AuthZ service sends context and authorization requests to SGNL for policy calculation and evaluation. The SGNL access service responds with allow and deny decisions considering the context of the authorization request. The Envoy gRPC AuthZ service then sends an allow or deny response to the Envoy proxy. If the request is denied, the Envoy proxy sends the appropriate response to the caller.

Envoy sidecars run beside every Kubernetes cluster/pod service and are responsible for externalizing network routing, observability, load balancing, and security. This solution implements the Envoy external authorization filter protos that are part of the Envoy filter chain.

Sample Request Flow

1. The client sends a request for a service through Envoy. First, an Envoy HTTP filter chain is created and executed. Then, the request first passes through the Envoy external authorization filter, which reads the request, and sets the correct HTTP headers, request context, and body for sending to the Envoy gRPC AuthZ service.
2. The Envoy gRPC AuthZ service sends an authorization query to the SGNL access service. Note that the AuthZ service uses a protected system bearer token that identifies the protected system used to evaluate the authorization request.
3. The SGNL policy engine evaluates the request and makes an allow or deny decision.
4. The policy engine responds to the Envoy gRPC AuthZ service with an (A) allow or (B) deny.
5. (A) The Envoy gRPC AuthZ service responds with an HTTP 200 to the Envoy reverse proxy if allowed. (B) If Deny, the Envoy gRPC AuthZ service returns 403 Forbidden to the Envoy reverse proxy.
6. (A) If denied, the Envoy external authorization filter passes the request on to the rest of the filter chain with the 403 status code, preventing the client from accessing the application. (B) If allowed, the Envoy filter passes the request to the rest of the filter change with a 200 OK status code. Envoy routes the request to the cluster (backend service), handling the specific load-balancing operations to find a service endpoint to fulfill the request.
7. The backend service performs its operations and sends a response back through Envoy. The response passes through the HTTP filters in reverse order from the request, starting at the router filter and passing through the Envoy external authorization filter.
8. Envoy sends the backend service response to the client.

Deployment Diagram

The Envoy gRPC AuthZ service may be deployed locally in the service mesh and each pod in a sidecar model, or it may be deployed outside of the service mesh. There are pros and cons to each deployment model. This diagram shows the model where the Envoy gRPC AuthZ service is deployed inside the service mesh alongside the Envoy sidecar.

Envoy Configuration

In order to call the Envoy gRPC AuthZ service, you need to tell Envoy where to send the gRPC request when performing authorization. Below is an example of an HTTP Filter configuration:

http_filters:
  - name: envoy.filters.http.ext_AuthZ
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.ext_AuthZ.v3.ExtAuthZ
transport_api_version: V3
grpc_service:
envoy_grpc:
cluster_name: ext-AuthZ

The configuration above defines an external authorization filter. The “ext-AuthZ” is the cluster name that defines the additional configuration for sending the authorization request to the Envoy gRPC AuthZ service. Here is an example cluster configuration:

- name: ext-AuthZ
type: static
http2_protocol_options: {}
load_assignment:
cluster_name: ext-AuthZ
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: {{Insert hostname for Envoy gRPC AuthZ service}}
port_value: 8223
common_lb_config:
healthy_panic_threshold:
value: 50.0
health_checks:
- timeout: 1s
interval: 5s
interval_jitter: 1s
no_traffic_interval: 5s
unhealthy_threshold: 1
healthy_threshold: 3
grpc_health_check:
service_name: "envoy.service.auth.v3.Authorization"
authority: "server.domain.com"

Benefits of Using SGNL

Here are the benefits of using SGNL with Envoy:

1. Business Data Driven Continuous Access Management. Any changes recorded in an organization’s business systems (e.g., ServiceNow, Salesforce, HRIS) of record are automatically and rapidly reflected in Envoy proxy access decisions without changing proxy policy or configuration.
2. Real-time Audit and Comprehensive Reporting. With SGNL, all Envoy proxy access decisions are logged centrally with the policies that contributed to the decision to grant or deny access.
3. Centralized Human-Readable Policies. Human-readable policies using reusable snippets enable organizations to scale policies without losing manageability and consistency.
4. Consistent Authorization Decisions Across All Services. Envoy using SGNL, provides the same decisions consistently based on centrally managed human-readable policies.
5. Contextual Authorization Decisions. Any access decision is determined considering the context of the request coming from the Envoy proxy at runtime. The request context received from Envoy is kept intact through the SGNL access service and back through the Envoy proxy.

How Does SGNL Work

SGNL continuously ingests data from systems of record to a central graph directory via resilient and performant adapters. This data includes identity data, such as users and groups, and any relevant data required to define access policies, such as ITSM cases or customers from CRM.

In this post, we use ServiceNow and Okta. Okta is our Identity Provider system of record, and ServiceNow provides the assigned and active case for the user.

Once the system of record data sources is setup, administrators can quickly author and manage human-readable policies based on the ingested data for granting or denying access to applications, APIs, and sensitive data. By implementing a centralized approach, SGNL provides consistency in centralized policy management, audit logging, and reporting across all assets an organization desires to protect (including APIs).

Instead of creating your own external authorization service to evaluate access, you use SGNL to select policy snippets from the user interface and graphically build a human-readable policy. The SGNL Envoy policies ensure that any request to the Envoy proxy is evaluated against the latest data ingested from systems of record and the policies defined in SGNL.

An example of a real human-readable policy for protecting Envoy resources

This human-readable policy allows access to engineering services for clients acting on behalf of engineering principals. When the client makes a request through the envoy proxy, the SGNL access service authorizes the request through the Envoy gRPC AuthZ service. The authorization result is then centrally monitored and audited.

Conclusion

Using this SGNL and Envoy integration, organizations can reduce risk; developers can reduce authorization logic complexity and leverage a centralized access management policy platform for making complex, consistent, and continuous authorization decisions.

Schedule time with a SGNLer to see how all this can work in your context.