What Is HTTPS? How Does It Work? Automate With cert-manager And Let's Encrypt

Sdílet
Vložit
  • čas přidán 12. 06. 2024
  • There's no excuse for anyone not to use HTTPS.
    Learn how to automate HTTPS with cert-manager running in Kubernetes and Let's Encrypt in this video.
    #cert-manager #letsencrypt #https
    Consider joining the channel: / devopstoolkit
    ▬▬▬▬▬▬ 🔗 Additional Info 🔗 ▬▬▬▬▬▬
    ➡ Gist with the commands: gist.github.com/8c42a986668fd...
    🔗 cert-manager: cert-manager.io
    🔗 Let's Encrypt: letsencrypt.org
    ▬▬▬▬▬▬ 💰 Sponsoships 💰 ▬▬▬▬▬▬
    If you are interested in sponsoring this channel, please use calendly.com/vfarcic/meet to book a timeslot that suits you, and we'll go over the details. Or feel free to contact me over Twitter or LinkedIn (see below).
    ▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬
    ➡ Twitter: / vfarcic
    ➡ LinkedIn: / viktorfarcic
    ▬▬▬▬▬▬ 🚀 Other Channels 🚀 ▬▬▬▬▬▬
    🎤 Podcast: www.devopsparadox.com/
    💬 Live streams: / devopsparadox
    ▬▬▬▬▬▬ ⏱ Timecodes ⏱ ▬▬▬▬▬▬
    00:00 Introduction To HTTPS (HTTP with TLS/SSL)
    09:17 Applications Without HTTPS Access
    11:28 Enable HTTPS Access Through cert-manager And Let's Encrypt
    Corrections:
    15:18 Actually, it's not one more thing missing but another way to get a certificate. We can do it through annotations in Ingress manifests.
    15:32 It's not a label as presented here but an annotation.
  • Věda a technologie

