SSL redirect is enabled by default in a Kubernetes NGINX ingress on Rancher 2. We changed the config map and redeployed the nginx -ingres in the system namespace, but the redirect still happens. Has someone managed to disable it?
Unfortunately I don't think you will be able to disable SSL in Rancher v2.
As per Randcher documentation:
For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster.
You can find there few ways to apply this certs:
Default Rancher-generated Self-signed Certificate
Bring Your Own Certificate, Self-signedlink
Bring Your Own Certificate, Signed by a Recognized CA
Let’s Encrypt Certificatelink
Inside this doc you have hyerlinks to further Rancher docs.
As Rancher by default deploying nginx controller you should also check Rancher docs about Nginx Controller.
As an update, rancher can disable http -> https redirection by disabling ingress's TLS and set a custom header "X-Forwarded-Proto: https" from ingress controller -> rancher,
reference:
https://github.com/rancher/rancher/issues/35088
Related
I have a service providing an API that I want to only be accessible over https. I don't want http to redirect to https because that will expose credentials and the caller won't notice. Better to get an error response.
How to do I configure my ingress.yaml? Note that I want to maintain the default 308 redirect from http to https for other services in the same cluster.
Thanks.
In the documentation: you can read the following sentence about HTTPS enforcement through redirect:
By default the controller redirects (308) to HTTPS if TLS is enabled for that ingress. If you want to disable this behavior globally, you can use ssl-redirect: "false" in the NGINX ConfigMap.
To configure this feature for specific ingress resources, you can use the nginx.ingress.kubernetes.io/ssl-redirect: "false" annotation in the particular resource.
You can also create two separate configurations: one with http and https and the other one only for http.
Using kubernetes.io/ingress.class annotation you can choose the ingress controller to be used.
This mechanism also provides users the ability to run multiple NGINX ingress controllers (e.g. one which serves public traffic, one which serves "internal" traffic).
See also this and this similar questions.
We have a AngularJS application where we have a nodejs app which creates certificates and key for service hostname only when HTTPS port is 443. Then created certificates are consumed in nginx as shown below:
<% if ENV["HTTPS__ENABLED"] == "true" %>
listen <%= ENV["HTTPS__PORT"] %> ssl;
# These files are generated by the node app
ssl_certificate /cert.csr;
ssl_certificate_key /tls_private_key.csr;
ssl_protocols TLSv1.2;
<% end %>
But when I set 443 port in route with re-encrypt termination it gives below error while accessing application
Application is not available
The application is currently not serving requests at this endpoint. It may not have been started or is still starting.
The request is not even reaching pod. If I create route with edge termination is gives error
400 Bad Request
The plain HTTP request was sent to HTTPS port
As in Edge termination there is no encryption from router to pod.
I cannot use passthrough termination policy as we have path in our route which is not supported by passthrough termination.
can someone please let me know how to achieve end to end encryption in openshift 4.3. We do not use custom domain here.
I was checking the way for creating re-encrypt route
oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com
but as we are not using custom domain our route should use default cert and key right? So no need to provide those right? I am not getting how to create --dest-ca-cert for this route.
TLS is already enabled in our AngularJS app using a nodejs app which creates cert and key which is consumed by Nginx.Pod inside the cluster uses TLS, it’s issued by a CA, that’s the cert we should put in destinationCACert for the route.The CA cert is how the router determines if it can trust the upstream POD for the TLS communication.
We used ca.cert located at /var/run/secrets/kubernetes.io/serviceaccount/ca.crt as destination certificate while creating re-encrypt route. We selected HTTPS port while creating route.
oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com
Here tls.cert and tls.key is not needed for us as we were using default domain of the openshift cluster.Only cert we used is --dest-ca-cert which is also found at secret service-serving-cert-signer-sa-token-l42lm of openshift-service-ca namespace
For re-encrypt route the pod needs to be configured with a TLS certificate as it has to respond to TLS request originated at Openshift router. You already have it as evident from the error you are getting when trying to use edge route.
Now this TLS certificate, must be created with same host name that you want to use in the actual route. It is not necessary that this TLS certificate is a CA signed one, but the hostname must match with the route. Only then the route can forward traffic to your pod.
We used http:servername:8080 when configured jenkins. Later we enabled ssl and made the jenkins access under https:servername:8080. But We want to redirect http:servername:8080 to https:servername:8080. Can you please help us here.
First of all you need to change the port for https connections, because the server can not listen on the same port for the same protocol (in your case TCP protocol and port 8080).
For example, you can configure https to a default 443 port.
Regarding redirection, actually, it is recommended to put a reverse proxy in front of the jenkins server. See official documentation about running jenkins with SSL https://wiki.jenkins.io/pages/viewpage.action?pageId=135468777.
Here is the manual how to configure jenkins behind an nginx reverse proxy with http to https redirection: https://wiki.jenkins.io/display/JENKINS/Jenkins+behind+an+NGinX+reverse+proxy
I wanted to visit my dashboard on a local Kubernetes installation (using docker for mac). I was 'blocked'. I have to provide a token or my config which is normal since the RBAC updates.
Now I don't want to kubectl proxy or enable port forwarding every time I want to visit my dashboard so I installed an nginx proxy with a ingress (tls) which redirects me to https://kubernetes-dashboard.kube-system.svc.cluster.local:443.
This works fine but now I'm a bit confused because I can see the dashboard now, without facing the RBAC issue.
I read this here:
To make Dashboard use authorization header you simply need to pass
Authorization: Bearer in every request to Dashboard. This can
be achieved i.e. by configuring reverse proxy in front of Dashboard.
Proxy will be responsible for authentication with identity provider
and will pass generated token in request header to Dashboard. Note
that Kubernetes API server needs to be configured properly to accept
these tokens.
But it's still not very clear for me. Can someone explain we why I can see the dashboard when I create a proxy in front of it?
Proxy is usually needed to transfer data between different segments of the network without connecting them directly.
Each segment of the network is "talking" to proxy host without any knowledge of the existence of the other network segment.
The Proxy Server is responsible for all negotiations and operations concerning requests and response packets. So, to enable authentication, authorization, SSL termination and many other things you need to configure your proxy server according to your needs.
If you can see the kubernetes dashboard via proxy in front of it it just means that you did not configure any security on that proxy.
For example, to learn how to configure Nginx Ingress to protect a service with basic authentication in your cluster consider to read this article.
For more complex security setup read the article about securing Kubernetes services with Ingress, TLS and LetsEncrypt.
I'm trying to put the WSO2 API Manager 1.8.0 behind an Apache proxy but it does not work.
I modified catalina-server.xml and set proxyPort but it still redirects met to port 9443. Other pages (like publish/) redirect to localhost.
I also set the correct hostname (using <HostName> and <MgtHostName>) in carbon.xml.
I suspect there are some other configuration settings which must be changed. Is there an overview available with everything you need to change in order to put the API Manager behind a reverse proxy?
in catalina-server.xml you can set proxy port for http and https. so for management console you need to add proxyport for https as follow
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
port="9443"
**proxyPort="443"**
bindOnInit="false"
sslProtocol="TLS"
maxHttpHeaderSize="8192"
acceptorThreadCount="2"
check this post on how publisher app site.json and store app site.json should be modified for reverse proxy.there you can set host name(your proxy) and even message contextpath.(this post explains with nginx same applicable to apache)
http://sanjeewamalalgoda.blogspot.in/2014/12/configure-wso2-api-manager-with-reverse.html