Ambassador: Filter and FilterPolicy not able to match requests

[QuanNham-GBI]

Describe the bug
Filter and FilterPolicy objects created to pass requests through an External authentication service in my cluster are unable to match requests regardless of host or path rules specified. The request simply goes through to the service without any authentication being performed.

To Reproduce
A simple http echo app was deployed to a test namespace named ingestion-test, and instances of the authentication service was deployed to a separate authentication namespace. Ambassador Edge Stack was deployed to a separate ambassador namespace, with the mappings being created there as well. The authentication service has been proven to work through a dedicated mapping to it. The Filter, FilterPolicy, and Mapping objects are as follows:

apiVersion: getambassador.io/v2
kind: Filter
metadata:
  name: auth-service-filter
  namespace: ambassador
spec:
  External:
    allowed_request_headers:
    - customerId
    auth_service: http://authentication.authentication:8080
    failure_mode_allow: false
    path_prefix: /gateway
    status_on_error:
      code: 401
    timeout_ms: 2000
---
apiVersion: getambassador.io/v2
kind: FilterPolicy
metadata:
  name: ingestion-api-filter-policy
  namespace: ambassador
spec:
  rules:
  - filters:
    - name: auth-service-filter
      namespace: ambassador
    host: '*'
    path: /ingestion/v1/*
---
apiVersion: getambassador.io/v2
kind: Mapping
metadata:
  name: ingestion-echo
  namespace: ambassador
spec:
  host: ^.*(.qa|.dev|.prod)?.domain.com
  host_regex: true
  prefix: /ingestion/v1
  rewrite: /ingestion/v1/api
  service: http://echo.ingestion-test:80
  timeout_ms: 300000

Expected behavior
The request to the app should return an Authorization header with a JWT bearer token as the value.

Versions:

• Ambassador Edge Stack v1.5.3
• GKE 1.16.9-gke.2

Additional context
I've tried to create other Filter and FilterPolicy objects in my cluster, including one that utilizes OAuth2 via Google, and I see the same behaviour with the request going through without authentication. Additionally, I was able to get the expected behaviour but only when using the AuthService object, which was recommended not to be used with AES.

[nbkrause]

@QuanNham-GBI Thanks for filing this bug report.

Taking a look at your report, I believe there is some confusion over how Mapping and the FilterPolicy match the path.

The FilterPolicy is doing glob matching of the entire path. You have this correctly configured with the * at the end of your path.

The Mapping is matching a URL prefix. So any request that starts with /ingestion/v1 will match that Mapping.

As it is configured, your FilterPolicy will catch requests with prefix /ingestion/v1/.Looking at your Mapping, the prefix is set to /ingestion/v1.

Taking a look at the set of matches for this combination, you will see that since the FilterPolicy matches include a trailing / where the Mapping matches do not. So, a request to https://example.com/ingestion/v1 will correctly be routed to the service but will not match any FilterPolicy rules. At request to https://example.com/ingestion/v1/ will match both.

I believe you should change your FIlterPolicy to path: /ingestion/v1* to match the Mapping prefix you are using.

[JamesPace-GBI]

Hi @nbkrause thanks for following this up.

I tried the suggestion of changing the FilterPolicy prefix to /ingestion/v1* with no success. The FilterPolicy still doesn't match the request. I also tried the following globs:

• /ingestion/v1* (your suggestion)
• /ingestion/v1**
• /ingestion/v1**/*
• /ingestion/v1/* (the original)
• /ingestion/v1/**
• /ingestion/v1/**/*

I also tried the globs with the /ingestion/v1/api (note api) as this is part of the rewrite of the mapping, and I'm not sure if the filter policy would try matching before or after the rewrite happens.

[archerz]

@nbkrause After trying lots of different options, we have come to believe that this is likely a bug. If it helps accelerating things, we can probably try to replicate the situation it in a Kind (K8s in Docker) cluster so that the Ambassador team can easily reproduce it.

[CodechCFA]

Having the same issue. Tried a lot of different permutations of configuration here. Ambassador is completely ignoring my filter/filterpolicy.

[richarddli]

@CodechCFA @archerz If you could post a reproducer, that would be very helpful.

[CodechCFA]

The issue was that I had set the AES helm chart to not deploy the AuthService because the docs say not to use an AuthService in AES and to instead use filter/filterpolicy. I was unaware that AES installs its own AuthService, which filter/filterpolicy relies on. After turning that on everything is working.

[galicantensoft]

@CodechCFA can you point me into documentation or explain what did you turn on and how ?
Thx
Edit: nvm i found problem. wrong aes docker image in helm chart values

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.