Komentáře • 41

  • @DevOpsToolkit
    @DevOpsToolkit  Před rokem +2

    How do you manage your HTTPS certificates? Do you use cert-manager with Let's Encrypt or something else?

    • @lilbitsquishyv2613
      @lilbitsquishyv2613 Před rokem

      yes we use exectaly this setup. I think exposing services with https was never easier than with kubernetes and cert-manager. When I first learned about it I was blown away how nice and easy it makes your life. 😆

    • @GM-qv1ql
      @GM-qv1ql Před rokem

      Hi Viktor, I used Let's Encrypt in the past when I had to deal with https.

    • @fanemanelistu9235
      @fanemanelistu9235 Před rokem +1

      Isn't https slower than http? Why not put the entire cluster behind a gateway, secure the gateway, and then let the apps in the cluster talk http? That would be faster and as secure.

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem +3

      @@fanemanelistu9235 that's what is happening in Kubernetes. Requests are coming through an external load balancer into the cluster and ingress is forwarding them to a specific service associated with the requested app. That part is public facing and should use https. From there one, apps communicate with each other through Kubernetes services that do not use https by default. Now, if that is not secure enough (and it often isn't), you can use mutual TLS (mTLS) through, let's say, a service mesh. Nevertheless, this video explores only the first part. Cert manager secures only the external traffic. Or, to be more precise, it can be used internally as well, but that not necessarily a good solution.

    • @fanemanelistu9235
      @fanemanelistu9235 Před rokem +1

      @@DevOpsToolkit Argh!!! My bad, for some reason I thought you're configuring your app for TLS, when in fact you're configuring your Ingress.

  • @Bloome_BlueFolf
    @Bloome_BlueFolf Před rokem +7

    I think since the 3 years I deal with IT THAT is the best and most understandable explaination about the topic I have seen so far.

  • @Naldjei3396
    @Naldjei3396 Před 2 měsíci +1

    Hi! I think that would be important to clarify that, unlike the public and private key assymetric system, you can, with the same session key, both encrypt and decrypt data - you encrypt data with the session key, sends to server, and the server decrypt the received data with the same session key.
    I was a bit confused with that since its said in the beginning of the video that you can't decrypt data with the same key you encrypted it. Things got clear when i remembered that I read somewhere that you start HTTPs with assymetric keys and then use symetric keys, but at the time I got confused.
    Now both the article I read days ago and your video are fully clear.
    Thanks for you videos! You really know how to explain complex subjects in a simple and understable way.

  • @JaydeepDave12
    @JaydeepDave12 Před rokem +1

    I have to read this everytime I start looking for a change, and then I forget or mix up. This is greatly explained. Thanks

  • @emmaaudu3461
    @emmaaudu3461 Před rokem +1

    wow I am new to IT and you really explained these concepts. Thank you so much

  • @GM-qv1ql
    @GM-qv1ql Před rokem +1

    Hi Viktor, thanks for this helpful video. I have used Let's encrypt once in the past but the app wasn't on k8s, so this is a good learning for me on how to do it on k8s.

  • @xDavidhjx
    @xDavidhjx Před rokem +1

    Great explanation on HTTPS, thanks.

  • @mehmetkaraday4972
    @mehmetkaraday4972 Před 9 měsíci

    only one word: wonderful explanation.. thank you..

  • @avinashnadendla7869
    @avinashnadendla7869 Před rokem +1

    Amazing video as always :D

  • @Palex1990
    @Palex1990 Před 5 měsíci +1

    Very nice video thank you! I have a question. Lets say I have a three node cluster (RKE2) and want to use for my app (rancher UI) an external loadbalancer. Can I use the certmanager when I have an external lb? What I found is that I have to hand some certificates to the nginx.conf of the external lb. How do these two different things work together?

    • @DevOpsToolkit
      @DevOpsToolkit  Před 5 měsíci +1

      If you configured your external proxy to be a passthrough to that certs can be terminated inside the cluster, you'll need certs only inside the cluster.

  • @yassinemessaoud8619
    @yassinemessaoud8619 Před rokem +1

    Thanks a lot for this awesome video..Would be great to talk about vpn in later videos

  • @rubenfernandez9603
    @rubenfernandez9603 Před rokem +1

    I finally understood how https works. Thank you!
    how do you handle with cert-manager requesting internal certificates (services with that are not exposed to internet)?

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem

      I think it's easier (and better) to use mTLS for that through a service mesh. Istio, LinkerD, and others will add it automatically for all internal communication.

  • @vn7057
    @vn7057 Před rokem +1

    Things like Nginx Ingress it does able to make reload when things got update
    but for other (such like Hashicorp Vault) it might require using 3rd party tools like reloader
    when cert/secret get update it tigger the rolling restart the sts
    Do cert manager new version solve the issue or Do you find a good way ? But i things it really depend on the Particular Software design
    Or we should always put Ingress/Gateway before the Application even itself expose the web page

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem

      Cert manager only reloads ingress. Any other resource using the certificate in the secret needs to do reloading separately.

  • @GM-qv1ql
    @GM-qv1ql Před rokem +1

    Slightly off-topic but what kind of impact do you think gRPC would have on k8s in the near future?

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem

      Assuming that you're asking about Kubernetes API, I do not think it will support gRPC any time soon :(

    • @GM-qv1ql
      @GM-qv1ql Před rokem +1

      @@DevOpsToolkit yes, thank you!

  • @PetrOsetr
    @PetrOsetr Před rokem +1

    4:04 i thought you can decrypt with public key if message was encrypted with private key ?

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem

      You can encrypt with the public key, but not decrypt. Otherwise, given that public key is public, anyone could decrypt anything.

    • @PetrOsetr
      @PetrOsetr Před rokem +1

      @@DevOpsToolkit if you encrypt with private key, can you decrypt the message with public key?

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem +1

      @@PetrOsetr I never tried that combination so I'm not 100% sure when I say that the answer is no. The point of public keys is that they are public (available to anyone) and everyone being able to decrypt something does not sound like a desirable feature.

    • @PetrOsetr
      @PetrOsetr Před rokem +1

      @@DevOpsToolkit I agree, just wanted to point that out since you should never encrypt stiff with your private key if you're not ready that it could be decrypted with public 😁
      Also I think ca might use this since you have their public key and if you can decrypt cert that means that it was encrypted exactly by them. Need to refresh my memory on this though

    • @user-mf6jh7jo9q
      @user-mf6jh7jo9q Před rokem +2

      @@PetrOsetr Its called asymmetric cryptography for a reason

  • @abhipsnl
    @abhipsnl Před rokem +1

    Can we use mtls ?

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem +2

      mTLS is used for internal communication. It assumes that both parties have the private key so tools like service meshes inject the keys to all endpoints. You cannot do that for public communication since, for example, that would mean that a browser accessing your services has a private key.
      In other words, use HTTP with TLS (HTTPS) for external-facing communication and mTLS for internal.

  • @user-gj8br7kw5h
    @user-gj8br7kw5h Před 3 měsíci +1

    you are perfect

  • @whooo71
    @whooo71 Před rokem +1

    Мы используем cert-manager + clusterissuer with LE certs + buyed wildcard SSL для клиентского домена.

  • @srgpip5620
    @srgpip5620 Před rokem +1

    With regards to cert-manager I would recommend employing DNS01 over HTTP01 as there can be a case whereby a race condition may develop where ingress attempts to deploy a service to satisfy HTTP01 ACME challenge which competes with the actual underlying service that the cert is being requested for.
    This can cause the challenge to spin since the challenge is never satisfied and no cert will be issued. It should also be noted that the request needs to happen on port 80.
    I find DNS01 challenges more robust if only slightly more challenging to automate and configure. The trick is granting access / perms to your dns system (AWS Route53) within kind: ClusterIssuer.
    DNS01 ACME challenge creates a DNS entry in your DNS for the given domain, be able to create this record satisfies the challenge and the cert is issued.
    It should also be noted that while testing use lets-encrypt staging since there are rate limits on lets-encrypt production. letsencrypt.org/docs/rate-limits/