feat: Add support for OPA authorizer

[sbernauer]

Description

Closes #400

Definition of Done Checklist

• Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
• Please make sure all these things are done and tick the boxes

Author

Beta Give feedback

1. Changes are OpenShift compatible
2. CRD changes approved
3. CRD documentation for all fields, following the style guide.
4. Integration tests passed (for non trivial changes)
5. Changes need to be "offline" compatible

Reviewer

Beta Give feedback

1. Code contains useful comments
2. Code contains useful logging statements
3. (Integration-)Test cases added
4. Documentation added or updated. Follows the style guide.
5. Changelog updated
6. Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

Beta Give feedback

1. Feature Tracker has been updated
2. Proper release label has been added

[NickLarsenNZ]

LGTM

[sbernauer]

In terms of CRD change we have two options:

1. Enable authorizer and group-mapper simultaneous

  # Enable authorizer and group-mapper at the same time
  clusterConfig:
    authorization: # optional
      opa: # mandatory
        configMapName: opa # mandatory
        package: hdfs # mandatory

• Good, because consistent and users can not enable authZ and forget about group mapping
• Good, because rego rules can rely on the groups being propagated (although not recommended)

2. Enable authorizer and group-mapper separately

  clusterConfig:
    authorization: # optional
      opaAuthorization: # mandatory
        configMapName: opa # mandatory
        package: hdfs # mandatory
      opaGroupMapping: # optional
        configMapName: opa # mandatory
        package: hdfs # mandatory

• Good, because more flexible, e.g. you can enable AuthZ without group mapping (which you basically would get for free)
• Bad, because more complex and error-prone

Originally I was thinking of 2., but now I am in favor of 1., as it's simpler and more consistent and 2. only enables stuff we should probably not support :)
User can always use configOverrides to easily partially enabled stuff when they really really want to.

[sbernauer]

Started https://ci.stackable.tech/view/02%20Operator%20Tests%20(custom)/job/hdfs-operator-it-custom/128/

[adwk67]

Just reviewed the docs so far with a few comments. Nit: we use regorule, rego rule and rego-rule here: I don't mind which it is but we should be consistent. The opa docs seem to use two separate words i.e. rego rules.

[sbernauer]

@adwk67 feedback should be addressed

[sbernauer]

Started https://ci.stackable.tech/view/02%20Operator%20Tests%20(custom)/job/hdfs-operator-it-custom/129/

[adwk67]

LGTM! Can merge when the CI tests are all done.

[adwk67]

LGTM! Can merge when the CI tests are all done.

[sbernauer]

And also a full testsuite run: https://ci.stackable.tech/view/02%20Operator%20Tests%20(custom)/job/hdfs-operator-it-custom/130/

[sbernauer]

Another full testsuite run, after I increased the resources in stackabletech/ci@40937a9:
https://ci.stackable.tech/view/02%20Operator%20Tests%20(custom)/job/hdfs-operator-it-custom/131/

[sbernauer]

Full testsuite passed 🚀