Refactor pluginconfig

[adam-cattermole]

Changes

• Moved the domain field into the actions and renamed scope. This is the host for auth ContextExtensions and domain for ratelimit
• Started using the data field in the actions and removed the data field in rules

Example:

---
extensions:
  limitador:
    type: ratelimit
    endpoint: limitador-cluster
    failureMode: deny
policies:
  - name: rlp-ns-A/rlp-name-A
    hostnames:
      - '*.toystore.com'
      - example.com
    rules:
      - conditions:
          - selector: request.path
            operator: eq
            value: /admin/toy
          - selector: request.method
            operator: eq
            value: POST
          - selector: request.host
            operator: eq
            value: cars.toystore.com
    actions:
      - extension: limitador
        scope: rlp-ns-A/rlp-name-A
        data:
          - static:
              key: rlp-ns-A/rlp-name-A
              value: "1"
          - selector:
              selector: auth.metadata.username

In progress

• Move actions into the rules (merged from @didierofrivia in Refactoring actions #88)
• Store dynamic metadata from auth in the filter_state so it can be retrieved by other actions
• Build the ratelimit descriptors at action time rather than beforehand so we can retrieve aforementioned filter_state

Verification:

Use the new guide in the README to verify multi-action setup:

make build && make local-setup

Port-forward envoy and watch the logs for all services:

kubectl port-forward --namespace default deployment/envoy 8000:8000
kubectl logs -f deployment/envoy
kubectl logs -f deployment/authorino
kubectl logs -f deployment/limitador

Test the authenticated rate limiting:

curl -H "Host: test.a.multi.com" http://127.0.0.1:8000/get -i
# HTTP/1.1 401 Unauthorized

Alice has 5 requests per 10 seconds:

while :; do curl --write-out '%{http_code}\n' --silent --output /dev/null -H "Authorization: APIKEY IAMALICE" -H "Host: test.a.multi.com" http://127.0.0.1:8000/get | grep -E --color "\b(429)\b|$"; sleep 1; done

Bob has 2 requests per 10 seconds:

while :; do curl --write-out '%{http_code}\n' --silent --output /dev/null -H "Authorization: APIKEY IAMBOB" -H "Host: test.a.multi.com" http://127.0.0.1:8000/get | grep -E --color "\b(429)\b|$"; sleep 1; done

[adam-cattermole]

@eguzki preferred retaining the name allOf over conditions here to be explicit that all conditions must apply. I myself am of the opinion that allOf suggests there's an anyOf so I prefer the name conditions, so would like other thoughts

[eguzki]

I think it will eventually (very soon) be called predicates, right @alexsnaps ?

[alexsnaps]

I think whether these are Predicates or PatternExpressions here is orthogonal to @adam-cattermole 's point. I think he wants to keep the field named allOf, which indeed eventually will be something else than PatternExpressions. It would eventually become a cel expression representing a Predicate indeed, tho, as discussed, how that would look like is probably dependent on what work the Kuadrant Operator does with the initial unparsed expression... if it is parsed entirely, we could inject the AST straight into here (more so if there is an easy way to (de)serialize it to yaml, from Go to Rust) or just pass the String around...

[adam-cattermole]

There's an issue with our design here, we've decoupled the rules from the data and actions, which makes some configurations impossible. We likely should nest the actions within the rules - if rule applies, actions performed with relevant data.

Examples:

• Two rules, one for GET one for POST incrementing different limits
• Two rules, one for GET one for POST, where we only perform auth on POST

These two examples are not possible with the current config, as either of the two rules would match, triggering all actions with all of the data.

[eguzki]

related Kuadrant/kuadrant-operator#867

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
13357796	Triggered	Generic High Entropy Secret	91da443	utils/deploy/authconfig.yaml	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[adam-cattermole]

I think we need some follow ups to improve performance here, will look to iterate to make things better.. we're also in need of new integration tests for auth, as well as auth + rl.. but it's working

[didierofrivia]

Great, from here on we can dedicate ourself to do the missing integration tests for auth, multi extension and make it faster/prettier. 💪🏼