Fix Vault and MinIO tenant Web UIs

[matthewrossi]

In their current state, Vault and MinIO tenant Web UIs return the "Client sent an HTTP request to an HTTPS server" error.

This happens despite providing the nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" annotation to the Vault and MinIO tenant Ingresses, so with this patch I update their annotations to make sure NGINX redirects their requests to HTTPS.

From the test I have done on the integration cluster, this completely solves the primary issue. However, the MinIO Console is still proving problematic. Indeed, while the MinIO Console login page is now accessible, after logging in, the interaction with the session endpoint responses with {"detailedMessage":"Access Denied.","message":"invalid session"} and leaves us with a blank page. To me this seems like a MinIO Console bug caused by using an HTTP ingress for the HTTPS server, so I will reach out to the MinIO community to get support on this.

I run a few tests in a local Minikube environment and with HTTP I can reproduce the same issue, however with HTTPS the MinIO Console works. So, would it be possible to update the NGINX configuration to support HTTPS incoming traffic?

[a-zharinov]

Dear @matthewrossi, thank you for the pull-request. I have shocking news for you: our platform does not support HTTPS yet. All the exposed web UIs and APIs use HTTP. From a practical point of view, it is secure enough because of VPN and a lack of sensitive data.

We decided to not set up HTTPS many months ago to save time. There is no simple solution to enable HTTPS. Self-signed certificates are not a good option. This is why to enable HTTPS we should not only change the Nginx configuration and install cert-manager, but also open access to the cluster from the internet and switch to public DNS servers and names. It is possible but not trivial.

Does it work for you to use HTTP for your web UIs?

[matthewrossi]

Dear @a-zharinov, thank you for your answer. I am sorry for the delayed response, but somehow I did not get any notifications about your comment.

I agree with you. In our use case, the use of only HTTP to access the web UIs and APIs is not a significant security problem since we are tunneling all the traffic through an encrypted tunnel with the VPN and we are not treating sensitive data.

However, unfortunately, the MinIO console requires the use of a secure connection to work.

Basically, after logging in, the MinIO console returns a response with the Set-Cookie header with the goal of configuring the session token. However, with the current configuration of the NGINX reverse proxy, which does not allow HTTPS communications, the configuration of the session token is blocked client-side because the token is marked with the Secure attribute and consequently the operation is only performed when the connection is deemed secure (i.e., we are using HTTPS).

I think in this situation the only solution that does not imply disabling HTTPS on the backend, is updating our environment to also allow HTTPS traffic to the integration and validation clusters.
To the best of my knowledge, we could go for a self-signed certificate; yes I agree this is not more secure and we are presented with the ugly message saying "Your connection is not private", but at least we would be able to get the MinIO console to work.

Please let me know your thoughts on this.

[matthewrossi]

Hi @a-zharinov,

I'm following up on my previous comment regarding the MinIO console and HTTPS requirement. I understand if you've been busy, but I'd appreciate your thoughts on the proposed solution of enabling HTTPS traffic to the integration and validation clusters using a self-signed certificate.

This would allow the MinIO console to function correctly within our current security constraints.

If this is not an option, I would like to be notified so that we can come up with and apply corrective measures as soon as possible.