Ambassador Pro 0.5: Identity Aware Proxy for Kubernetes, support for Azure AD and Google Identity Platform

Today, we’re thrilled to announce Ambassador Pro 0.5, a major release of the enterprise version of the Ambassador API Gateway. This release enables Ambassador to function as a sophisticated Identity Aware Proxy as part of implementing a Zero Trust security architecture on Kubernetes.

Zero Trust Security

In the traditional network-oriented security model, trust is assumed by your network location: if you’re inside the network (e.g., behind the firewall), you’re trusted. If you’re outside the network, you’re not trusted until you join the network (e.g., by connecting via VPN).

This trust model does not extend well to modern networks:

• There is no “defense in depth”. Once an attacker breaches the (network) perimeter, an attacker in this model has full access to all internal resources.
• Modern infrastructure is fully distributed: cloud providers, on-premises data centers, laptops, mobile devices. Creating a strong perimeter across this diffuse edge is impractical.

In the zero trust model, every request to a resource is verified, regardless of where that request originates. Google was one of the first companies to deploy a complete zero trust architecture, as detailed in their BeyondCorp security architecture whitepaper.

Identity-Aware Proxy

One of the key components of a zero trust architecture is request verification. Therefore an important question to ask is how do you verify every request? Implementing a secure authentication and authorization solution is complex. Moreover, in a cloud-native architecture that consists of multiple microservices, each microservice cannot practically implement its own authentication mechanism. Instead, an Identity-Aware Proxy (IAP) is deployed in front of an application. Access to the application is gated by the IAP, which can authenticate users, check authorization, and enforce other types of security policies. Critically, the IAP operates at the application level, which means the IAP can take advantage of domain knowledge of users to improve security. The IAP interfaces with the Identity Provider (IdP), which is the trusted canonical source for authentication and authorization information.

Ambassador Pro 0.5: Cloud-Native Identity-Aware Proxy

The 0.5 release extends the previous security capabilities of Ambassador Pro enabling the gateway to function as a secure Identity-Aware Proxy. 0.5 adds:

• A revamped, fully standards-compliant OAuth2 implementation that can interface with any OIDC-core compliant identity provider.
• Support for OAuth refresh tokens.
• CSRF protection support.
• Intelligent caching of authentication requests to maximize performance and minimize the load on your IdP.
• Certified support for both Azure Active Directory and Google Identity Platform as your Identity Providers, adding to our pre-existing support of Auth0, CloudFoundry UAA, Keycloak, and Okta.

Implementing Zero Trust Security within Kubernetes

With this release, Ambassador Pro supports a broad spectrum of capabilities that help you to implement a Zero Trust security architecture. These capabilities are focused on a threat model involving application-level attackers, and include:

• Authentication and authorization, integrating with your previous identity provider.
• Application-level rate limiting.
• A pluggable mechanism for inspecting and manipulating incoming requests, letting you implement custom business logic to validate and transform application traffic.
• Support for managing and deploying all these mechanisms on a per-service basis, which enables you to flexibly deploy Ambassador in front of multiple different types of services.

Full Release Notes and Breaking Changes

Here is a list of detailed changes to Ambassador Pro.

• A Redis instance/cluster is now always required to be running and configured correctly.
• The amb-sidecar environment variables $APRO_PRIVATE_KEY_PATH and $APRO_PUBLIC_KEY_PATH are replaced by a Kubernetes secret and the $APRO_KEYPAIR_SECRET_NAME and $APRO_KEYPAIR_SECRET_NAMESPACE environment variables.
• The OAuth2 Filter now ignores the audience field setting (this will be addressed in the near future).
• The OAuth2 Filter now acts as if the openid scope value is always included in the FilterPolicy's scopes argument.
• The OAuth2 Filter can verify Access Tokens with several different methods; configured with the accessTokenValidation field.
• The OAuth2 Filter is now strictly compliant with OAuth 2.0.
• The OAuth2 Filter browser cookie is now named ambassador_session.{{filter_name}}.{{filter_namespace}} instead of access_token, and is an opaque string instead of a JWT Access Token. The Access Token is still available in the injected Authorization header.
• The OAuth2 Filter will no longer consider a user-agent-provided Authorization header; it will only consider the cookie.
• The OAuth2 Filter now supports Refresh Tokens; they must be requested by listing offline_access in the scopesargument in the FilterPolicy.
• The OAuth2 Filter's /callback endpoint is no longer vulnerable to XSRF attacks

Get Started with Ambassador Pro Today

Contact us for more information. If you’re already using Ambassador, we strongly recommend that you upgrade in order to take advantage of this new functionality.