Using Oathkeeper to mutate incoming headers using the data from headers

[viters]

Hey, I've recently had a task, and picked Oathkeeper as best place to set up the logic (don't want to go into details of the infrastructure). I had couple of findings out on the way, so I wanted to share them, maybe something would be useful to add to docs.

The task

If the request comes with header X-Force-Webp, set Accept header to image/webp, otherwise leave Accept content or empty if nothing is present.

Enable header mutator

This should be easy, but it had one quirk. To enable it, without global config, you need to pass empty config:

mutators:
  header:
    enabled: true
    config:
      headers: {}

Otherwise, without config: headers: {} it will fail to load. I think it should be written in docs or fixed.

Write the golang template

Working solution:

mutators:
  - handler: header
    config:
      headers:
        Accept: '{{ if gt (len (index .MatchContext.Header "X-Force-Webp")) 0 }}image/webp{{ else if gt (len .MatchContext.Header.Accept) 0 }}{{ print (index .MatchContext.Header.Accept 0) }}{{ end }}'

Here I had some ideas:

.Header vs .MatchContext.Header

My first choice was .Header. Maybe I missed something in docs, but I think it should be mentioned (or some relation link) in every place - where you can choose between them, about the existence and purpose of .MatchContext

Helpers to access / write templates

There is some field for improvement, to foster the readability of those templates - but most crucial, to enhance the performance of those operations.

A helper to reach headers that are unreachable by dot notation (because of dashes, for example) would be useful. Also, because the .Header type is type Header map[string][]string, the value is an array of 0 or 1 elements. It also makes it harder to access specific header, especially for someone not familiar with this templating language (such as me).

---

To summarize, Oathkeeper saved my day, because I was able to complete the task, and that is awesome. I had some minor issues on the way, I think they can be easily fixed by adding more insights to docs. Maybe someone will also find a help here, before we propose any documentation changes.

[aeneasr]

Thabk you @viters for the write up! Our plan is to deprecate go templates and use JsonNet to define these rules in the future, but we have to do some performance testing to ensure it scales :)