Transformation
Alter a request before matching and routing, such as with an Inja header template.Transformation policies apply to the route. You might transform the request or response to match a different routing destination based on the transformed content.
You can also apply special transformations, such as via Inja templates. With Inja, you can write loops, conditional logic, and other functions to transform requests and responses.
For more information, see the following resources.
If you import or export resources across workspaces, your policies might not apply. For more information, see Import and export policies.
Before you begin
Follow the getting started instructions to:
- Set up Gloo Gateway in a single cluster.
- Deploy sample apps.
- Configure an HTTP listener on your gateway and set up basic routing for the sample apps.
Configure transformation policies
You can apply a transformation policy at the route level. For more information, see Applying policies.
Review the following sample configuration files.
The following example is to inject a header with simple Inja template into a request.
apiVersion: trafficcontrol.policy.gloo.solo.io/v2
kind: TransformationPolicy
metadata:
annotations:
cluster.solo.io/cluster: ""
name: basic-auth
namespace: bookinfo
spec:
applyToRoutes:
- route:
labels:
route: httpbin
config:
request:
injaTemplate:
headers:
foo:
text: bar
Review the following table to understand this configuration. For more information, see the API docs.
Setting | Description |
---|---|
spec.applyToRoutes |
Use labels to configure which routes to apply the policy to. This example label matches the app and route from the example route table that you previously applied. If omitted, the policy applies to all routes in the workspace. |
config.request |
Transform the request before sending to the upstream service. The example adds a foo: bar header. |
The following example is to inject a header with simple Inja template into a response.
apiVersion: trafficcontrol.policy.gloo.solo.io/v2
kind: TransformationPolicy
metadata:
annotations:
cluster.solo.io/cluster: ""
name: basic-auth
namespace: bookinfo
spec:
applyToRoutes:
- route:
labels:
route: httpbin
config:
response:
injaTemplate:
headers:
foo1:
text: bar1
Review the following table to understand this configuration. For more information, see the API docs.
Setting | Description |
---|---|
spec.applyToRoutes |
Use labels to configure which routes to apply the policy to. This example label matches the app and route from the example route table that you previously applied. If omitted, the policy applies to all routes in the workspace. |
config.response |
Transform the response before returning to the client. The example adds a foo1: bar1 header. |
You can use a replace_with_random
function in a transformation policy to replace a string in a request and response with a random, unique value per request-response pair in the header, body, or metadata. For example, you might have a request with an ID, nonce, or other sanitized value that shares the value with other requests. You want to replace this value with a new, random value that is unique to the request so that you can build response-specific logic in your app.
- The function is in the format:
replace_with_random(source_string, pattern_to_replace_string)
. - The
pattern_to_replace_string
pattern is an exact match string. - The replaced value is a 128-bit, base64-encoded random number.
Review the following example Inja template.
apiVersion: trafficcontrol.policy.gloo.solo.io/v2
kind: TransformationPolicy
metadata:
annotations:
cluster.solo.io/cluster: ""
name: transformation-one
namespace: bookinfo
spec:
applyToRoutes:
- route:
labels:
route: ratings
config:
phase:
postAuthz:
priority: 10
response:
injaTemplate:
advancedTemplates: false
parseBodyBehavior: DontParse
headers:
baz:
text: '{{ replace_with_random(header("baz"), "pattern-to-replace") }}'
foo:
text: '{{ replace_with_random(header("x-foo"), "another-pattern-to-replace") }}'
body:
text: ' {{ replace_with_random(body(), "pattern-to-replace") }}'
Review the following table to understand this configuration. For more information, see the API docs.
Setting | Description |
---|---|
spec.applyToRoutes |
Use labels to configure which routes to apply the policy to. This example label matches the app and route from the example route table that you previously applied. If omitted, the policy applies to all routes in the workspace. |
config.phase |
Set when to apply the transformation filter in the request chain, either before (preAuthz ) or after (postAuthz ) authorization. You can also set the priority if you have multiple policies in the same phase. The lowest numbered priority is run first. For more information, see Order of applied policies. This example sets postAuthz so that the policy can extract authorization information such as an external auth ID or JWT token. |
config.response.injaTemplate |
The Inja template with header and body rules to use to transform data in the response that is received from the upstream service before returning the response to the client. To configure an Inja template to transform data before sending a request to an upstream, you can use config.request.injaTemplate . |
advancedTemplates: false |
Set to false to use simple naming and dot notation (such as time.start ) for the extraction rules in the template. For more information, see the Envoy transformation proto. |
parseBodyBehavior: DontParse |
Set to DontParse to treat the response and request bodies as plain text, not JSON (ParseAsJson ). |
headers |
Configure the replacement rules for request headers. The example replaces the pattern-to-replace pattern in the baz header and the another-pattern-to-replace pattern in the x-foo header. |
body |
Configure the replacement rules for the request body. The example replaces the pattern-to-replace pattern anywhere in the request body. The replacement value for the pattern-to-replace pattern in the body is the same as the replacement value in the baz header because the patterns match. However, the replacement value for the body differs from the foo header because the patterns do not match. |
Verify transformation policies
-
Apply the example transformation policy in the workload cluster.
kubectl apply -f transformation-policy.yaml
-
Send a request to the
httpbin
app through the ingress gateway. -
Verify that you notice the transformed request and response headers.
-
Optional: Clean up the resources that you created.
kubectl -n bookinfo delete transformationpolicy basic-auth