Apigee Adapter for Envoy release notes

You can now enable the adapter to service multiple environments in an Apigee organization. This feature allows you to use one Apigee Adapter for Envoy associated with one Apigee organization to service multiple environments. Before this change, one adapter was always tied to one Apigee environment. For more information about this feature, see Multi-tenant environment support.

Envoy 1.16+ allows sending ext_authz metadata without having to use headers. By using this and related changes, we now provide better HTTP response codes for denied requests, and we no longer need to install an RBAC filter in Envoy. See

This feature is only supported for Envoy 1.16+ and Istio 1.9+.

With this change, the following configuration is no longer added to the Envoy configuration file (envoy-config.yaml):

additional_request_headers_to_log:
    - x-apigee-accesstoken
    - x-apigee-api
    - x-apigee-apiproducts
    - x-apigee-application
    - x-apigee-clientid
    - x-apigee-developeremail
    - x-apigee-environment

If you want to append headers to requests for a special case, just set the property append_metadata_headers:true in the adapter's config.yaml file.

The remote-service proxy has been refactored into two separate proxies. The v2.0.x, provisioning will install two API proxies: remote-service and remote-token. The /token and /certs endpoints were moved from the remote-service proxy to remote-token.

This change creates a useful separation of functions. Now, the remote-service proxy is only used for internal Adapter communications, while the remote-token proxy provides a sample OAuth workflow that you can customize. We will never overwrite your custom remote-token proxy, even if the provision --force-proxy-install command is used.

Only avaliable for Apigee X and Apigee hybrid.

The Adapter now supports passing Envoy metadata to Apigee's data capture feature, which sends data captured in variables that you specify to Apigee analytics for use in custom reports.

As noted previously under Envoy metadata support, we now immediately reject unauthorized requests without requiring a separate RBAC filter. Because RBAC is not used, clients will now receive these HTTP status codes as appropriate from the Adapter:

• 401 Unauthorized
• 403 Forbidden
• 429 Too Many Requests
• 500 Internal Server Error

If you want to allow unauthorized requests to continue, you can do so by setting auth:allow_unauthorized:true in the adapter's config.yaml file.

As noted previously in the Envoy metadata support section, x-apigee-* headers are no longer appended by default. If you want to add them, set append_metadata_headers:true in the config.yaml file. This configuration is completely optional and should only need to be used when it's desirable to forward headers to the upstream target service.

The semantics of the api_header config property remain the same as the former target_header property (the default is still the target host name), and the specified header’s contents still will match either the API Product Remote service target attribute or apiSource field in an API Product operation (Apigee hybrid and Apigee X only).

To override this header value using Envoy metadata, you can pass the apigee_api metadata element from Envoy to the adapter to directly specify the API Product’s Remote Service Target or API Product Operation’s API Source. To configure, add code similar to the following to the Envoy configuration file (which you can generate using the Adapter's CLI):

typed_per_filter_config:
  envoy.filters.http.ext_authz:
    "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthzPerRoute
    check_settings:
      context_extensions:
        apigee_api: httpbin.org

Envoy Adapter will now log rejected requests immediately to analytics as required instead of waiting for the request to return in the access log. This is more efficient and doesn’t require any metadata be attached to the request.

Streaming to Apigee's Universal Data Collection Agent (UDCA) in Apigee hybrid and Apigee X is no longer needed for analytics as it has been replaced by direct upload. This change simply removes the legacy support for this option.

Apigee Edge for Private Cloud users can supply client-side TLS certificates and root cert via ‑‑tls‑cert, ‑‑tls‑key and ‑‑tls‑ca respectively when provisioning or listing products bindings using the CLI.

You can supply client-side TLS certificates in the tenant section of the adapter's config.yaml file to use mTLS between the adapter and the Apigee runtime. This change applies to all supported Apigee platforms. It also enables mTLS for analytics for the Apigee Edge for Private Cloud platform. For more information, see Configuring mTLS between the adapter and Apigee runtime.