[FEAT] - Secure resources exposed with the service-proxy

[IvoGoman]

User Story

As a Greenhouse Admin I want to restrict access to URLs exposed with the service-proxy, so that the audience of a service can be controlled.

A second use case is to allow access to exposed services for technical users (e.g. with api key or tls certificate)

Description

As is everyone who has access to a URL exposed via the service-proxy can access it. In order to avoid misuse of this feature and the exposed service the access should be restricted. This is a PCI compliance issue as access to all administrative UIs (even read-only UIs like prometheus/plutono) has to be protected.

Solution Proposal

For authentication we will reuse the idproxy which is already used to protect the greenhouse UI.
This will make sure that only users with access the the organization can assess the exposed services.
The service proxy is currently exposed via the nginx-ingress and a single org-wide ingress resource with a wildcard certificate.
This means we can use a similar approach as we do for elektra: We deploy an oauth2-proxy next the service proxy in each organization and configure it to use the idproxy as an upstream oidc authentication provider.
By adding an annotation the the service-proxy ingress definition we can make sure the ingress will only forward authenticated requests to the service-proxy instances.

Pros:

• Re-use of proven implementation (elektra), oauth-proxy chart
• Low implementation effort, mostly adding resources to the service-proxy chart

Cons:

• Only authentication, no fine grained authorization possible per exposed-service

For the second use case we could a second ingress resource that requires client tls credentials instead of oidc authentication. The client certificate should be manageble by org admins (e.g. in a secret)

Acceptance Criteria

• service-proxy URLs should be protected automatically
• by default all Organization members should have access to the service-proxy URLs
• Support for certificates for accessing exposed endpoints interactively

Reference Issues

No response

[IvoGoman]

Requires #738 and #798 to be completed before the oauth-proxy can be implemented.

For the oauth2-proxy it needs to be checked how the connector id can be passed to dex, so that the enduser does not need to select their organisation when redirected to dex