Aws-app-mesh-roadmap: Feature Request: Support matching on headers and hostnames in Virtual Gateway

[rajal-amzn]

If you want to see App Mesh implement this idea, please upvote with a :+1:.

Tell us about your request
Currently Gateway Routes support matching based on prefix/service names in HTTP/GRPC and route it to a Virtual Service on match. But, we need to extend this to allow more complex matching rules like HTTP headers, hostnames and GRPC metadata.

Which integration(s) is this request for?
Applicable to all integrations- Fargate, ECS, EKS, EC2, Kubernetes.

Attachments
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

[ganapras]

Hello! Is there an update on when this feature will be supported ?

[rajal-amzn]

Hello all,
We are currently working on the design of supporting hostnames and headers in Virtual Gateway.

For those customers who want to use a single Virtual Gateway for different hostnames, we would like to understand your requirements for TLS:

• Would you want to use different certificates for different hostnames at Virtual Gateway?
• If yes, would adding SNI based TLS termination help? If not, please expand on your usecase.
• Would you also want SNI based TLS termination at Virtual Nodes?

Your input on this would be much helpful for prioritizing this. Thank you for taking time.

[blackey-mitek]

Good evening, For our use case, we do not need SNI as the certificates are wildcard. for example...

We have HTTP services that need to be reachable from other mesh services and from outside.

1. The VirtualGateway containers will pick up a ACM PCA wildcard cert from ACM.
2. As these HTTP services are added to the mesh with cform, they will also get a R53 record pointing to an external LB (NLB likely). Example: *.prod.mesh.cloud.local
3. As multiple services are added, there will be several hostnames pointing at this LB and passed on to the Virtual Gateway. serviceA.prod.mesh.cloud.local, serviceB.prod.mesh.cloud.local.
4. We want routing rules to pass the request to specific mesh Virtual Services. This allow us to have one inbound path to the mesh for several services.
5. We would use path routing, but we have path conflicts at the moment.

[rajal-amzn]

@blackey-mitek Got it. Thank you for your input.

[rajal-amzn]

Hey all,
We are adding the following fields in Gateway Route in order to support matching on headers and hostnames at Virtual Gateway:

• Hostname field: This will be used to specify the hostname that should be matched on the incoming request to route to the target Virtual Service.
• Headers/metadata field: This will be used to specify the headers (for HTTP & HTTP2)/metadata (for GRPC) that should be matched on the incoming request to route to the target Virtual Service.
• Method field for HTTP/HTTP2 Routes: This will be used to specify the method header to be matched in the incoming HTTP/HTTP2 requests.
• Priority field: This will be used to specify the ordering of the Gateway routes.

Note that the Virtual Gateway supports specifying a single TLS settings (for both TLS termination and Client TLS validation) and that TLS settings would be applied for all the traffic with multiple hostnames. Support for vending different server certificates based on the SNI in the incoming request is being tracked here

API model
Following represents the updated API model for HTTP Gateway Routes. HTTP2 Gateway Routes would follow similar model changes.

kind: GatewayRoute
spec:
  # (NEW) (OPTIONAL) Specifies ordering of Gateway routes. 0 being the highest priority
  priority: 0
  httpRoute:
    match:
        prefix: "/" #Existing field.
        # (*NEW*) (OPTIONAL) Specifies Method to match in the incoming request
        method: "GET"
        # (*NEW*) (OPTIONAL) Specifies hostname to be matched in the request
        hostname:
            # (*NEW*) (OPTIONAL) Specifies the exact hostname to be matched in the request
            exact: "example.com"
            # (*NEW*) (OPTIONAL) Specifies the suffix hostname to be matched in the request
            suffix: ".example.com" # Optional field
        # (*NEW*) (OPTIONAL) Specifies list of headers to be matched in the request. When multiple headers are specified, **AND** of conditions would be applied.
        headers: 
            # (*NEW*) (REQUIRED) Specifies name of the header to be matched
            - name: "header"
               # (*NEW*) (OPTIONAL) Specifies whether the header match condition should be inverted
               invert: true
               # (*NEW*) (OPTIONAL) Specifies the match condition for the header value in the request
               match:
                   # (*NEW*) (OPTIONAL) Specifies the exact header value to be matched
                   exact: "exact"
                   # (*NEW*) (OPTIONAL) Specifies the prefix of the header value to be matched
                   prefix: "prefix"
                   # (*NEW*) (OPTIONAL) Specifies the suffix of the header value to be matched
                   suffix: "suffix"
                   # (*NEW*) (OPTIONAL) Specifies the regex the header value to match
                   regex: "regex"
                   # (*NEW*) (OPTIONAL) Specifies the range the header value to match
                   range:
                      # (*NEW*) (REQUIRED) Specifies the start range of the header value
                       start: 0
                      # (*NEW*) (REQUIRED) Specifies the end range of the header value
                       end: 10
   # Existing field
    action:
      ...

