Support for client certificate validation in order to verify only requests from Equinor API Manamgenent are allowed

[elsewhat]

Is your feature request related to a problem? Please describe. The background for this request is that we're investigating moving the Maintenance API from an Azure App service to Radix.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] In the Azure App Service today we have enabled client certificates as pr Microsoft's documentation and Equinor API Management is configured to send their client certificate. This allows us to guarantee requests are going through Equinoir API Management and not directly to the app service and therby avoiding subscription key requirements and other security features.

Describe the solution you'd like From Microsoft documentation for how Azure App service works with client certificates "In App Service, TLS termination of the request happens at the frontend load balancer. When forwarding the request to your app code with client certificates enabled, App Service injects an X-ARR-ClientCert request header with the client certificate. App Service does not do anything with this client certificate other than forwarding it to your app."

We would like the same functionality in Radix

Describe alternatives you've considered Not moving to Radix ;) Evaluate if client certificates are necessary part of the architecture in order to ensure security.

Additional context The radix loadbalancer based on Nginx is terminating the TLS so it needs to have the logic to pass the thumbprint or the public key of the HTTP certificate . Some documentation on this from nginx http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ssl_certificate

[jonaspetersorensen]

nginx already read certs from from secret, this is how the cert-manager integration work. Meaning it might be "easy" to implement this feature the same way as custom ingress configuration, https://www.radix.equinor.com/docs/reference-radix-config/#ingressconfiguration

[hekka]

From the nginx docs, looks like these are the config-settings that could be made available in ingressconfiguration-section, if I understand it right? edit added link

Any update on if this will be looked at? @emirgens

[emirgens]

Product Backlog reference: https://dev.azure.com/Equinor/Radix/_workitems/edit/82539

[emirgens]

It is not prioritized in the next few sprints. I'll update our PO with your request.

[elsewhat]

We'll be starting with the implementation of a new API 'Operating Projects API' and believe Radix would be a good fit for it. On a successful implementation, it is likely we'll also move Maintenance API to Radix.

In order to implement 'Operating Projects API' on Radix without this enhancement issue in place, we need advice regarding the security impact. Our understanding is that most APIs in Equinor in production, do not validate a client certificate from APIM today.

The effect of not performing this client certificate validation is:

1. Clients can call the API app service in Radix directly instead of via APIM. We can probably mitigate this by verifying the request contains a subscription key (although we cannot validate if it's a valid subscription key) or through operational logs from app insight. We don't expect this to be a major concern though.

2. The radix app service will be open over the internet with one less barrier than with todays architecture The API will still require all request to have a valid access token from Equinor Azure AD. We expect this to have sufficient security as this is similar to what other APIs do today. However, it would be good to get a clear signal either here from @oyron or our product owner @atarigui (Guillaume Fagernes-Turpin) or via an architecture contract that it's is an ok architecture.

[atarigui]

This API will be lightweight and the project can not alone take upfront costs in exploring 'unknown territories'. I am tempted to not use RADIX, and move later when the necessary functionality is in place. Edit: if there is support from the IT discipline network, this is will be fine for me. I just do nto have the necessary competence to assess whether the issue is causing an unacceptable risk, or not. INput from @oyron would be appreciated

[elsewhat]

@oyron Confirmed with Omnia Core team responsible for APIM that client certificate validation between APIM and backend is not normally used by existing APIs in Equinor. So it's a normal work practice today.

In order to 'Operating Projects API' on Radix without this enhancement issue in place we would need a confirmation from @oyron or other it disciplinary advisor that this is an acceptable risk to accept (at least temporarily untill this enhancement is in place)

[oyron]

This feature ha been implemented: https://radix.equinor.com/references/reference-radix-config/#clientcertificate Improving documentation is in progress.