Skip to content

feat: Add support for header in rule matching #820

@a-manraj-pvotal

Description

@a-manraj-pvotal

Preflight checklist

Context and scope

We are generating from proto and internal configs versioned oathkeeper rules.
Protobufv3 generates the code references from an :authority and :path perspective preventing us from modifying it.
We are passing a version in a header to route to a specific version of a microservice with the autogenerated rule.
As it stands oathkeeper is unaware of the specific header and the rules are not version specific and collide with one another.

Therefore we suggest leverage not only the URL for the oathkeeper rule but also a header for routing and security rules to be unique and apply correctly when a new rule version is generated.
This can also happen if headers are used internally in REST for routing.

Goals and non-goals

We suggest adding an additional optional header configuration to the rule matching to become unique in Oathkeeper and Oathkeeper maester's configuration from a combination of URL and specific header containing possibly the service version.

The design

Modify api/decision.go, matcher.go and rule.go to take into account the optional new header for oathkeeper rule unicity.
Modify the documentation and tests to clearly account for the new option.

APIs

No response

Data storage

No response

Code and pseudo-code

No response

Degree of constraint

No response

Alternatives considered

The alternative in REST would be to add the version into the URL, this solution can't be used when generating the :authority and :path in HTTP2/HTTP3 as it is controlled by the proto generation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    rfcA request for comments to discuss and share ideas.staleFeedback from one or more authors is required to proceed.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions