Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-12T14:54:20.117Z
Answers: 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.
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2018-03-12T16:02:10.477Z
Answers: 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.
Answers: slintes
Answers: CC BY-SA 3.0
Answers: 2018-03-12T16:13:17.373Z
Answers: Still, the answer is IMHO valuable as things are definitely moving in the right direction.
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2018-03-12T20:06:07.997Z
Answers: @MarcSluiter You used helm as well?
Answers: 030
Answers: CC BY-SA 3.0
Answers: 2018-03-12T20:11:34.350Z
Answers: I'm not using cert-manager myself yet, I'm still using the predecessor project "kube-lego" ;)
Answers: slintes
Answers: CC BY-SA 3.0
Answers: 2018-03-12T20:23:17.500Z
Answers: 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.
Answers: 030
Answers: CC BY-SA 3.0
Answers: 2018-03-12T20:31:33.867Z
Answers: 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
Answers: slintes
Answers: CC BY-SA 3.0
Answers: 2018-03-12T20:48:40.033Z
Answers: 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.
Answers: 030
Answers: CC BY-SA 3.0
Answers: 2018-03-12T20:49:50.877Z
Answers: `error: Unexpected args: [cert.yaml]` :(
Answers: 030
Answers: CC BY-SA 3.0
Answers: 2018-03-12T20:54:20.853Z
Answers: 20 github tabs are now open in my webbrowser. I will close all, start with the documentation again and try to create the cert.
Answers: 030
Answers: CC BY-SA 3.0
Answers: 2018-03-12T20:57:53.827Z
Answers: kubectl apply -f <yourfile.yaml>
Answers: slintes
Answers: CC BY-SA 3.0
Answers: 2018-03-12T21:31:40.863Z
Answers: 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
Answers: 030
Answers: CC BY-SA 3.0
Answers: 2018-03-12T08:50:43.510Z
Answers: 2018-03-12T08:50:43.510Z
Answers: slintes
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-10-23T16:38:55.827Z
Answers: 2019-10-23T16:38:55.827Z
Answers: Daniel
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-12T23:08:11.423Z
Answers: 2018-03-12T23:08:11.423Z
Answers: wolmi
Body: <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>
  
Tags: <kubernetes><ssl><devsecops>
Title: What are trusted providers that offer wildcard certificates and associated costs to be used in an Orchestration Platform like Kubernetes?
UserDisplayName: 030
ThreadText: # 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.
  
  
  ---
  
  