ory / oathkeeper-maester

Kuberenetes CRD Controller for Ory Oathkeeper. :warning: Maintained by the community, not an official Ory project!

• Ory Oathkeeper Maester
  • Prerequisites
  • How to use it
  • Command-line parameters
    • Mode options
    • Global flags
    • Controller mode flags
    • Sidecar mode flags
    • Environment variables

Ory Oathkeeper Maester

⚠️ ⚠️ ⚠️

Ory Oathkeeper Maester is developed by the Ory community and is not actively maintained by Ory core maintainers due to lack of resources, time, and knolwedge. As such please be aware that there might be issues with the system. If you have ideas for better testing and development principles please open an issue or PR!

⚠️ ⚠️ ⚠️

ORY Maester is a Kubernetes controller that watches for instances of rules.oathkeeper.ory.sh/v1alpha1 custom resource (CR) and creates or updates the Oathkeeper ConfigMap with Access Rules found in the CRs. The controller passes the Access Rules as an array in a format recognized by the Oathkeeper.

The project is based on Kubebuilder

Prerequisites

• recent version of Go language with support for modules (e.g: 1.12.6)
• make
• kubectl
• kustomize
• kind for local integration testing
• ginkgo for local integration testing
• access to K8s environment: minikube or KIND (https://github.com/kubernetes-sigs/kind), or a remote K8s cluster

How to use it

• make to build the binary
• make test to run tests
• make test-integration to run integration tests with local KIND environment

Other targets require a working K8s environment. Set KUBECONFIG environment variable to the proper value.

• make install to generate CRD file from go sources and install it in the cluster
• make run to run controller locally

Refer to the Makefile for the details.

Command-line parameters

Usage example: ./manager [--global-flags] mode [--mode-flags]

Mode options

Name	Description
controller	This is the default mode of operation, in which oathkeeper-maester is expected to be deployed as a separate deployment. It uses the kubernetes api-server and ConfigMaps to store data.
sidecar	Alternative mode of operation, in which the oathkeeper-maester is expected to be deployed as a sidecar container to the main application. It uses local filesystem to create the access rules file.

Global flags

Name	Description	Default values
metrics-addr	The address the metric endpoint binds to	8080
enable-leader-election	Enable leader election for controller manager. Enabling this will ensure there is only one active controller manager.	false
kubeconfig	Paths to a kubeconfig. Only required if out-of-cluster.	$KUBECONFIG

Controller mode flags

Name	Description	Default values
rulesConfigmapName	Name of the Configmap that stores Oathkeeper rules.	oathkeeper-rules
rulesConfigmapNamespace	Namespace of the Configmap that stores Oathkeeper rules.	oathkeeper-maester-system
rulesFileName	Name of the key in ConfigMap containing the rules.json	access-rules.json

Sidecar mode flags

Name	Description	Default values
rulesFilePath	Path to the file with converted Oathkeeper rules	/etc/config/access-rules.json

Environment variables

Name	Description	Default values
NAMESPACE	Namespace option to scope Oathkeeper maester to one namespace only - useful for running several instances in one cluster. Defaults to "" which means that there is no namespace scope.	``

oathkeeper-maester's Issues

Inconsistancy with upstream.strip_path

Describe the bug

There is an inconstancy within the CRD when defining upstream.strip_path.

The Ory Oathkeeper documentation, and some references within the CRD uses snake case strip_path , however the CRD expects this to be camel case stripPath.

Snake Case references:
Documentation
Rule_type_tests.go
Rule_json.go

Camel case reference
rule_types.go

Expected behavior

The CRD should ideally match that of the Ory documentation for a standard rule outside of the CRD, as snake case strip_path

Environment
CRD version: v1alpha1

I would contribute a PR for this, but aware that it'll be a breaking change for those who have already implemented as stripPath, so not sure how best to action this.

Add support to errors handlers

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• This issue affects my Ory Network project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Context and scope

Applying the maester in my Ory network I noticed that error handlers are not currently supported.
This blocked me to implement oathkeeper-maester.

Error Handlers | Ory: https://www.ory.sh/docs/oathkeeper/pipeline/error

Goals and non-goals

goals:

• ability to maester to support error handlers

non-goals:

• nothing to mention

The design

By design, oathkeeper provides support to error handlers, which are responsible for executing logic after, for example, authentication or authorization failed.

The error handlers definition will follow the same structure of other handlers (authenticators, authorizers and mutators).

APIs

No response

Data storage

No response

Code and pseudo-code

No response

Degree of constraint

No response

Alternatives considered

No response

<.*> becomes \u003c.*\u003e

I don't fully understand the issue, but what I gather is that when I add a Kubernetes resource that uses <.*> it becomes \u003c.*\u003e. Also in oathkeeper-rules secret.

I think this is caused by Kubernetes.

• Is there something I can do to fix my issue? Escaping?
• Is this something that oathkeeper-maester should decode?
• Should oathkeeper use (.*) instead, like we are used to – will that even fix the problem?

Am I missing something?

Steps to reproduce

0. Run Oathkeeper (v0.32.0-beta.1+oryOS.12) and Oathkeeper-maester (v0.0.5)
1. Add a Kubernetes resource that has a URL containing a regex string. eg.: https://google.com/<.*>.
2. Check output of oathkeeper rules list

Resources

These are my examples.

kubectl get rules account-role-test -o json

{
    "apiVersion": "oathkeeper.ory.sh/v1alpha1",
    "kind": "Rule",
    "metadata": {
        "annotations": {
            "kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"oathkeeper.ory.sh/v1alpha1\",\"kind\":\"Rule\",\"metadata\":{\"annotations\":{},\"creationTimestamp\":\"2020-02-15T16:21:55Z\",\"finalizers\":[\"finalizer.oathkeeper.ory.sh\"],\"generation\":2,\"labels\":{\"app.kubernetes.io/managed-by\":\"pulumi\"},\"name\":\"account-role-test\",\"namespace\":\"default\",\"resourceVersion\":\"30389400\",\"selfLink\":\"/apis/oathkeeper.ory.sh/v1alpha1/namespaces/default/rules/account-role\",\"uid\":\"47fa5bb7-500f-11ea-9339-42010a840075\"},\"spec\":{\"authenticators\":[{\"handler\":\"noop\"}],\"authorizer\":{\"handler\":\"allow\"},\"match\":{\"methods\":[\"POST\",\"GET\",\"OPTION\"],\"url\":\"http://account.dev.v1.oslobf.app/\\u003c.*\\u003e\"},\"mutators\":[{\"handler\":\"noop\"}],\"upstream\":{\"url\":\"https://account.dev.v1.oslobf.app\"}},\"status\":{\"validation\":{\"valid\":true}}}\n"
        },
        "creationTimestamp": "2020-02-15T16:33:02Z",
        "finalizers": [
            "finalizer.oathkeeper.ory.sh"
        ],
        "generation": 1,
        "labels": {
            "app.kubernetes.io/managed-by": "pulumi"
        },
        "name": "account-role-test",
        "namespace": "default",
        "resourceVersion": "30392595",
        "selfLink": "/apis/oathkeeper.ory.sh/v1alpha1/namespaces/default/rules/account-role-test",
        "uid": "d5e76516-5010-11ea-9339-42010a840075"
    },
    "spec": {
        "authenticators": [
            {
                "handler": "noop"
            }
        ],
        "authorizer": {
            "handler": "allow"
        },
        "match": {
            "methods": [
                "POST",
                "GET",
                "OPTION"
            ],
            "url": "http://account.dev.v1.oslobf.app/\u003c.*\u003e"
        },
        "mutators": [
            {
                "handler": "noop"
            }
        ],
        "upstream": {
            "url": "https://account.dev.v1.oslobf.app"
        }
    },
    "status": {
        "validation": {
            "valid": true
        }
    }
}

oathkeeper rules list

{
		"authenticators": [
			{
				"handler": "noop"
			}
		],
		"id": "account-role-test.default",
		"mutators": [
			{
				"handler": "noop"
			}
		],
		"authorizer": {
			"handler": "allow"
		},
		"match": {
			"methods": [
				"POST",
				"GET",
				"OPTION"
			],
			"url": "http://account.dev.v1.oslobf.app/\u003c.*\u003e"
		},
		"upstream": {
			"url": "https://account.dev.v1.oslobf.app"
		}
	}

High memory consumption in clusters with many ConfigMaps

Kind:
Bug

Description:
The controller allocates a lot of memory in clusters with many ConfigMaps. In a cluster with over 5000 ConfigMaps, the controller allocated over 750MiB of memory.

Reason:
Invalid bootstrap code that allocates watcher/lister for ConfigMap objects.

Expected behavior:
The amount of memory the controller allocates does not depend on the number of ConfigMap objects.

Run integration tests on CI

Currently integration test are not triggered on circle CI. There was a problem running KIND in docker. We need to enable it in order to have continuous testing

Validate access rules against JSON Schema from Oathkeeper Upstream

Right now there is some manual validation of access rules (their handlers etc) in the controller. This should instead be using a JSON Schema from upstream!

Helm charts for the controller

Description

We need to have helm chart for oathkeeper controller in order to easily deploy it in the k8s env.

There is already repo for ory eco system helm charts here https://github.com/ory/k8s/tree/master/helm so it can be placed there.

For sure from k8s POV we need to have

• Deployment
• Service
• Service account
• RBAC
• plus helm additional files like README, notes etc. ;-)
• Set also memory requests for the component

