I am running a web service that can be accessed from my company's domain name.
I have setup automatic SSL certificates with Lets Encrypt as seen below.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: basic-ingress
annotations:
certmanager.k8s.io/issuer: letsencrypt
spec:
tls:
- hosts:
- my.domain.net
secretName: my-domain-net-tls
rules:
- host: my.domain.net
http:
paths:
- backend:
serviceName: frontend-service
servicePort: 80-to-8080-tcp
I want to offer clients the option of serving the frontend from their own domains.
What is the best way to go about this with certificates?
I understand that I can setup the load balancer to use multiple secrets as shown here: https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-multi-ssl,
but I will need to be serving from more than the stated max of 10 domains.
Is there a more efficient way to go about this? What's the industry standard for serving one frontend service from multiple domains?
Many thanks!
The standard method to support more than one domain name and / or subdomain names is to use one SSL Certificate and implement SAN (Subject Alternative Names). The extra domain names are stored together in the SAN. All SSL certificates support SAN, but not all certificate authorities will issue multi-domain certificates. Let's Encrypt does support SAN so their certificates will meet your goal.
What is a SAN Certificate?
If you don't require a global IP and can do with a regional one you can install the nginx-ingress and use multiple ingress to handle multiple domains and certificates for the same IP.
If you do require a global IP you can do as suggested by #John.
And if you don't mind having your clients pointing their domains to the different IPs as you do you can just use different ingress without anything more. But be aware that the normal ingress on GKE instantiates a L7 global load balancer so consider the cost of doing this
Related
I'm missing some form of configuration/knowledge when configuring an ingress through Helm for a chart.
I want to enable TLS for an existing chart which has the following values:
ingress:
enabled: false
annotations: {}
# kubernetes.io/ingress.class: nginx
# kubernetes.io/tls-acme: "true"
path: /
hosts:
- chart-example.local
tls: []
# - secretName: chart-example-tls
# hosts:
# - chart-example.local
From what I've read on the Traefik docs you can't use LetsEncrypt certificates in k8s secrets:
Only TLS certificates provided by users can be stored in Kubernetes Secrets. Let's Encrypt certificates cannot be managed in Kubernets Secrets yet.
What are my options here, do I overwrite the ingress and potentially mess with future helm upgrades or is annotations the way to go? If so an example would be great.
Only TLS certificates provided by users can be stored in Kubernetes
Secrets. Let's Encrypt certificates cannot be managed in Kubernets
Secrets yet.
It was discussed few times here, on stack. Maybe it will help you.
The most recommended solution is to use cert-manager instead of LetsEncrypt.
1. Traefik Ingress (Kubernetes) not receiving letsencrypt certificates
2. Let's Encrypt on Traefik with Helm
Also here is How to easily(ish!) get SSL/TLS configured for your web hosting needs using Traefik and cert-manager on Kubernetes article for you that shows everything is in details.
Is it possible to configure SSL redirection (forcing https over http) with Google Ingress and Managed certificates in GKE ?
If yes, then how ?
This documentation doesn't mention it:
https://cloud.google.com/kubernetes-engine/docs/how-to/managed-certs
For now there is no way to force redirection to the SSL version of sites when using the GCE ingress class. However, there are feature requests to make this possible in the future.
If you need this feature you can either, do the automatic redirection directly in the backend rather than the ingress or, you can use another ingress class, such as Nginx, with support for this feature.
Alternatively, you can disallow HTTP using an ingress annotation, leaving only HTTPS available.
Under annotation section of GKE Ingress yaml, try using force-ssl-redirect
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: gke-ingress-test
annotations:
ingress.kubernetes.io/ingress.static-ip: gke-ingress-test-stat-ip
networking.gke.io/managed-certificates: "domain1,domain2"
ingress.gcp.kubernetes.io/pre-shared-cert: "domain3,domain4"
ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
rules:
I am trying to setup Traefik on Kubernetes with Let's Encrypt enabled. I managed yesterday to retrieve the first SSL certificated from Let's Encrypt but am a little bit stuck on how to store the SSL certificates.
I am able to create a Volume to store the Traefik certificates but that would mean that I am limited to a single replica (when having multiple replicas am I unable to retrieve a certificate since the validation goes wrong most of the times due to that the volume is not shared).
I read that Traefik is able to use something like Consul but I am wondering if I have to setup/run a complete Consul cluster to just store the fetched certificates etc.?
You can store the certificate in a kubernetes secret and you reference to this secret in your ingress.
spec:
tls:
- secretName: testsecret
The secret has to be in same namespace the ingress is running in.
See also https://docs.traefik.io/user-guide/kubernetes/#add-a-tls-certificate-to-the-ingress
You can set up the ingress with controller and apply for the SSL certificate of let's encrypt.
You can use cluster issuer to manage the SSL certificates and store that tls certificate on ingress.you can also use different ingress controllers like nginx also can use service mess istio.
For more details you can check : https://docs.traefik.io/user-guide/kubernetes/
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 have a pod that serves HTTPS traffic on 443 using a self-signed certificate with a CN of app that matches the service name, app. It also serves HTTP on 80.
I also have an Ingress object that exposes the pod externally on foo.com and I use kube-lego to dynamically fetch and configure a LetsEncrypt certificate for foo.com:
spec:
rules:
- host: foo.com
http:
paths:
- backend:
serviceName: kube-lego-gce
servicePort: 8080
path: /.well-known/acme-challenge/*
- backend:
serviceName: app
servicePort: 80
path: /*
tls:
- hosts:
- foo.com
secretName: app-tls-staging
This means there are two levels of SSL. If I set the servicePort of the Ingress to 443 to ensure traffic between Google's LB and my pod is encrypted, the endpoint returns 502 Server Error. Is this because it doesn't know to trust my self-signed cert? Is there a way to specify a CA?
Once I set it back to 80 the Ingress starts working normally again after a few minutes.
What you're looking for is "re-encryption" for Load Balancer <=> cluster traffic. If you see here, re-encryption is listed as "Future Work".
But I see this feature is merged: https://github.com/kubernetes/ingress/pull/519/commits
It looks like you can find an example here and it's described as "Backend HTTPS" in this document: https://github.com/kubernetes/ingress/tree/master/controllers/gce#backend-https
However today this feature seems to be in alpha, so it may be subject to change and you may need to create an alpha GKE cluster (which is short-lived) to use it.