fix: oathkeeper - allow self managed rules when maester is disabled

[edeustua]

Since PR #669, self-managed access rules are impossible to deploy. This commit fixes that by allowing the deployment controller to load the rules config map when maester is disabled.

Related Issue or Design Document

In PR #669, logic was added to the deployment controller such that the access rules configmap would not be loaded when .Values.managedAccessRules was false. This breaks down self-templated access rules when maester is not desired.

Checklist

• I have read the contributing guidelines and signed the CLA.
• I have referenced an issue containing the design document if my change introduces a new feature.
• I have read the security policy.
• I confirm that this pull request does not address a security vulnerability.
  If this pull request addresses a security vulnerability,
  I confirm that I got approval (please contact security@ory.sh) from the maintainers to push the changes.
• I have added tests that prove my fix is effective or that my feature works.
• I have added the necessary documentation within the code base (if appropriate).

Further comments

There might be other ways to address this. Let me know if you have other suggestions. In PR #669, a suggestion was made restrict the logic only when maester's sideloader mode was enabled @cbrendanprice . This might be a solution as well.

[CLAassistant]

All committers have signed the CLA.

[Demonsthere]

Could you please update the hacks/values/oathkeeper.yaml to trigger this case on our CI? I would like to expand the tests to cover a wider array of cases

[edeustua]

Could you please update the hacks/values/oathkeeper.yaml to trigger this case on our CI? I would like to expand the tests to cover a wider array of cases

Sure thing. I'll do it today.

[edeustua]

Could you please update the hacks/values/oathkeeper.yaml to trigger this case on our CI? I would like to expand the tests to cover a wider array of cases

Just to further comment on the issue. We use oathkeeper as a subchart of our own chart, and therefore we build the access rules config map before deploying oathkeeper. We do this because we don't want to use maester at this point.

Disabling managedAccessRules in hacks/values/oathkeeper.yaml would prevent the access rules defined in it from deploying properly. Maybe you would like me to add a different test? Let me know.

[Demonsthere]

My end goal would be to refactor the current setup into hacks/values/$component/values-testcase.yaml and have the CI iterate over all cases in the directory. This is moderately bigger refactor that needs to be done in a separate issue/pr. In this case I think we can emulate the use-case by adding a oathkeeper-rules manifest here, so it will act as a pre-existing cm which has to be consumed by the chart