Reasons

Quick adoption in k8s envs, no need to create deployments by your own

Provide ARM Docker Image

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• This issue affects my Ory Network project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Describe your problem

I try to deploy the oathkeeper helm chart to a Kubernetes cluster running on arm64 hardware. The oathkeeper-maester pod fails with: exec /manager: exec format error. The docker image only supports amd64.

Describe your ideal solution

The other ory docker images are built for arm. It would be nice if oathkeeper-maester would support arm docker images too.

Workarounds or alternatives

I have removed the GOARCH from the Makefile and build a arm version of the image with:

docker buildx build --platform=linux/arm64 --tag ghcr.io/yoo/oathkeeper-maester:latest --push .

You can try the image yourself. https://github.com/users/yoo/packages/container/package/oathkeeper-maester

Version

0.1.7

Additional Context

No response

New authorizers remote and remote_json not in default config

Hi,

I believe that new authorizers (remote and remote_json) implemented in oathkeeper (v0.38.0) are not part of default configuration defaultAuthorizersAvailable (https://github.com/ory/oathkeeper-maester/blob/master/main.go#L42).

Without these default values, the validation of the resource fails (being valid).

There is a workaround for this problem and is to use the authorizersAvailable environment variable and set the value to: "allow,deny,remote". This works but I believe that those default values should be included in master.

Thanks for the work team!

Upgrade `gopkg.in/yaml.v3` to latest stable version

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe the bug

Addresses 1 high CVE
https://www.cve.org/CVERecord?id=CVE-2022-28948

and a high scoring CVSS
https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:P

Reproducing the bug

N/A

Relevant log output

No response

Relevant configuration

No response

Version

v0.1.9

On which operating system are you observing this issue?

None

In which environment are you deploying?

None

Additional Context

No response

Add leader election flag to the controller

In the "controller" mode, leader election should be enabled by adding --enable-leader-election=true flag.
At the moment it's not possible, because this flag causes internal logger to produce log entries - see: #34

Controller crashes because logger can't create file

Kind:
Bug

Description:
The controller crashes with a message: log: exiting because of error: log: cannot create log: open /tmp/manager.oathkeeper-maester-858d5476f6-rgj52.unknownuser.log.INFO.20191212-121706.1: no such file or directory
The internal K8s logger, klog, is configured to write to file. It is usually silent, but it's triggered sometimes.

Expected behavior:
The internal logger is configured to write to stderr.

How to reproduce:
enable leader election when running the controller, this triggers the logger.

Bump golang version to at least 1.15.5 to fix CVEs

Is your feature request related to a problem? Please describe.

There is a CVE-2020-28362 with a rating high
"Go before 1.14.12 and 1.15.x before 1.15.4 allows Denial of Service. "

More info here and here

Describe the solution you'd like

The build scripts should use golang image >= 1.15.4

The field 'upstream' should not be required

Currently, it is not possible to apply a Rule without the upstream field being set, this does not reflect what is mentioned in the documentation:

The location of the server where requests matching this rule should be forwarded to. This only needs to be set when using the ORY Oathkeeper Proxy as the Decision API does not forward the request to the upstream.

Error: The Rule "xyz" is invalid: spec.upstream: Required value

https://github.com/ory/oathkeeper-maester/blob/master/config/crd/bases/oathkeeper.ory.sh_rules.yaml#L131

Broken handling of rules across namespaces

Kind:
Bug

Description:
The issue is caused by changes introduced in #30
Before then, the controller was fetching all Rules from the cluster on every run of the reconcile loop. Based on the result, ConfigMap payload was generated.

PR #30 changed that so that only Rules from the same namespace as the "triggering" event (a change to some Rule) are processed. This leads to removal of Rules from ConfigMap in scenarios where Rules from few namespaces are expected to exist in a single ConfigMap

How to reproduce:
Assumption: Rules are not using new CRD field configMapName, a common ConfigMap configured using argument --rulesConfigmapName is used.

• Person A adds five rules to namespace A
• Controller reconcile loop is triggered five times
• On every run of the reconcile loop the controller fetches all Rules from namespace A and replaces ConfigMap payload with the list.
• On the last pass, the controller finds a list of five Rules
• The controller replaces the payload of common ConfigMap with the five rules from namespace A.
• Person B adds three new rules to namespace B
• Controller reconcile loop is triggered three times
• On every run of the reconcile loop the controller fetches all Rules from namespace B and replaces ConfigMap payload with the list.
• On the last pass, the controller finds a list of three Rules
• The controller replaces the payload of common ConfigMap with the three rules from namespace B.
• Rules from namespace A are missing from ConfigMap, although they were present few seconds ago and they still exist in the cluster (the real problem, broken contract)

If Person A and B work in parallel (interleaved), the result will be that the ConfigMap contents will change completely frequently (blinking), "the last wins".

How to fix it
The contract established before #30 should be still supported.

• For rules without explicit configMapName field, we should fetch rules from all namespaces, as before. Restricting these to a "triggering" namespace leads to the "blinking" problem described above

• Rules with explicit configMapName from different namespaces will end up in ConfigMaps created in respective namespaces, no "blinking" occurs, so this scenario looks OK.

Rewrite integration tests to stretchr/testify

The tests in tests/integration directory are written with Ginkgo, because it's a default choice for kubebuilder-based projects.
To be consistent with other projects in ORY repository we should use just go testing package with stretchr/testify assertions.
Pay attention to correct cleanup handling (namespace delete).

Define CRD representing access rule

Description

Kubernetes controllers react on CR which requires CRD to be definied. As we want to create a k8s controller that will server access rules for oathkeeper based on registered rules via CR, we need to first define the CRD.

Custom resource should reflect access rule API see here. It may reflect the schema of access rule but perhaps can be simplified.

Reasons

CRD is required for the controller to run. It is also a contract.

Setup CI/CD

Description

As we want to create controller we need a CI/CD for that. We should be able to test and build component we develop. @aeneasr is it possible to intgerate this project with your exisiting setup?

Error handlers & matches not supported

Description

Oathkeeper supports error handlers with for example redirect. This property is not supported in the controller but for some users this feature is desired. The same goes with error matches

Rule Spec does not have those properties https://github.com/ory/oathkeeper-maester/blob/master/api/v1alpha1/rule_types.go#L59 and CRD needs to be updated as well.

Access rule update silently fails

Oathkeeper maester should be more careful when it comes to applying incorrect access rules.

I have used by mistake the NOOP handler under authorizers and the access rule got successfully applied to k8s, yet it did not work. After searching for errors, I've found in the maester log an INFO line, which made it seem everything was alright and the access rule was applied with the erroneous part ignored.

>>> kubectl logs oathkeeper-maester-6cfcff4b-62qmq -f
2021-01-11T17:58:17.557Z        INFO    setup   running in controller mode
2021-01-11T17:58:19.025Z        INFO    controller-runtime.metrics      metrics server is starting to listen    {"addr": "0.0.0.0:8080"}
2021-01-11T17:58:19.026Z        INFO    setup   using default values for authenticatorsAvailable
2021-01-11T17:58:19.026Z        INFO    setup   using default values for authorizersAvailable
2021-01-11T17:58:19.026Z        INFO    setup   using default values for mutatorsAvailable
2021-01-11T17:58:19.026Z        INFO    setup   starting manager
2021-01-11T17:58:19.027Z        INFO    controller-runtime.manager      starting metrics server {"path": "/metrics"}
2021-01-11T17:58:19.027Z        INFO    controller-runtime.controller   Starting EventSource    {"controller": "rule", "source": "kind source: /, Kind="}
2021-01-11T17:58:19.144Z        INFO    controller-runtime.controller   Starting Controller     {"controller": "rule"}
2021-01-11T17:58:19.144Z        INFO    controller-runtime.controller   Starting workers        {"controller": "rule", "worker count": 1}
2021-01-11T17:58:19.147Z        INFO    controllers.Rule        validation error in Rule ory-auth/ory-auth: "invalid handlers: [authorizer/noop], please check the configuration"
2021-01-11T17:58:19.260Z        INFO    controllers.Rule        updating ConfigMap
2021-01-11T17:58:19.264Z        DEBUG   controller-runtime.controller   Successfully Reconciled {"controller": "rule", "name": "ory-auth", "namespace": "ory-auth"}

However the config map for the access rules was empty. After I've changed the NOOP handler to ALLOW, the maester service returned the exactly same lines of logs, but this time correctly filled out the config map:

2021-01-11T19:38:57.817Z        INFO    controllers.Rule        updating ConfigMap
2021-01-11T19:38:57.827Z        DEBUG   controller-runtime.controller   Successfully Reconciled {"controller": "rule", "name": "ory-auth", "namespace": "ory-auth"}

Maester logging shoud be fixed to throw an ERROR in such cases, to show an incorrect access rule CR is trying to be applied (and it fails)

Sidecar mode - write access rules to file

Description

We should be able to run controller in the sidecar mode, saving provided access rules to file. In this mode controller is running as a second container in the pod.

Current workflow with integration via configmap works but is slow (refresh time).
Mode should be enabled via config and it should be a generic implementation : interface with different implementations (one for configmap one for file)

AC :

• Writing to file/cm enabled in the config. Writing to file by default
• Writing to file/cm implemented in a generic way (interface with different impl)
• Tests
• Document all available flags in README
• Update charts (make this change optional, enabled via value, default behavior is configmap)

Probably leader election should be disabled in such scenario, all controllers should react on CRs.

bearer_token authenticator is not available

Describe the bug

It is not possible to configure a rule of handler type bearer_token. Applying the rule gets rejected with validation error in Rule iam/sample-rule-1: "invalid handlers: [authenticator/bearer_token], please check the configuration"

I think this happens because the handler is not listed as a default authenticator in https://github.com/ory/oathkeeper-maester/blob/master/main.go#L41

To Reproduce

Create any rule with handler bearer_token

apiVersion: oathkeeper.ory.sh/v1alpha1
kind: Rule
metadata:
  name: sample-rule-1
spec:
  upstream:
    url: "http://abc.ef"
    preserveHost: false
  match:
    methods: ["GET"]
    url: <http|https>://localhost:8080
  authenticators:
    - handler: bearer_token
  authorizer:
    handler: allow
  mutators:
    - handler: noop
      config: {}

Expected behavior

It should be possible to configure a rule with bearer_token authenticator out of the box.

Environment

• Version: oathkeeper-0.23.2 (which installs the oathkeeper-maester)
• Environment: Kubernetes

Additional context

oathkeeper-maester crashes on updating configmap w/ rules

Description

Oathkeeper-maester crashes while updating configmap with rules. Controller should have the most recent version of the configmap to update.

Expected result
The most recent version of configmap should be updated. Oathkeeper-maester should log the error and should NOT crash.

Actual result

The controller logs error on updating old version of configmap with rules and crashes. Oathkeeper-maester pod restarted several times. See the following logs:
oathkeeper-maester-699cccb749-vplhm 0/1 CrashLoopBackOff 26

2019-11-06T10:17:21.490Z	ERROR	controllers.Rule	unable to process rules Configmap	{"error": "All attempts fail:\n#1: Operation cannot be fulfilled on configmaps \"ory-oathkeeper-rules\": the object has been modified; please apply your changes to the latest version and try again\n#2: Operation cannot be fulfilled on configmaps \"ory-oathkeeper-rules\": the object has been modified; please apply your changes to the latest version and try again\n#3: Operation cannot be fulfilled on configmaps \"ory-oathkeeper-rules\": the object has been modified; please apply your changes to the latest version and try again\n#4: Operation cannot be fulfilled on configmaps \"ory-oathkeeper-rules\": the object has been modified; please apply your changes to the latest version and try again\n#5: Operation cannot be fulfilled on configmaps \"ory-oathkeeper-rules\": the object has been modified; please apply your changes to the latest version and try again"}
github.com/go-logr/zapr.(*zapLogger).Error
	/go/pkg/mod/github.com/go-logr/[email protected]/zapr.go:128
github.com/ory/oathkeeper-maester/controllers.(*RuleReconciler).Reconcile
	/go/src/github.com/ory/oathkeeper-maester/controllers/rule_controller.go:108
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:216
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:192
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).worker
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:171
k8s.io/apimachinery/pkg/util/wait.JitterUntil.func1
	/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:152
