Protecting Microservices with Envoy Proxy and SGNL

Introduction

Protected Systems are applications, services, or infrastructure that you want to protect with SGNL. In this guide, we’ll describe how to enhance access control for your Microservice infrastructure via an integration betweem SGNL and Envoy Proxy. In doing so, we’ll enable continuous, centralized access management that leverages a central set of human-readable policies.

With this integration, your Microservice Infrastructure need not know about the policies, systems of record, or any of the data in SGNL - it simply needs to pass to SGNL:

  • Who/What is requesting the access (The Principal)
  • (Optional) What is attempting to be accessed (The Asset)
  • (Optional) What operation is being attempted on the asset (The Action)
  • An access token that ensures the Protected System is a legitimate caller into SGNL

Prerequisites

  • An existing microservice deployment with a configured Envoy Proxy
  • A SGNL Client
  • A SGNL User Account with Admin privileges
  • At least 1 system of record integrated to SGNL, containing principals and (optionally) assets that will be evaluated in access evaluations
  • (Optional) 1 or more policies that you want assigned to the integration

Creating a Protected System in SGNL

  1. Log-In to your SGNL Client with an Admin Account
  2. From the left navigation pane, select Protected Systems and Add, or simply click Add from the SGNL Dashboard
  3. Select ‘Envoy Proxy’ from the Infrastructure category in the list of integrations
  4. Give your integration a descriptive display name and description
  5. Specify the Default Policy to be applied to your App
    • Allow: If no policies provide a decision for an access request, SGNL will respond to the access request with an Allow decision
    • Deny: If no policies provide a decision for an access request, SGNL will respond to the access request with a Deny decision
  6. Next, you’ll need to configure which identifier Envoy is using to describe your user/principal
    • This may be an email address or Username that can be found in your IdP, or an EmployeeID in your HRIS system. This should be in the format of the Principal ID of the user that will request access to the Protected System.
    • e.g. If an Okta user will be requesting access to this Protected System, Envoy, the principal identifier should be the Okta email address.
  7. You’ll also need to define the types of Assets that Envoy is proxying access to
    • This might be customer identifiers sourced your CRM system, or products that your customers are buying
  8. Once configured, click Continue to save your configuration and move on to other configuration steps

Configuring Authentication

  1. Authentication ensures that only authorized systems can make requests into SGNL, as well as verifying the identity of an integration in order to effectively evaluate Policies - to access Authentication settings, open your Envoy-enabled protected system and select the Authentication tab

    SGNL - Authentication

  2. Click Generate Token

  3. Give your token a descriptive name so that you know how it’s being used in the future and click to Generate Token

    SGNL - Generate Token

  4. On the next screen, copy the token - this will be used by Envoy to make access requests to SGNL using the SGNL Access Service API

    Note: The value of this token is not available again after this screen, so ensure you securely store it for steps later in this guide

    SGNL - Token

Integrating Envoy Proxy with SGNL

Integrating Envoy Proxy with SGNL comprises an Envoy external authorization adapter, Envoy external authorization filter configuration, and the SGNL platform. The Envoy proxy is configured to send authorization requests to the Envoy external authorization adapter. The adapter sends context about the principal alongside the authorization request to SGNL for policy evaluation. The SGNL access service responds with allow and/or deny decisions based on the context and the authorization request.

Once the decision is made, the Envoy external authorization adapter then sends an allow or deny response to the Envoy proxy. If the request is denied, the caller is blocked from gaining access to the requested resource. Otherwise, the request proceeds as normal.

Envoy runs alongside Microservices Infrastructure and is 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.

Envoy Configuration

In order to call the Envoy external authorization adapter, 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 external authorization adapter. 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: {{SGNL AuthZ Service}}
port_value: {{Port Number}}
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"

At this point, it’s likely that all decisions will either be Allow or Deny, based on the Default Decision you’ve selected for the Envoy Integration - if that’s the case, you’re ready to start assigning policies.

Assigning Policies

  1. Once the Envoy integration is created, you can start assigning versions of Policies - to get started, select Policies from the tabs in your newly created integration

    SGNL - Policies

  2. Select ‘Assign Policies’

  3. Select:

    • The Policies you want to apply to the integration with the check box
    • The version of the Policy you want applied

    SGNL - Select Policies

  4. Click Next once you have the Policies and Versions configured as is appropriate

  5. Select the Enforcement mode for the Policies you chose in the previous step

    • Simulated: Policy Versions that are being simulated will only log their access decision in the SGNL logs and will not impact the access decision that SGNL hands back to an integration. Simulated policies are useful for performing what-if analysis of new policy versions as well as debugging policy changes.

      Note: It’s considered best practice to start with policies in Simulated mode, to verify that policies have been created an applied as expected

    • Enforced: Policy Versions that are being enforced will impact the access decisions that SGNL hands back to an integration. Enforced Policies will determine access for an integration

    SGNL - Set Enforcement

  6. Select your desired Enforcement mode and select Assign

  7. Versions of Policies will now be Assigned to your integration

    SGNL - Policy Assignments