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.
Related
I have an nginx server serving both as an http server (frontend) on / and reverse proxy on /api, where it forwards the requests to a node server (backend) on the same machine (localhost).
I am using authentication only on the frontend. The backend accepts all incoming requests and does not authenticate again the requests.
I would like to allow all requests coming from the frontend to the backend. I would like to block all requests coming to the backend from other sources (via the reverse proxy of course).
For example, the frontend will try to login the user using the user third-party auth id via https://domain/api/login/id. The reverse proxy will forward it to the backend. This is fine.
I can also access the backend directly from any other machine via https://domain/api/login/id.
My question is the following. I would like to block all requests not originating by the frontend. I have tried figuring out how to find the information but it seems that the X-Real-IP header always refers to the browser originating the request (either by using the frontend or directly). I am wondering if there is any header I can set in the reverse proxy which will tell the backend that this is an allowed call, or even use nginx own allow/deny rules. Right now, I do not manage to make a distinction between the two types of requests.
Thank you very much!
I'm attempting to connect a client running in a Kubernetes cluster to an Apache Pulsar cluster hosted by StreamNative. Specifically, I'm attempting to use the logstash-input-pulsar Plugin, which doesn't support auth. One option is to fork logstash-input-pulsar and add authentication; however, a more general option would be create a proxy between logstash and pulsar, where the proxy is able to handle authentication. (For example, the proxy could be a sidecar on the kubernetes pod where logstash is running.) I looked into using the Pulsar Proxy; however, this proxy is intended to run on the same Kubernetes cluster as the Pulsar broker(s). If the Pulsar client was using the HTTP protocol, I could set up nginx as a proxy between the client and broker, and nginx could add the appropriate auth - a header, for example. Pulsar, however, uses its own protocol over TCP. Would there still be a way to have a proxy that handles adding auth between the pulsar client and broker?
I have an application set up like this:
There is a server, with a reverseproxy/load balancer that acts as the HTTPS termination (this is the one that has a server certificate), and several applications behind it(*)
However, some applications require authentication of the client with a certificate. Authentication cannot happen in the reverse proxy. Will the application be able to see the user certificate, or will it be jettisoned by the HTTPS->HTTP transfer?
(*) OK, so this is a Kubernetes ingress, and containers/pods.
It will be lost. I think you need to extract it in the reverse proxy (i.e. Nginx) and pass it in as a HTTP header if you really must. See for example https://serverfault.com/questions/788895/nginx-reverse-proxy-pass-through-client-certificate. Not very secure as the cert is passed in the clear!
I don't know if we have that level of control over the ingress, personally I'm using a normal Nginx server for incoming traffic instead.
Currently in the gateway configuration I have to set the protocol to https like:
<ServerURL>https://10.130.10.110:9443/services/</ServerURL>
10.130.10.110:9443 is the https end point of the keymanager. If I switch to the http end point, the token validation will fail.
I searched all the WSO2 AM document and all the config sample are pointing to keymanager using https. It looks like the key manager only supports https, is it possible to change it to http? Because all the servers are deployed inside one VPC, there is no need to use http. The https is too heavy and the overall API gateway performance doesn't look good.
Thanks!
My application is based on Spring framework and is used to transmit very confidential data.During testing of the application with with proxy tools like Fiddler, Paros Proxy etc. it was found that these tools are intercepting the request data, and data is easily modified before reaching the server.
My application is not currently not integrated with SSL . We will implement SSL /HTTPS. but is this because SSL has not been integrated ?
Is it normal for Proxy tools to intercept the data from a web application with out HTTPS ?
There are two things here.
1) If you don't use SSL the communication is not encrypted, which means that anybody who is able to intercept the traffic, will be able to see the content. You don't necessarily need a proxy for that.
2) With an intercepting HTTP proxy you can see SSL encrypted traffic as well. What the proxy does is building two separate SSL tunnels one between the server and the proxy and one between the client and the proxy. This way the proxy itself can see the whole traffic. Of course the proxy can only provide a fake SSL certificate which will trigger a notification in the browser for the user, but he will probably ignore it.
Yes. If you don't use https, Proxy see everything that the application send or received.
To prevent that, you must use https.
To prevent sslstrip you must use HSTS.