k8s.io/apimachinery/pkg/util/wait.JitterUntil
	/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:153
k8s.io/apimachinery/pkg/util/wait.Until
	/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:88

Version of the maester installed: oryd/oathkeeper-maester:v0.0.2-beta.1

Release v0.1.3 did not pass status check and was not pushed to docker registry

Back-off pulling image "oryd/oathkeeper-maester:v0.1.3": ImagePullBackOff

upstream reference closed: github.com/anchore/grype/issues/558

The upstream issues got closed. It is referenced in:

• .grype.yaml#L2
• .grype.yaml#L4

This issue was created by the ORY Closed Reference Notifier GitHub action.

Handlers "config" attribute is replaced by an empty object

Assume the following configuration:

apiVersion: oathkeeper.ory.sh/v1alpha1
kind: Rule
metadata:
  name: hub-animeshon
  namespace: oathkeeper
spec:
  authenticators:
    - handler: anonymous
    - handler: cookie_session
  authorizer:
    handler: allow
  mutators:
    - handler: id_token
      config:
        ttl: 3600s
        claims: |
          {
            "aud": [ "hub.animeapis.dev" ],
            "session": {{ .Extra | toJson }}
          }
  match:
    url: <{https,http}>://hub.animeshon.dev/<**>
    methods: ["GET", "POST", "PUT", "DELETE", "OPTIONS", "HEAD"]

