I have a bare metal kubernetes deployment running on vmware vcloud director and I am struggling to setup cert-manager to manage ssl certificates. As described in following issue, "Challenge" always fails with self-check to cluster's domain name/Public IP because of it is not accessible from inside of cluster (vmware vcloud director doesn't support hairpin nat which is routing traffic from internal server back to internal server using edge gateways public IP).
https://github.com/jetstack/cert-manager/issues/863
There is also a feature request to disable http01 and dns01 self-check but this is not implemented yet.
https://github.com/jetstack/cert-manager/issues/1292
My questin is "Is there a work-around solution to fix this self-check request?" I am also using node-port to open nginx-ingress service to outside. Therefore, I have to route www.domain.com:80 request from cert-manager pod to ingress-nginx pod 31080 port without leaving the kubernetes cluster.
Best Regard
Related
I have to deploy an application via Helm by supplying a VM Ip address and node port. Its a BareMetal Kubernetes cluster. The kubernetes cluster has ingress controller installed (as node port, this value is supplied in helm command). The problem is: I am receiving a 404 not found error if I access the applciation as:
curl http://{NODE_IP}:{nodeport}/path
there is no firewall. I have "allow all ingresss traffic" policy. But not sure what is wrong. I have now tried anything possible but cannot find the root cause.
We have 10 different kubernetes pods which runs inside a private VPN, this pods are HTTP serving endpoints(not HTTPS). But this services would interact with HTTPS serving endpoints. Logically to make call to HTTP-S serving endpoints from a HTTP serving pod , the SSL server certificate trust is required. Hence we decided to store the SSL certificates inside each HTTP Service pods to make call to HTTPS serving pods.
I am wondering is there are any alternative approaches for managing SSL certificates across different pods in Kubernetes cluster? How about kubeadm for K8s certificate management ... any suggestions ?
This is more of a general SSL certificate question rather than specific to Kubernetes.
If the containers/pods providing the HTTPS endpoint already have their SSL correctly configured and the SSL certificate you are using was purchased/generated from a known, trusted CA (like letsencrypt or any one of the known, trusted certificate companies out there) then there is no reason your other container apps that are making connections to your HTTPS endpoint serving pods would need anything special stored in them.
The only exception to this is if you have your own private CA and you've generated certificates on that internally and are installing them in your HTTPS serving containers. (Or if you are generating self-signed certs). Your pods/containers connecting to the https endpoints would then need to know about the CA certificate. Here is a stackoverflow question/answer that deals with this scenario:
How do I add a CA root certificate inside a docker image?
Lastly, there are better patterns to manage SSL in containers and container schedulers like Kubernetes. It all depends on your design/architecture.
Some general ideas:
Terminate SSL at a load balancer before traffic hits your pods. The load balancer then handles the traffic from itself to the pods as HTTP, and your clients terminate SSL at the Load Balancer. (This doesn't really tackle your specific use case though)
Use something like Hashicorp Vault as an internal CA, and use automation around this product and Kubernetes to manage certificates automatically.
Use something like cert-manager by jetstack to manage SSL in your kubernetes environment automatically. It can connect to a multitude of 'providers' such as letsencrypt for free SSL. https://github.com/jetstack/cert-manager
Hope that helps.
My Kubernetes cluster has 2 applications.
A deployment connecting to an external API through https:// - lets call it Fetcher
A proxy service which terminates the HTTPs request to inspect the headers for rate limiting - called Proxy
The deployment uses the mentioned proxy, picture the following architecture
Fetcher deployment <-- private network / Kubernetes --> Proxy <-- Internet --> external API
Before I moved to Kubernetes this was solved by creating a self-signed certificate and certificate authority CA to trust and place them on the Fetcher and proxy. The certificate simply contained the IP address of docker as SAN.
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com, DNS:mail.example.com, DNS:ftp.example.com, IP Address:192.168.99.100, IP Address:192.168.56.1, IP Address:192.168.2.75
However I can't do this in Kubernetes, can I? Since the IP addresses of both the deployment and service are not guaranteed, the IP's could change. I am using a Kubernetes CoreDNS solution, could I add the dns addresses in the certificate? I dont know enough about ssl/certificates to understand.
How can I create a certificate and CA in Kubernetes to create a trust between the certificate sent by the proxy with a custom certificate authority on the fetcher?
If you expose the proxy deployment via a service, then by default it will be assigned a ClusterIP which will be stable even as the IPs of the pods running the proxy may change over time. You will want to generate a cert with an IPSAN corresponding to the ClusterIP of the service, rather than any of the IPs of the pods. Check out the official docs regarding the "service" concept.
I have a k8s cluster that sits behind a load balancer. The request for myapisite.com passes through the LB and is routed by k8s to the proper deployment, getting the SSL cert from the k8s load balancer ingress, which then routes to the service ingress, like so:
spec:
rules:
- host: myapisite.com
http:
paths:
- backend:
serviceName: ingress-605582265bdcdcee247c11ee5801957d
servicePort: 80
path: /
tls:
- hosts:
- myapisite.com
secretName: myapisitecert
status:
loadBalancer: {}
So my myapisite.com resolves on HTTPS correctly.
My problem is that, while maintaining the above setup (if possible), I need to be able to go to my local service endpoints within the same namespace on HTTPS, i.e. from another pod I should be able to curl or wget the following without a cert error:
https:\\myapisite.namespace.svc.cluster.local
Even if I were interested in not terminating SSL until the pod level, creating a SAN entry on the cert for a .local address is not an option, so that solution is not viable.
Is there some simple way I'm missing to make all local DNS trusted in k8s? Or some other solution here that's hopefully not a reinvention of the wheel? I am using kubernetes version 1.11 with CoreDNS.
Thanks, and sorry in advance if this is a dumb question.
If your application can listen on both HTTP and HTTPS, you can configure both. Meaning you will be able to access via both HTTP and HTTPS by your preference. Now, how you create and distribute certificate is a different story, but you must solve it on your own (probably by using your own CA and storing cert/key in secret). Unless you want to use something like Istio and its mutual tls support to secure traffic between services.
While you write what you want to achieve, we don't really know why. The reason for this need might actually help to suggest the best solution
I 've apache camel application deployed on kubernetes. My application is esposed in kubernetes cluster which is accessible at http://192.168.99.100:31750. so how to make it accessiible accross.
I suggest you do 2 things :
run an NginX Ingress Controller in your minikube and expose it with NodePort service. Meaning it will be available somewhat similar to your service right now (high port range)
run HAProxy on your host that runs minikube that will forward 80/443 port to your high ports on minikube (ie. 80->32080, 443->32443)
that way you can expose your ingress controller on standard ports and have your services exposed with regular kubernetes Ingress definitions on these ports.