<p>Have a look at "Ingress" and "Cert-Manager":</p>

<ul>
<li><p>With a Kubernetes Ingress you can configure the load balancer, see e.g. <a href="https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer" rel="nofollow noreferrer">https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer</a></p></li>
<li><p>With "Cert-Manager" you can get certificates from Let's Encrypt (like certbot does), and it handles renewing automatically. See <a href="https://github.com/jetstack/cert-manager" rel="nofollow noreferrer">https://github.com/jetstack/cert-manager</a></p></li>
</ul>

CC BY-SA 3.0
2018-03-12T14:54:20.117Z
Note that wildcard Let's Encrypt certificates are a very recent offering (I'm not sure if they are generally released) and only available via their ACME v2 API. See https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html.
Dan Cornilescu
CC BY-SA 3.0
2018-03-12T16:02:10.477Z
You're right. I missed to make clear that with cert-manager it might be ok to not use wildcard certificates at all, but just go on like now with certbot. I understood that the need for wildcards was coming from the problem on how to renew certs in a k8s cluster every 3 months ("First impression is that using certbot in the google loadbalancer will not be possible or will be cumbersome..."), and cert-manager solves exactly that problem.
slintes
CC BY-SA 3.0
2018-03-12T16:13:17.373Z
Still, the answer is IMHO valuable as things are definitely moving in the right direction.
Dan Cornilescu
CC BY-SA 3.0
2018-03-12T20:06:07.997Z
@MarcSluiter You used helm as well?
030
CC BY-SA 3.0
2018-03-12T20:11:34.350Z
I'm not using cert-manager myself yet, I'm still using the predecessor project "kube-lego" ;)
slintes
CC BY-SA 3.0
2018-03-12T20:23:17.500Z
Ok. I am now reading https://github.com/jetstack/cert-manager/tree/v0.2.3/docs/api-types/issuer. I wonder where the domains should be defined.
030
CC BY-SA 3.0
2018-03-12T20:31:33.867Z
The domains are in the Certificate resource, see https://github.com/jetstack/cert-manager/tree/v0.2.3/docs/api-types/certificate.