Following represents the updated API model for GRPC Gateway Routes

kind: GatewayRoute
spec:
  # (*NEW*) (OPTIONAL) Specifies ordering of Gateway routes. 0 being the highest priority
  priority: 0
  grpcRoute:
    match:
        serviceName: "service" #Existing field.
        # (*NEW*) (OPTIONAL) Specifies hostname to be matched in the request
        hostname:
            # (*NEW*) (OPTIONAL) Specifies the exact hostname to be matched in the request
            exact: "example.com"
            # (*NEW*) (OPTIONAL) Specifies the suffix hostname to be matched in the request
            suffix: ".example.com" # Optional field
        # (*NEW*) (OPTIONAL) Specifies list of metadata to be matched in the request. When multiple metadata are specified, **AND** of conditions would be applied.
        metadata: 
            # (*NEW*) (REQUIRED) Specifies name of the metadata to be matched
            - name: "metadata"
               # (*NEW*) (OPTIONAL) Specifies whether the metadata match condition should be inverted
               invert: true
               # (*NEW*) (OPTIONAL) Specifies the match condition for the metadata value in the request
               match:
                   # (*NEW*) (OPTIONAL) Specifies the exact metadata value to be matched
                   exact: "exact"
                   # (*NEW*) (OPTIONAL) Specifies the prefix of the metadata value to be matched
                   prefix: "prefix"
                   # (*NEW*) (OPTIONAL) Specifies the suffix of the metadata value to be matched
                   suffix: "suffix"
                   # (*NEW*) (OPTIONAL) Specifies the regex the metadata value to match
                   regex: "regex"
                   # (*NEW*) (OPTIONAL) Specifies the range the metadata value to match
                   range:
                      # (*NEW*) (REQUIRED) Specifies the start range of the metadata value
                       start: 0
                      # (*NEW*) (REQUIRED) Specifies the end range of the metadata value
                       end: 10
   # Existing field
    action:
      ...

Example
Here is an example of a mesh with 2 internal services having different hostnames - foo.example.com, bar.example.com and the Virtual Gateway is configured to send traffic to the appropriate Virtual Service based on the hostname in the request.

export CERTIFICATE_ARN =`aws acm request-certificate \
    --domain-name example.com \
    --subject-alternative-names *.example.com \
    --certificate-authority-arn ${ROOT_CA_ARN} \
    --query CertificateArn --output text`
----
kind: VirtualGateway
metadata:
  name: SampleVirtualGateway
  ..
spec:
  - listeners:
     portMapping:
        port: 9080
        protocol: http
     tls:
        mode: STRICT
        certificate:
          acm:
            certificateArn: $CERTIFICATE_ARN
---
kind: GatewayRoute
metadata:
 name: SampleGatewayRoute1
 ..
spec:
  httpRoute:
    match:
      hostname:
        exact: "foo.example.com"
      prefix: "/"
    action:
      target:
        virtualServiceRef:
            name: foo.example.com
---
kind: GatewayRoute
metadata:
 name: SampleGatewayRoute2
 ..
spec:
  httpRoute:
    match:
      hostname:
        exact: "bar.example.com"
      prefix: "/"
    action:
      target:
        virtualServiceRef:
            name: bar.example.com

We hope these changes fit your use cases. We'll be updating this issue once we have the feature enabled in our Preview Channel. Until then, we'd love to hear your feedback on this proposal in the comments.

Thanks!

[blackey-mitek]

Excellent! this fits our intentions exactly.

On Feb 5, 2021, at 1:31 AM, Rajal <[email protected][e-mail]> wrote:

Hey all,
We are adding the following fields in Gateway Routehttps://docs.aws.amazon.com/app-mesh/latest/userguide/gateway-routes.html in order to support matching on headers and hostnames at Virtual Gateway:

• Hostname field: This will be used to specify the hostname that should be matched on the incoming request to route to the target Virtual Service.
• Headers/metadata field: This will be used to specify the headers (for HTTP & HTTP2)/metadata (for GRPC) that should be matched on the incoming request to route to the target Virtual Service.
• Method field for HTTP/HTTP2 Routes: This will be used to specify the method header to be matched in the incoming HTTP/HTTP2 requests.
• Priority field: This will be used to specify the ordering of the Gateway routes.