The translated Rule is missing the mutators[0].config attribute:

[
  {
    "upstream": {
      "url": "",
      "preserve_host": false
    },
    "id": "hub-animeshon.oathkeeper",
    "match": {
      "url": "<{https,http}>://hub.animeshon.dev/<**>",
      "methods": [
        "GET",
        "POST",
        "PUT",
        "DELETE",
        "OPTIONS",
        "HEAD"
      ]
    },
    "authenticators": [
      {
        "handler": "anonymous"
      },
      {
        "handler": "cookie_session"
      }
    ],
    "authorizer": {
      "handler": "allow"
    },
    "mutators": [
      {
        "handler": "id_token",
        "config": {}
      }
    ]
  }
]

---

Notice that the following block is not as expected:

{
  "mutators": [
    {
      "handler": "id_token",
      "config": {}
    }
  ]
}

This is how a correctly applied rule should look like:

{
  "mutators": [
    {
      "handler": "id_token",
      "config": {
        "ttl": "3600s",
        "claims": " {\n \"aud\": [ \"hub.animeapis.dev\" ],\n \"session\": {{ .Extra | toJson }}\n }"
      }
    }
  ]
}

Update to latest changes in oathkeeper access rule config

Latest change in oathkeeper https://github.com/ory/oathkeeper/blob/master/UPGRADE.md#config-changes

Provides breaking change in the access rule format. Controller needs to be updated in order to allow saving access rule in new format, where configurations are nested in config object.

Example : https://www.ory.sh/docs/oathkeeper/pipeline/authn#configuration-6

Create controller skeleton

With CRD defined in #1 we need to create a controller skeleton using kube builder.

Controller should react on create, update, delete actions for the CR and serve compiled list of access rules on an endpoint (just GET) and in configmap reflecting oathkeeper API schema.
Configmap could be later on mounted as volume in the oathkeeper deployment.

In the first iteration, controller should be able to run as a central component (1 controller in the cluster)

• Store access rule in configmap which later can be mounted as a volume in oathkeeper
• If user will manually update configmap, controller should overwrite wit data coming from CR but do now watch for configmap change explicitly. Overwrite when there is some change in CR
• Once configmap handling is done, create an endpoint which can expose also access rules but make it optional - if it's set in the config (deployment) serve http server.
• Create README which describes how to run,build and test controller

More details provided soon

/cc @aeneasr