It would be even easier with the "ingress-shim", but I'm not sure if that was already part of the v0.2.3 release. https://github.com/jetstack/cert-manager/blob/master/docs/user-guides/ingress-shim.md
slintes
CC BY-SA 3.0
2018-03-12T20:48:40.033Z
The documentation is not very clear in my opinion. There is a lot of documentation, but how to use a DNS record and how to deploy it. What command should be issued, e.g. `kubectl deploy cert.yaml`. I will try the latter.
030
CC BY-SA 3.0
2018-03-12T20:49:50.877Z
`error: Unexpected args: [cert.yaml]` :(
030
CC BY-SA 3.0
2018-03-12T20:54:20.853Z
20 github tabs are now open in my webbrowser. I will close all, start with the documentation again and try to create the cert.
030
CC BY-SA 3.0
2018-03-12T20:57:53.827Z
kubectl apply -f <yourfile.yaml>
slintes
CC BY-SA 3.0
2018-03-12T21:31:40.863Z
I am already struggling setting up a HTTPS ingress, also the link between the cert and the ingress is not clear to me. I think I should start from scratch upcoming Thursday. Thank you for your help so far. +1
030
CC BY-SA 3.0
2018-03-12T08:50:43.510Z
2018-03-12T08:50:43.510Z
slintes
<p>Let's Encrypt is a free TLS/SSL service you can use with your Kubernetes cluster and a lot of the work is automated. You can setup Kubernetes Cluster to reach out to Let's Encrypt and confirm you are the owner of the domain name and to issue you a cert.</p>

<p>Let's Encrypt will not take the word of your Kubernetes Cluster, but instead make a request to that domain name you supposedly own and if you truly do own it, you will reply. When you respond to that route, you will automatically get a certificate from Let's Encrypt thats going to save it into a secret and make it available to your application. Typically, its good for 90 days and then it will automatically go through this process again.</p>

<p>The challenge for you is setting up the infrastructure to make this happen.</p>

<p>Step 1. You need to purchase a domain name. You can use many different services out there, but I would recommend domains.google.com.</p>

<p>Step 2. You want to set up your domain name by going to your Kubernetes Cluster dashboard in <strong>Services</strong> and then finding the <strong>Ingress service</strong> and thats the IP you will use for your domain name to point to. You are going to click on the <strong>DNS</strong> of the domain name you purchased, look for <strong>Custom resource records</strong> and setup to custom records. The first one will ensure a user who goes to mycluster.com gets forwarded to the IP specified, the second one ensures that a user who goes to www.mycluster.com gets forwarded to the same IP specified.</p>

<p>So you add the <code>@</code> symbol with an <code>A</code> record and a 1 hour time to life which is how long it takes for the record to take effect and the IP address assigned to your Load balancer. No port, just the IP address.</p>

<p>The second record type is <code>C</code> name with <code>www</code>, 1 hour time to life and obviously thats for your <code>www.mycluster.com</code> and thats pretty much it for that.</p>

<p>Step 3. Is setting up your Kubernetes cluster to obtain a TLS certificate.</p>

<p>Step 4. You will have to complete an issuer and certificate config files</p>

<p>Step 5. Deploy your new changes</p>

<p>Step 6. verify the certificate</p>

CC BY-SA 4.0
2019-10-23T16:38:55.827Z
2019-10-23T16:38:55.827Z
Daniel
<p>For using kube-lego you can follow this step:</p>

<p>Visit <a href="https://github.com/jetstack/kube-lego/tree/master/examples/gce" rel="nofollow noreferrer">https://github.com/jetstack/kube-lego/tree/master/examples/gce</a> and follow instructions to have a kube-lego namespace working.</p>

<p>Create an ingress like this:</p>

<pre><code>    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: app-ingress
      annotations:
        kubernetes.io/tls-acme: "true"
        kubernetes.io/ingress.class: "gce"
    spec:
      backend:
        serviceName: backend-service
        servicePort: 80
      tls:
      - hosts:
        - example.com
        - api.example.com
        secretName: app-ingress-tls
      rules:
      - host: example.com
        http:
          path:
          - path: /*
            backend:
              serviceName: backend-service
              servicePort: 443
      - host: api.example.com
        http:
          path:
          - path: /*
            backend:
              serviceName: backend-service
              servicePort: 443
</code></pre>

<p>remember to replace backend-service with your own service name and exampl.com with your domain.</p>

<p>You can put as more host sections as you need, each host section should be associated with a domain on the tls section.</p>

<p>Use the app-ingress-tls secret to mount as a volume on your service.</p>

CC BY-SA 3.0
2018-03-12T23:08:11.423Z
2018-03-12T23:08:11.423Z
wolmi
<p>Currently, certbot and nginx are used to create a trusted webpage. Recently, an attempt was made to move the images to a kubernetes cluster on google cloud platform. A guide was found to configure an SSL loadbalancer. It was tried and it shows multiple textboxes to insert a key, cert and chain.</p>

<p>An attempt was made to see whether Google offers wildcard certs as well, but no information was found. Certbot itself announced last year that they will support wildcard certs, but that does not seem to be the case as well. First impression is that using certbot in the google loadbalancer will not be possible or will be cumbersome as the certs have to be renewed every three months.</p>

<p>When one Googles: <code>cheap wildcard ssl</code> then a lot of results are shown. The questions are which of these providers can be considered as safe, what are the costs and what providers do you use and why?</p>

<kubernetes><ssl><devsecops>
What are trusted providers that offer wildcard certificates and associated costs to be used in an Orchestration Platform like Kubernetes?
030
# What are trusted providers that offer wildcard certificates and associated costs to be used in an Orchestration Platform like Kubernetes?

(Asked by: username_0 on 2018-03-11)

Currently, certbot and nginx are used to create a trusted webpage. Recently, an attempt was made to move the images to a kubernetes cluster on google cloud platform. A guide was found to configure an SSL loadbalancer. It was tried and it shows multiple textboxes to insert a key, cert and chain.

An attempt was made to see whether Google offers wildcard certs as well, but no information was found. Certbot itself announced last year that they will support wildcard certs, but that does not seem to be the case as well. First impression is that using certbot in the google loadbalancer will not be possible or will be cumbersome as the certs have to be renewed every three months.

When one Googles: `cheap wildcard ssl` then a lot of results are shown. The questions are which of these providers can be considered as safe, what are the costs and what providers do you use and why?

**Tags:** kubernetes, ssl, devsecops


---

## 3 answers

### Answer by username_1 on 2018-03-12. Score: 2 | Accepted answer

Have a look at "Ingress" and "Cert-Manager":

* With a Kubernetes Ingress you can configure the load balancer, see e.g. <https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer>
* With "Cert-Manager" you can get certificates from Let's Encrypt (like certbot does), and it handles renewing automatically. See <https://github.com/jetstack/cert-manager>

> **Comments:**
> **username_2**: Note that wildcard Let's Encrypt certificates are a very recent offering (I'm not sure if they are generally released) and only available via their ACME v2 API. See https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html.  
> **username_1**: You're right. I missed to make clear that with cert-manager it might be ok to not use wildcard certificates at all, but just go on like now with certbot. I understood that the need for wildcards was coming from the problem on how to renew certs in a k8s cluster every 3 months ("First impression is that using certbot in the google loadbalancer will not be possible or will be cumbersome..."), and cert-manager solves exactly that problem.  
> **username_2**: Still, the answer is IMHO valuable as things are definitely moving in the right direction.  
> **username_0**: @MarcSluiter You used helm as well?  
> **username_1**: I'm not using cert-manager myself yet, I'm still using the predecessor project "kube-lego" ;)  
> **username_0**: Ok. I am now reading https://github.com/jetstack/cert-manager/tree/v0.2.3/docs/api-types/issuer. I wonder where the domains should be defined.  
> **username_1**: The domains are in the Certificate resource, see https://github.com/jetstack/cert-manager/tree/v0.2.3/docs/api-types/certificate.  It would be even easier with the "ingress-shim", but I'm not sure if that was already part of the v0.2.3 release. https://github.com/jetstack/cert-manager/blob/master/docs/user-guides/ingress-shim.md  
> **username_0**: The documentation is not very clear in my opinion. There is a lot of documentation, but how to use a DNS record and how to deploy it. What command should be issued, e.g. `kubectl deploy cert.yaml`. I will try the latter.  
> **username_0**: `error: Unexpected args: [cert.yaml]` :(  
> **username_0**: 20 github tabs are now open in my webbrowser. I will close all, start with the documentation again and try to create the cert.  
> **username_1**: kubectl apply -f <yourfile.yaml>  
> **username_0**: I am already struggling setting up a HTTPS ingress, also the link between the cert and the ingress is not clear to me. I think I should start from scratch upcoming Thursday. Thank you for your help so far. +1  

---

### Answer by username_3 on 2019-10-23. Score: 0

Let's Encrypt is a free TLS/SSL service you can use with your Kubernetes cluster and a lot of the work is automated. You can setup Kubernetes Cluster to reach out to Let's Encrypt and confirm you are the owner of the domain name and to issue you a cert.

Let's Encrypt will not take the word of your Kubernetes Cluster, but instead make a request to that domain name you supposedly own and if you truly do own it, you will reply. When you respond to that route, you will automatically get a certificate from Let's Encrypt thats going to save it into a secret and make it available to your application. Typically, its good for 90 days and then it will automatically go through this process again.

The challenge for you is setting up the infrastructure to make this happen.

Step 1. You need to purchase a domain name. You can use many different services out there, but I would recommend domains.google.com.

Step 2. You want to set up your domain name by going to your Kubernetes Cluster dashboard in **Services** and then finding the **Ingress service** and thats the IP you will use for your domain name to point to. You are going to click on the **DNS** of the domain name you purchased, look for **Custom resource records** and setup to custom records. The first one will ensure a user who goes to mycluster.com gets forwarded to the IP specified, the second one ensures that a user who goes to www.mycluster.com gets forwarded to the same IP specified.

So you add the `@` symbol with an `A` record and a 1 hour time to life which is how long it takes for the record to take effect and the IP address assigned to your Load balancer. No port, just the IP address.

The second record type is `C` name with `www`, 1 hour time to life and obviously thats for your `www.mycluster.com` and thats pretty much it for that.

Step 3. Is setting up your Kubernetes cluster to obtain a TLS certificate.

Step 4. You will have to complete an issuer and certificate config files

Step 5. Deploy your new changes

Step 6. verify the certificate


---

### Answer by username_4 on 2018-03-12. Score: 0

For using kube-lego you can follow this step:
Visit https://github.com/jetstack/kube-lego/tree/master/examples/gce and follow instructions to have a kube-lego namespace working.
Create an ingress like this:
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: app-ingress
      annotations:
        kubernetes.io/tls-acme: "true"
        kubernetes.io/ingress.class: "gce"
    spec:
      backend:
        serviceName: backend-service
        servicePort: 80
      tls:
      - hosts:
        - example.com
        - api.example.com
        secretName: app-ingress-tls
      rules:
      - host: example.com
        http:
          path:
          - path: /*
            backend:
              serviceName: backend-service
              servicePort: 443
      - host: api.example.com
        http:
          path:
          - path: /*
            backend:
              serviceName: backend-service
              servicePort: 443

remember to replace backend-service with your own service name and exampl.com with your domain.
You can put as more host sections as you need, each host section should be associated with a domain on the tls section.
Use the app-ingress-tls secret to mount as a volume on your service.


---