Note that the Virtual Gateway supports specifying a single TLS settings (for both TLS termination and Client TLS validation) and that TLS settings would be applied for all the traffic with multiple hostnames. Support for vending different server certificates based on the SNI in the incoming request is being tracked herehttps://github.com/aws/aws-app-mesh-roadmap/issues/311

API model
Following represents the updated API model for HTTP Gateway Routes. HTTP2 Gateway Routes would follow similar model changes.

kind: GatewayRoute
spec:
# (NEW) (OPTIONAL) Specifies ordering of Gateway routes. 0 being the highest priority
priority: 0
http:
match:
prefix: "/" #Existing field.
# (NEW) (OPTIONAL) Specifies Method to match in the incoming request
method: "GET"
# (NEW) (OPTIONAL) Specifies hostname to be matched in the request
hostname:
# (NEW) (OPTIONAL) Specifies the exact hostname to be matched in the request
exact: "example.comhttp://example.com"
# (NEW) (OPTIONAL) Specifies the suffix hostname to be matched in the request
suffix: ".example.comhttp://example.com" # Optional field
# (NEW) (OPTIONAL) Specifies list of headers to be matched in the request. When multiple headers are specified, AND of conditions would be applied.
headers:
# (NEW) (REQUIRED) Specifies name of the header to be matched
- name: "header"
# (NEW) (OPTIONAL) Specifies whether the header match condition should be inverted
invert: true
# (NEW) (OPTIONAL) Specifies the match condition for the header value in the request
match:
# (NEW) (OPTIONAL) Specifies the exact header value to be matched
exact: "exact"
# (NEW) (OPTIONAL) Specifies the prefix of the header value to be matched
prefix: "prefix"
# (NEW) (OPTIONAL) Specifies the suffix of the header value to be matched
suffix: "suffix"
# (NEW) (OPTIONAL) Specifies the regex the header value to match
regex: "regex"
# (NEW) (OPTIONAL) Specifies the range the header value to match
range:
# (NEW) (REQUIRED) Specifies the start range of the header value
start: 0
# (NEW) (REQUIRED) Specifies the end range of the header value
end: 10
# Existing field
action:
...

Following represents the updated API model for GRPC Gateway Routes

kind: GatewayRoute
spec:
# (NEW) (OPTIONAL) Specifies ordering of Gateway routes. 0 being the highest priority
priority: 0
grpc:
match:
serviceName: "service" #Existing field.
# (NEW) (OPTIONAL) Specifies hostname to be matched in the request
hostname:
# (NEW) (OPTIONAL) Specifies the exact hostname to be matched in the request
exact: "example.comhttp://example.com"
# (NEW) (OPTIONAL) Specifies the suffix hostname to be matched in the request
suffix: ".example.comhttp://example.com" # Optional field
# (NEW) (OPTIONAL) Specifies list of metadata to be matched in the request. When multiple metadata are specified, AND of conditions would be applied.
metadata:
# (NEW) (REQUIRED) Specifies name of the metadata to be matched
- name: "metadata"
# (NEW) (OPTIONAL) Specifies whether the metadata match condition should be inverted
invert: true
# (NEW) (OPTIONAL) Specifies the match condition for the metadata value in the request
match:
# (NEW) (OPTIONAL) Specifies the exact metadata value to be matched
exact: "exact"
# (NEW) (OPTIONAL) Specifies the prefix of the metadata value to be matched
prefix: "prefix"
# (NEW) (OPTIONAL) Specifies the suffix of the metadata value to be matched
suffix: "suffix"
# (NEW) (OPTIONAL) Specifies the regex the metadata value to match
regex: "regex"
# (NEW) (OPTIONAL) Specifies the range the metadata value to match
range:
# (NEW) (REQUIRED) Specifies the start range of the metadata value
start: 0
# (NEW) (REQUIRED) Specifies the end range of the metadata value
end: 10
# Existing field
action:
...

Example
Here is an example of a mesh with 2 internal services having different hostnames - foo.example.comhttp://foo.example.com, bar.example.comhttp://bar.example.com and the Virtual Gateway is configured to send traffic to the appropriate Virtual Service based on the hostname in the request.

---

export CERTIFICATE_ARN =`aws acm request-certificate \
--domain-name example.comhttp://example.com \
--subject-alternative-names *.example.comhttp://example.com \
--certificate-authority-arn ${ROOT_CA_ARN} \

--query CertificateArn --output text`

