Authenticating Requests Through Traefik
I am looking at using traefik as a proxy for a set a microservices.
However I realised that traefik does not support a authentication mechanism such as the one provided by Kong.
I would like to register consumers with traefik and allow access based on authentication.
Is there a recommend approach to doing this?
Ideally I would like to forward all incoming requests to a service that authenticates the incoming request. However I can not find any way to do this with traefik by using a custom middleware.
In short, is there a way to add such a middleware to traefik and have it execute a remote check before allowing a request to pass though?
(The basic auth built in to traefik is very limited.)
I don't believe Traefik supports this currently. Are you using a service discovery layer behind Traefik like Consul/Kubernetes Ingress? If so, these services may support ACL access to services.
Related
How can we make sure all requests are routed through cloudflare seevers only?
I currently setup dns in cloudflare in proxy mode. I set a custom domain mapping on cloud run and pointed dns records for my custom domain to ghs.googlehost.com.
Wondering how to make sure the traffic is received only from cloudflare to avoid abuses.
Update
There is another question about origin pulls but the answer mentions its only possible through OAuth which is not in detail.
You cannot achieve your goal without inserting a proxy that you must build. Google Cloud authorization is OAuth. Cloudflare's servers do not implement OAuth authorization headers.
You should implement OAuth at your clients. However, that will provide for authorization but not selectively from Cloudflare.
I have an application that is internal and exposed only to other application on the cluster by a service with cluster IP. Other services are accessing this application via it's DNS (serviceName-namespace.svc.cluster.local). This application handles sensitive data, so although all the communication is inside the cluster I would like to use TLS to secure the communications to this application.
My question is - how can I enable TLS on a service? Is there something already exist or should I handle it on the application code? Also, is there already a CA I can use on the cluster that can sign certificates for .svc.cluster.local?
To clarify, I know I can use ingress for this purpose. The only problem is keeping this service internal only - so only services inside the cluster will be able to access it.
Thanks,
Omer
I just found that Kubernetes API can be used to generate a certificate that will be trusted by all the pods running on the cluster. This option might be simpler than the alternatives. You can find the documentation here, including full flow of generating a certificate and using it.
Following #vonc comments from bellow, I think I have a solution:
Purchase a public valid domain for this service (e.g. something.mycompany.com).
Use CoreDNS to add override rule so all requests to something.mycompany.com will go to something-namesapce.svc.cluster.local, as the service is not exposed externally (this can be done also with normal A record for my use case).
Use Nginx or something else to handle TLS with the certificate for something.mycompany.com.
This sounds pretty complicated but might work. What do you think?
Check if the tutorial "Secure Kubernetes Services with Ingress, TLS and LetsEncrypt" could apply to you:
Ingress can be backed by different implementations through the use of different Ingress Controllers. The most popular of these is the Nginx Ingress Controller, however there are other options available such as Traefik, Rancher, HAProxy, etc. Each controller should support a basic configuration, but can even expose other features (e.g. rewrite rules, auth modes) via annotations.
Give it a domain name and enable TLS. LetsEncrypt is a free TLS certificate authority, and using the kube-lego controller we can automatically request and renew LetsEncrypt certificates for public domain names, simply by adding a few lines to our Ingress definition!
In order for this to work correctly, a public domain name is required and should have an A record pointing to the external IP of the Nginx service.
For limiting to inside the cluster domain though (svc.cluster.local), you might need CoreDNS.
On Google Cloud you can make load balancer service internal, like this:
annotations = {
"cloud.google.com/load-balancer-type" = "Internal"
}
We are evaluating reverse proxies which support API Gateway feature. We tested the API Gateway feature in NGINX with a custom authentication Application. The request flow in NGINX is that when a request reaches NGINX, it forwards the request for authentication to a custom authentication application. If the auth application returns HTTP 200, NGINX forwards the request to downstream servers.
HaProxy:
For HAP proxy I am unable to figure out how to integrate the custom authentication application in HAProxy configurations.
Kindly guide me to the correct configuration/resource for me to proceed.
I am looking for ways to authorize each individual client request made through the rest proxy. Is there a mechanism to integrate the proxy with existing Kafka ACL's?
I already configured the HTTPS authentication with client certificates so I have a unique client token I can include with every request for authorization purpose. My preferred approach would be to introduce a custom servlet filter that integrates with Kafka ACL system using something like SimpleAclAuthorizer. Unfortunately, the Rest Proxy is not a standard Web application but runs the embedded Jetty, so configuration is a bit more convoluted.
My question is, what is the least intrusive way to to accomplish this?
Thank you in advance.
You can configure a single kafka client credentials for the REST Proxy to use when connecting to Kafka, but today you cannot pass through the credentials of each HTTP(s) client separately. That feature is being worked on and will likely come out in a future release.
RBAC is available now in Confluent Kafka but it is still in preview here is the link
I have 2 web roles in a cloud service; my API and my Web Client. Im trying to setup SSL for both. My question is, do I need two SSL certificates? Do I need 2 domain names?
The endpoint for my api is my.ip.add.ress. The endpoint for my webclient is my.ip.add.ress:8080.
Im not sure how to add the dns entrees for this as there is nowhere for me to input the port number (which I have learned is because its out of the scope of the dns system).
What am I not understanding? This seems to be a pretty standard scenario with Azure Cloud Services (it is set up this way in the example project in this tutorial, for instance http://msdn.microsoft.com/en-us/library/dn735914.aspx) but I can't find anywhere that explains explicitly how to handle this scenario.
First, you are right about DNS not handling port number. For your case, you can simply use one SSL certificate for both endpoints and make the two endpoints have the same domain name. Based on which port is used by user request, the request will be routed to the correct endpoint (API vs. Web Client). Like you said this is a relative common scenario. There is no need to complicate things.
Let's assume you have one domain www.dm.com pointing to the ip address. To access your Web API, your users need to hit https://www.dm.com, without port number which defaults to 443. To access your web client, your users need to hit https://www.dm.com:8080. If you want users to use default port 443 for both web api and web client, you need to create two cloud services instead of one, then web api on one cloud service and web client on the other cloud service. Billing wise, you will be charged the same as one cloud service.
Are there any reasons you want to make 2 different domains and in turn 2 SSL certificates? If so, it is still possible. Based on your requirements, you may have to add extra logic to block requests from the other domain.