Gloo Gateway as a waypoint proxy ENTERPRISE ALPHA
Enforce Layer 7 policies for the apps in your ambient mesh by using Gloo Gateway as a waypoint proxy.
Gloo Gateway as a waypoint proxy is an alpha feature. Alpha features are likely to change, are not fully tested, and are not supported for production. For more information, see Alpha and beta release process.
This feature is Enterprise-only and requires a Gloo Gateway Enterprise license. Running Gloo Gateway Enterprise version 1.19 or later is strongly recommended.
About ambient mesh
Solo collaborated with Google to develop ambient mesh, a new “sidecarless” architecture for the Istio service mesh. Ambient mesh uses node-level ztunnels to route and secure Layer 4 traffic between pods with mutual TLS (mTLS). Waypoint proxies enforce Layer 7 traffic policies whenever needed. To onboard apps into the ambient mesh, you simply label the namespace the app belongs to. Because no sidecars need to be injected in to your apps, ambient mesh significantly reduces the complexity of adopting a service mesh.
To learn more about ambient, see the ambient mesh documentation.
About this guide
In this guide, you learn how to set up Gloo Gateway as a waypoint proxy for multiple apps in your ambient mesh. To demonstrate the Layer 7 capabilities of the waypoint proxy, you deploy the three sample apps client
, httpbin2
, and httpbin3
to your cluster. The client
app sends in-mesh traffic to httpbin2
and httpbin3
. To apply Layer 7 policies, you create HTTPRoute resources for the httpbin2
and httpbin3
apps that define the policies that you want to apply to each app. Because the HTTPRoute is scoped to a particular service, when the client
app sends a request to that service, only the policies that are defined for that service are enforced by the waypoint proxy.
You can create an HTTPRoute and scope it to the waypoint proxy by referencing the waypoint proxy in the parentRef
section. This way, the policies that are defined in the HTTPRoute are automatically applied to all services in the waypoint proxy namespace.
Set up an ambient mesh
Set up an ambient mesh in your cluster to secure service-to-service communication with mutual TLS.
- Ambient mesh with the Solo distribution of Istio: Follow the instructions in the Gloo Mesh documentation to Deploy Istio in ambient mode. These instructions use the Solo distribution of Istio, which is a hardened Istio image provided by Solo. You do not need to create an Istio ingress gateway, as you configure Gloo Gateway as the ingress gateway for your ambient mesh.
- Community ambient mesh: You can install the community version of ambient mesh by following the ambient mesh quickstart tutorial. This tutorial uses a script to quickly set up an ambient mesh in your cluster. You do not need to create an Istio ingress gateway, as you configure Gloo Gateway as the ingress gateway for your ambient mesh.
Deploy sample apps
Install the httpbin2, httpbin3, and curl client sample apps into the httpbin namespace. You use these sample apps to demonstrate the Layer 7 capabilities of the waypoint proxy.
Create the httpbin namespace.
Deploy the httpbin2, httpbin3, and client sample apps.
Verify that all apps are deployed successfully.
Example output:
Label the httpbin namespace to add the httpbin2, httpbin3, and client apps to the ambient mesh.
Enable the Gloo Gateway ambient integration
To create a waypoint proxy that uses Gloo Gateway, you must first enable the ambient integration in Gloo Gateway.
Create a waypoint proxy
Use the gloo-waypoint GatewayClass to deploy Gloo Gateway as a waypoint proxy in your cluster.
Create a waypoint proxy in the httpbin namespace. Note that creating a waypoint proxy does not automatically enforce Layer 7 policies for the apps in your cluster. To assign a waypoint, you must label your apps. You learn how to label your apps in a later step.
Wait for the waypoint proxy to deploy successfully.
Example output:
Label the httpbin2 and httpbin3 apps to use the waypoint proxy that you created.
Send a request from the client app to httpbin2 and httpbin3. Verify that the request succeeds.
Example output for httpbin2:
Enforce L7 policies with the waypoint
In this step, you explore how to apply header modification, external auth, and rate limit Layer 7 policies to your sample apps. These policies are enforced by the Gloo Gateway waypoint proxy that you created earlier. You can add other Layer 7 policies to the waypoint proxy. For more information, see the traffic management, security, and resiliency guides.
Header control
Use the Kubernetes Gateway API to define header manipulation rules that you apply to the httpbin apps, including adding, setting, and removing request headers.
Create an HTTPRoute resource for the httpbin2 app with the following request header modifications rules:
- Add the
App: httpbin2
header to all requests. - Set the
User-Agent
header tocustom
. If the User-Agent header is not present, it is added to the request. - Remove the
X-Remove
header from the request.
Note that the HTTPRoute specifies the httpbin2 service in the
parentRefs
section. This setting instructs the waypoint proxy to enforce these policies for the httpbin2 app only.- Add the
Create an HTTPRoute for the httpbin3 app with the following request header modifications rules:
- Add the
App: httpbin3
header to all requests.
- Add the
Use the client sample app to send a request to the httpbin2 app. Verify that you see the
App: httpbin2
andUser-Agent: custom
headers, and that theX-Remove
was not added to the respones.Example output:
Send the same request to the httpbin3 app. Verify that you see the
App: httpbin3
header andX-Remove
headers, and that theUser-Agent
header is not changed tocustom
.Example output:
Optional: Remove the HTTPRoutes for the httpbin2 and httpbin3 apps.
External auth with API keys
Create an AuthConfig to secure traffic to the httpbin2 app with an API key.
Create AuthConfig and Kubernetes secret resources to set up API key authentication for the httpbin2 app. The AuthConfig allows requests with the
mykey
API key that is stored in the secret. In addition, it extracts theorganization
field from the Kubernetes secret and adds the value as theX-Organiztion
request header.Create a RouteOption resource that references the AuthConfig that you created.
Create an HTTPRoute resource that routes traffic to the httpbin2 app. This resource is required for the waypoint proxy to enforce the external auth policies that you defined in your RouteOption.
Send a request to the httpbin2 app without an API key. Note that the request is denied and you get back a 401 HTTP response code.
Example output:
Send another request. This time, you include the API key that you stored in the secret. Verify that you get back a 200 HTTP response code and that you see the
Api-Key
andX-Organization
headers in your CLI output.Example output:
Send a request to the httpbin3 app without any API key. Verify that no external authentication is required for that app.
Example output:
Optional: Delete the external auth resources.
Rate limit
Create different RatelimitConfig resources to limit the number of requests that you can send to the httpbin2 and httpbin3 apps.
Create a RatelimitConfig to set up your rate limiting rules for the httpbin2 app.
Create a RouteOption configuration that references the RatelimitConfig that you created earlier.
Create an HTTPRoute resource for the httpbin2 app. This resource is required to enforce the Layer 7 rate limiting rules for only the httpbin2 app.
Send multiple requests to the httpbin2 app. Verify that the first request comes back with a 200 HTTP response code and that any subsequent requests are denied with a 429 HTTP response code.
Example output:
Create another RatelimitConfig for the httpbin3 app. This configuration rate limits requests if the
X-Organization: myorg
header is present on the request.Create a RouteOption resource that references your RatelimitConfig.
Create an HTTPRoute resource for the httpbin3 app. This resource is required to enforce the Layer 7 rate limiting rules for only the httpbin3 app.
Send multiple requests to the httpbin3 app without the
X-Organization
header. Verify that you are not rate limited after the first request.Example output:
Repeat the requests. This time, you include the
X-Organization: myorg
header. Verify that the first request comes back with a 200 HTTP response code and that any subsequent requests are denied with a 429 HTTP response code.Example output:
Optional: Delete the ratelimit resources.
Cleanup
Delete the resources that you created in this guide.