kind: VirtualGateway
metadata:
name: SampleVirtualGateway
..
spec:

• listeners:
  portMapping:
  port: 9080
  protocol: http
  tls:
  mode: STRICT
  certificate:
  acm:

certificateArn: $CERTIFICATE_ARN

kind: GatewayRoute
metadata:
name: SampleGatewayRoute1
..
spec:
http:
match:
hostname:
exact: "foo.example.comhttp://foo.example.com"
prefix: "/"
action:
target:
virtualServiceRef:

name: foo.example.comhttp://foo.example.com

kind: GatewayRoute
metadata:
name: SampleGatewayRoute2
..
spec:
http:
match:
hostname:
exact: "bar.example.comhttp://bar.example.com"
prefix: "/"
action:
target:
virtualServiceRef:
name: bar.example.comhttp://bar.example.com

We hope these changes fit your use cases. We'll be updating this issue once we have the feature enabled in our Preview Channelhttps://docs.aws.amazon.com/app-mesh/latest/userguide/preview.html. Until then, we'd love to hear your feedback on this proposal in the comments.

Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/aws/aws-app-mesh-roadmap/issues/232#issuecomment-773911979, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJNMHYWRRLK7BNYS77FSKH3S5O3GLANCNFSM4O4XL5XQ.

[misterjoshua]

Hey all,
We are adding the following fields in Gateway Route in order to support matching on headers and hostnames at Virtual Gateway:

• Hostname field: This will be used to specify the hostname that should be matched on the incoming request to route to the target Virtual Service.
• Headers/metadata field: This will be used to specify the headers (for HTTP & HTTP2)/metadata (for GRPC) that should be matched on the incoming request to route to the target Virtual Service.
• Method field for HTTP/HTTP2 Routes: This will be used to specify the method header to be matched in the incoming HTTP/HTTP2 requests.
• Priority field: This will be used to specify the ordering of the Gateway routes.

Note that the Virtual Gateway supports specifying a single TLS settings (for both TLS termination and Client TLS validation) and that TLS settings would be applied for all the traffic with multiple hostnames. Support for vending different server certificates based on the SNI in the incoming request is being tracked here

API model
Following represents the updated API model for HTTP Gateway Routes. HTTP2 Gateway Routes would follow similar model changes.

kind: GatewayRoute
spec:
  # (NEW) (OPTIONAL) Specifies ordering of Gateway routes. 0 being the highest priority
  priority: 0
  httpRoute:
    match:
        prefix: "/" #Existing field.
        # (*NEW*) (OPTIONAL) Specifies Method to match in the incoming request
        method: "GET"
        # (*NEW*) (OPTIONAL) Specifies hostname to be matched in the request
        hostname:
            # (*NEW*) (OPTIONAL) Specifies the exact hostname to be matched in the request
            exact: "example.com"
            # (*NEW*) (OPTIONAL) Specifies the suffix hostname to be matched in the request
            suffix: ".example.com" # Optional field
        # (*NEW*) (OPTIONAL) Specifies list of headers to be matched in the request. When multiple headers are specified, **AND** of conditions would be applied.
        headers: 
            # (*NEW*) (REQUIRED) Specifies name of the header to be matched
            - name: "header"
               # (*NEW*) (OPTIONAL) Specifies whether the header match condition should be inverted
               invert: true
               # (*NEW*) (OPTIONAL) Specifies the match condition for the header value in the request
               match:
                   # (*NEW*) (OPTIONAL) Specifies the exact header value to be matched
                   exact: "exact"
                   # (*NEW*) (OPTIONAL) Specifies the prefix of the header value to be matched
                   prefix: "prefix"
                   # (*NEW*) (OPTIONAL) Specifies the suffix of the header value to be matched
                   suffix: "suffix"
                   # (*NEW*) (OPTIONAL) Specifies the regex the header value to match
                   regex: "regex"
                   # (*NEW*) (OPTIONAL) Specifies the range the header value to match
                   range:
                      # (*NEW*) (REQUIRED) Specifies the start range of the header value
                       start: 0
                      # (*NEW*) (REQUIRED) Specifies the end range of the header value
                       end: 10
   # Existing field
    action:
      ...

Following represents the updated API model for GRPC Gateway Routes

