Support for k8s authorization service

[dadrus]

Preflight checklist

• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines."
• I have discussed this feature request with the community.

Describe the background of your feature request

A Kubernetes cluster comes with build-in authorization capabilities, used to define which subject in a cluster can access which resources. The configuration is done by making use of corresponding authorization resources, like Role, RoleBinding, etc.

The same authorization resources can be used to implement the required authorization model for regular services/applications deployed to the cluster. Such approach would remove the need to deploy a special purpose authorization service in the cluster making the setup more simple.

Describe your idea

Implement an authorization mechanism which would make use of SubjectAccessReview to check whether a given subject is allowed to access a specific endpoint of a service.

It would work as follows:

• The developer of the service, heimdall should protect access to, would create (Cluster)Role objects describing the allowed permissions
• Those services, which should be allowed to communicate to the above one would need a ServiceAccount and (Cluster)RoleBinding resources, latter referencing the abovesaid (Cluster)Role(s).
• When the request comes in for the to be protected service, heimdall would query the API Server by making use of SubjectAccessReview and based on the response allow the request to pass through, or decline it.

Are there any workarounds or alternatives?

As written in the description, one could make use of any general purpose authorization service, like SpiceDB, Keto, OPA, OpenFGA, etc. Depending on the context and requirements, that would mean much more complex setup as actually desired.

Version

v0.13.0-alpha

Additional Context

To allow such an authorization mechanism, there is obviously a need to verify a token of a ServiceAccount. In principle, this could be done via the available JWT authenticator. However, it would be more straight forward to make use of the TokenReview API for this purpose.