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

[Demonsthere]

this is a static file, not a template, functions are not supported 😉

[edeustua]

Yes! I know, haha. I just wanted to give you the feel for it since you were thinking about a larger refactor.

In principle, you would need, at least, the name of the release ahead of time, use that helper, or use fullnameOverride with oathkeeper.

I should have written a comment after pushing this, I'm sorry about that. I'm going to put the PR in draft now.

Maybe I should just try doing the changes in the CI that would lead to this tests working? Maybe you can give me some guidance on how you would like to do this:

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

Thanks again for your help.

[Demonsthere]

No worries :) My idea for the CI refactor would be rather straightforward.
Current structure

hacks/
  values/
    oathkeeper.yaml
    keto.yaml
    ...

New structure

hacks/
  values/
    oathkeeper/
      case1.yaml
      case2.yaml
    keto/
      foo.yaml

This would allow us to hold multiple config options in the CI and tests all of them automatically :)

In the quote you send i meant to deploy the cm as a static object, with a predefined foo name, and then feed that name as a variable in the values