kind: GatewayRoute
spec:
  # (*NEW*) (OPTIONAL) Specifies ordering of Gateway routes. 0 being the highest priority
  priority: 0
  grpcRoute:
    match:
        serviceName: "service" #Existing field.
        # (*NEW*) (OPTIONAL) Specifies hostname to be matched in the request
        hostname:
            # (*NEW*) (OPTIONAL) Specifies the exact hostname to be matched in the request
            exact: "example.com"
            # (*NEW*) (OPTIONAL) Specifies the suffix hostname to be matched in the request
            suffix: ".example.com" # Optional field
        # (*NEW*) (OPTIONAL) Specifies list of metadata to be matched in the request. When multiple metadata are specified, **AND** of conditions would be applied.
        metadata: 
            # (*NEW*) (REQUIRED) Specifies name of the metadata to be matched
            - name: "metadata"
               # (*NEW*) (OPTIONAL) Specifies whether the metadata match condition should be inverted
               invert: true
               # (*NEW*) (OPTIONAL) Specifies the match condition for the metadata value in the request
               match:
                   # (*NEW*) (OPTIONAL) Specifies the exact metadata value to be matched
                   exact: "exact"
                   # (*NEW*) (OPTIONAL) Specifies the prefix of the metadata value to be matched
                   prefix: "prefix"
                   # (*NEW*) (OPTIONAL) Specifies the suffix of the metadata value to be matched
                   suffix: "suffix"
                   # (*NEW*) (OPTIONAL) Specifies the regex the metadata value to match
                   regex: "regex"
                   # (*NEW*) (OPTIONAL) Specifies the range the metadata value to match
                   range:
                      # (*NEW*) (REQUIRED) Specifies the start range of the metadata value
                       start: 0
                      # (*NEW*) (REQUIRED) Specifies the end range of the metadata value
                       end: 10
   # Existing field
    action:
      ...

Example
Here is an example of a mesh with 2 internal services having different hostnames - foo.example.com, bar.example.com and the Virtual Gateway is configured to send traffic to the appropriate Virtual Service based on the hostname in the request.

export CERTIFICATE_ARN =`aws acm request-certificate \
    --domain-name example.com \
    --subject-alternative-names *.example.com \
    --certificate-authority-arn ${ROOT_CA_ARN} \
    --query CertificateArn --output text`
----
kind: VirtualGateway
metadata:
  name: SampleVirtualGateway
  ..
spec:
  - listeners:
     portMapping:
        port: 9080
        protocol: http
     tls:
        mode: STRICT
        certificate:
          acm:
            certificateArn: $CERTIFICATE_ARN
---
kind: GatewayRoute
metadata:
 name: SampleGatewayRoute1
 ..
spec:
  httpRoute:
    match:
      hostname:
        exact: "foo.example.com"
      prefix: "/"
    action:
      target:
        virtualServiceRef:
            name: foo.example.com
---
kind: GatewayRoute
metadata:
 name: SampleGatewayRoute2
 ..
spec:
  httpRoute:
    match:
      hostname:
        exact: "bar.example.com"
      prefix: "/"
    action:
      target:
        virtualServiceRef:
            name: bar.example.com

We hope these changes fit your use cases. We'll be updating this issue once we have the feature enabled in our Preview Channel. Until then, we'd love to hear your feedback on this proposal in the comments.

Thanks!

Thanks for adding this! Will this be available in CloudFormation for use in ECS?

[rajal-amzn]

@misterjoshua We are currently working on implementing this proposal. When the feature is released in GA, you can use it via all methods including Cloudformation.

[vodwood]

Good afternoon.
Is there perhaps a ballpark estimation of delivery date to GA?

[debu99]

any progress?

[RafalMaleska]

i think that this is the most awaited feature :) i have few teams waiting for this as well :)

would be nice to have the ability to use something similar like kubernetes ingress resources:
https://kubernetes.io/docs/concepts/services-networking/ingress/

[rishijatia]

Hi everyone,

Header and Hostname Matching support is now available in the App Mesh Preview Channel.

Feel free to try out the example from our examples repository: howto-match-and-rewrite-at-ingress.

[rajal-amzn]

Hey all,
Thanks to everyone for your feedback. Routing enhancements at Ingress are now generally available. Check out this blog post for more details: https://aws.amazon.com/about-aws/whats-new/2021/06/aws-app-mesh-introduces-enhanced-ingress-traffic-management-capabilities/

NOTE: Cloudformation support for this is yet to be launched. We will update this issue once it is done.

[moserke]

Will the docs be updated soon? This PR is the only place I have found, other than reading the code, that show what the new fields are.

But also thank you for this change! Is great to have!

[rajal-amzn]

@moserke The docs are now updated as well. Thanks.

[rajal-amzn]

Cloudformation changes are now live.