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. 😆
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.
@@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.
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.
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.
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?
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.
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)?
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.
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
@@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.
@@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
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.
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/
![[LIVE] : ONE ลุมพินี 88 | คู่เอก "ป้อมเพชร vs อัสลามจอน"](http://i.ytimg.com/vi/1ZqTVVbMgbo/mqdefault.jpg)
How do you manage your HTTPS certificates? Do you use cert-manager with Let's Encrypt or something else?
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. 😆
Hi Viktor, I used Let's Encrypt in the past when I had to deal with https.
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.
@@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.
@@DevOpsToolkit Argh!!! My bad, for some reason I thought you're configuring your app for TLS, when in fact you're configuring your Ingress.
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.
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.
I have to read this everytime I start looking for a change, and then I forget or mix up. This is greatly explained. Thanks
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.
wow I am new to IT and you really explained these concepts. Thank you so much
only one word: wonderful explanation.. thank you..
Great explanation on HTTPS, thanks.
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?
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.
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)?
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.
Does let's encrypt server as the issuer of root CA? Does it expire? If so, do we need manually to rotate it? @DevOpsToolkit
It does act as issuer and it does expire. If you use certmanager it will automatically renew it.
Amazing video as always :D
Glad you enjoyed!
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
Cert manager only reloads ingress. Any other resource using the certificate in the secret needs to do reloading separately.
Thanks a lot for this awesome video..Would be great to talk about vpn in later videos
Adding it to my TODO list... :)
Slightly off-topic but what kind of impact do you think gRPC would have on k8s in the near future?
Assuming that you're asking about Kubernetes API, I do not think it will support gRPC any time soon :(
@@DevOpsToolkit yes, thank you!
4:04 i thought you can decrypt with public key if message was encrypted with private key ?
You can encrypt with the public key, but not decrypt. Otherwise, given that public key is public, anyone could decrypt anything.
@@DevOpsToolkit if you encrypt with private key, can you decrypt the message with public key?
@@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.
@@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
@@PetrOsetr Its called asymmetric cryptography for a reason
Can we use mtls ?
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.
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/
💯
@@DevOpsToolkit I neglected to mention nice presentation Viktor :-)
Мы используем cert-manager + clusterissuer with LE certs + buyed wildcard SSL для клиентского домена.
you are perfect