I am new to kubernetes and my question could be naive.
I am working for client and i installed JupyterHub on Google Kubernetes Engine. To be able to access it from client side externally I used ingress with TLS & hostname https://my-jupyterhub/jhub and everything is working fine.
Now my client doesn't want to use DNS/hostname for some reasons and want to access the jupyterhub using the IP address only.
Is it possible to have TLS without hostname in ingress? If No, how can I achieve it?
I think that you can achieve this by connecting through the External IP of the cluster and serving the Jupyter hub on the port you want and open that port.
You can of course set an static IP on the cluster so it stays the same, you can find information on that regard on the following links [1] [2].
[1] https://cloud.google.com/compute/docs/ip-addresses#reservedaddress
[2] https://cloud.google.com/kubernetes-engine/docs/tutorials/configuring-domain-name-static-ip
Related
In my example I am using https://portmap.io VPN service which is not exactly a pure VPN services but still uses VPN technology to break my ISP restrictions, allowing portforwarding to my own home server running in my android device.
So if I run 193.161.193.99:1200, my website gets browsed. The port 1200 is mapped to my local python server port running on port 1000. Port 1200 is given by the VPN provider.
However, if I try 193.161.193.99 without the port 1200. The portmap VPN official website gets called, cause that's the websites' IP. So basically each user of this VPN services has there own port to work with.
Question: I don't have any public IP totally in my own control to get an SSL certificate, which requires a file upload verification by the CA (CSR). So, it it anyhow possible to get an SSL certificate using 193.161.193.99:1200 ?
Note: Services like zerossl.com accepts to provide a certificate for ipv4 public addresses. So it not always essential to use a FQDN to get a cert.
Yes this is possible, you will need a domain pointing to the VPN/portmap IP and then obtain a SLL certificate from Let's Encrypt for that domain. This can be your own domain or one provided by a Dynamic DNS Service such as Duck DNS.
I'll describe how I have done it with Docker and Duck DNS in detail:
Sign in to Duck DNS, create a subdomain and point it to the VPN/portmap IP, note the token at the top of the page.
Deploy a docker container from LinuxServer.io's SWAG Image
Make sure to provide the required environment variables in your docker-compose.yml (or with docker run command):
- VALIDATION=duckdns
- DUCKDNSTOKEN={your token}
- URL={yourdomain}.duckdns.org
Note: If you want everything behind your VPN, there is a great docker container called gluetun which allows you to run the swag container behind your VPN
You will find your SSL certificates in the /config/etc/letsencrypt/live/{yourdomain}.duckdns.org folder of the SWAG container. Use those for the website/service that is running behind your forwarded port.
The certificates will get updated automatically 30 days before they expire. There is also a PKCS#12-file privkey.pfx, which is needed for services like emby. For more information on SWAG see the LinuxServer.io Docs. You may or may not need another container running that updates the Duck DNS IP periodically, I'm not sure if the SWAG container already does that.
All of this can of course be done without Docker and with your own domain. In this case you will need to map your domain or subdomain to the VPN IP in the DNS Record section of your domain provider. And then use certbot to create certificates for that domain. Docker just automates the renewal part.
I'm having problems portforwarding traefik. I have a deployment in Rancher, where i'm using metallb with traefik to have ssl certs. applied on my services. All of this is working locally, and i'm not seeing any error messages in the traefik logs. It's funny because, at times, i am able to reach my service outside of my network, but other times not.
I have portforwarded, 80, 433, 8080 to 192.168.87.135
What am i doing wrong? are there some ports im missing?
Picture of traefik logs
Picture of the exposed traefik loadbalancer
IPv4 specifies private ip address ranges that are not reachable from the internet because:
The Internet has grown beyond anyone's expectations. Sustained
exponential growth continues to introduce new challenges. One
challenge is a concern within the community that globally unique
address space will be exhausted.
(source: RFC-1918 Address Allocation for Private Internets)
IP addresses from these private IP ranges are not accessible from the internet. Your IP address 192.168.87.235 is part of the class C private ip address range 192.168.0.0/16 hence it is by nature not reachable from the internet.
Furthermore you state yourself that it is working correctly within your local network.
A follow up question to this is: How can I access my network if it's a private network?
To access your local network you need to have a gateway that has both an internal as well as a public IP so that you can reach your network through the public IP. One solution could be to have a DNS name thats mapped to the public IP and is internally routed to the internal load balancer IP 192.168.87.235 with a reverse proxy.
Unfortunately I can't tell you why it is working occasionally because that would require far more knowledge about your local network. But I guess it could i.e. be that you are connected with VPN to your local network or that you already have a reverse proxy that is just not online all the time.
Edit after watching your video:
Your cluster is still reachable from the internet at the end of the video. You get the message "Service unavailable" which is in fact returned by traefik everytime you wish to access a non-healthy application. Your problem is that the demo application is not starting up after you restart the VM. So what you need to do next is to check why the demo app is not starting. This includes checking the logs of the pod and events of the failing pod.
Another topic I'd like to touch is traefik and what it actually does. First to only call Traefik a reverse proxy, while not false,is not the entire truth. Traefik in a kubernetes environment is an ingress controller. That means it is a reverse proxy configured by kubernetes resources, namely by the "Ingress" object or the "IngressRoute" object. The latter is a custom resource introduced by Traefik itself (read here for further informations) because it introduces andvanced options to configure traefik.
The reason I tell you this is because you actually have two ingress controllers installed in your cluster, "Traefik" and "nginx-ingress-controller" and you just need a single one.
How to add TLS/SSL letsencrypt or GCP provided certificate to VM instance in GCP with an internal ip address and static external address?
When I create one via a letsencrpt certificate install script, resultant connections break because the VM doesn't have an external facing ip number --only an internal number.
The traffic passes through a firewall (or load balancer) of sorts.
I'm used to bastionhost VM servers in the wild..
Details: NaviServer web server is running on a GCP Compute Engine with a FreeBSD 11.3 image.
(Linux Shield OSes aren't letting me compile Naviserver and use it on any port).
All works for port 80 and 8000 on an internal ip address, and a static ip address pointed externally and not connected to the VM.
I can't find any proxy/firewall settings to navigate via GCP menus.
How to resolve?
Is there some special term I should use to search for docs?
Any link with instructions to follow?
Is there a way to expose a VM instance directly to an external ip address?
Any other creative way I may get SSL/TLS to work with NaviServer?
thank you
Links to some things I've tried:
Enable SSL on Tomcat on Google Compute Engine
How to setup Letsencrypt for Google Cloud Compute Engine load balancer? <-- this is for Kubernetes clusters
I'm currently trying adding a load balancer:
https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs
This appears to be the solution: Use a GCP HTTP/S load balancer: https://cloud.google.com/load-balancing/docs/https
and specifically:
https://cloud.google.com/load-balancing/docs/https/ext-https-lb-simple
Argh. Actually No.
GCP Team kindly suggested this url: https://cloud.google.com/compute/docs/instances/custom-hostname-vm#create-custom-hostname
Set the hostname to the domain name. Treat this as if there's no proxy, just a firewall.
I have 3 virtual hosts running on my GCE instance and they all require SSL. I can't figure out how to add extra IP address to my instance in order to allow multiple ssl enabled vhosts (apache). The docs say i can do it using protocal forwarding, but im a bit of a GCE novice and cant seem to get it to work. This was pretty straight forward in amazon AWS.
Has anyone done this before? (I do not want to use SNI as we still have some xp users out there)
Thanks
Max
You need to setup a HTTPS load balancer for that https://cloud.google.com/compute/docs/load-balancing/http, the SSL certificate will be attached to the load balancer. Create multiple forwarding rules to map multiple external IPs to the same instance.
We're running a lot of applications in Kubernetes and handle TLS termination inside a pod with HAProxy and a certificate generated with LetsEncrypt.
This works really well for traffic coming from outside the Kubernetes cluster because the requests use the domain name as specified in the certificate.
However for internal communication using the service name - with a url like https:/// - the host part of the url no longer matches what's defined in the certificate, resulting in failure.
Is there any way to let Kubernetes' dns system resolve the full domain name to a specific service, so it doesn't get routed outside the cluster?
I can think of a couple of options that you could pursue:
You could have the requests that transit just the cluster run over http instead of https if you trust the security of your cluster network.
You could have your HAProxy instance serve a different certificate to internal requests using SNI. You would need a way to generate and distribute the internal certificates, but it would allow you to present the client a certificate that matches the Kubernetes service name.
Continue to resolve the FQDN and not worry about routing requests out and then back into the cluster. This actually isn't that different than the upcoming cross-cluster service discovery/federation feature being built into Kubernetes cluster federation.
There isn't really a way to inject/overwrite the external FQDN resolution to return the internal service IP.