- [Instructor] Hello, everyone.
Today, I'll be showcasing how to use
AWS Certificate Manager Private CA, or ACM Private CA,
to issue certificates to Amazon Elastic Kubernetes Service,
or EKS, workloads using the cert-manager plugin.
First, I'll provide an overview of the cert-manager plugin
and the integration between ACM Private CA and EKS.
Then we'll look at a brief demo
of how this integration works in practice.
The Private CA Kubernetes cert-manager plugin
is an opensource plugin for cert-manager
that offers a secure certificate authority solution
for Kubernetes containers.
ACM Private CA is AWS's fully managed
and highly available private CA service,
and cert-manager is a widely adopted solution
for TLS certificate management in Kubernetes.
Customers who use cert-manager
for certificate lifecycle management can use this plugin
with ACM Private CA to improve security
over the default cert-manager CA,
which stores keys in plain text in server memory.
Kubernetes containers and applications
use digital certificates to provide secure authentication
and encryption over TLS.
With this plugin, cert-manager requests TLS certificates
from ACM Private CA, a highly available
and auditable managed CA that secures CA keys
using FIPS-validated hardware security modules,
or HSMs.
Together, cert-manager and the plugin for ACM Private CA
provide certificate automation for TLS
in a range of configurations, including at the ingress,
on the pod, and mutual TLS between pods.
You can use the ACM Private CA
Kubernetes cert-manager plugin
with Amazon Elastic Kubernetes Service,
a self-managed Kubernetes on AWS and Kubernetes on-premise.
If you take a look at this diagram,
you can see there are four different ways to terminate TLS
for applications running on an EKS cluster,
on the load balancer, on the ingress controller,
and directly on the pod.
The fourth way is to use mutual TLS, or MTLS, between pods.
In this demo, I'll show you how to issue a certificate
to terminate TLS on the ingress controller.
You can follow along with the steps in this demo,
as well as dive deeper into other TLS termination options
in the publicly available ACM Private CA workshop.
I put the link to this workshop
in the description of this video.
Be aware that if you run the workshop in your own account,
you will, of course, incur charges
for the services you consume.
Now let's take a brief look at how this works.
Now that we're in the AWS console, let's first take a look
at the resources I've pre-configured for this demo.
I'll navigate to the ACM Private CA console,
where we can see the root and subordinate CAs I've created.
We'll be using this subordinate CA
to issue certificates to our EKS cluster.
Now, if we look at the EKS console,
we can see the Kubernetes cluster, pca-eks-demo,
that has been pre-created in this account.
It has two worker nodes
in a node group named pca-eks-demo workers.
Next, I'll switch to the CLI and use a command
to install the cert-manager add-on to Kubernetes.
This add-on will allow us to automate the management
and issuance of TLS certificates.
Now we need to install the AWS PCA Issuer plugin,
which is an add-on to cert-manager.
First, to do this,
we need to create an OpenID Connect provider
for our cluster.
Now, we'll use eksctl to create an IAM service account
that the PCA Issuer plugin will use.
I'll clear the screen to make it a little more readable,
and then we'll use helm to install the AWS PCA Issuer.
Notice that this command also sets the service account
as the one we created in the previous step.
Now I'll run the get pods command
for the namespace, aws-pca-issuer,
and as you can see, we now have a pod
in the ready state running in the aws-pca-issuer namespace.
Now we will use the AWS PCA Issuer plugin
to create a cluster issuer, which will be used
with the ACM Private CA to issue certificates.
As you can see in the deployment file, we're naming the ARN
of the subordinate CA that I showed earlier in the demo.
I'll use the kubectl apply command to go ahead
and deploy this YAML file.
Okay, now we've set up our EKS cluster
and prepared it to start requesting certificates.
We need to create an ingress controller.
I'll use the following command to install NGINX Ingress.
NGINX Ingress is built
around the Kubernetes Ingress resource using a config map
to store the NGINX configuration.
This command also deploys a network load balancer.
I'll navigate to the EC2 console so we can take a look
at this load balancer that was created.
It's currently in the Provisioning state,
but after a few minutes, it should switch to Active.
We need to copy the DNS name of this load balancer,
as it will be used in our certificate request.
Before we request our certificate,
we'll create a new namespace
that will contain our application
and the secret or certificate that we create.
Next, I'll create a new file called eks-cert.yaml,
where we'll place the information for a certificate request.
Here you can see, I'm placing the DNS name
of that load balancer under the DNS name section
of the certificate request.
We're also naming this eks-cert,
and it uses the namespace we just created
in the previous command.
I'll save this file and exit.
Now we can use the same apply command we've used before
to go ahead and request this new certificate.
Let's use the get certificate command
to check the status of our certificate.
It should show ready.
We can also use the describe certificate command
to see more details about this certificate we requested.
You may notice a few things in the result of this command.
We can see the DNS name of the load balancer
that we put in the certificate request,
as well as the eks-example-domain, common name,
used again in that certificate request from earlier.
We can also see that the certificate status is Ready,
and it is up-to-date and has not expired.
You'll also notice that the key algorithm is RSA
and the key length is 2048.
We specified all this in our certificate request
as part of that eks-cert.yaml file.
Now we simply need to deploy a demo application
and expose this application using our ingress controller.
This will create a basic service that we can expose
via our ingress controller.
I'll create a new file named hello-world.yaml.
Now I'll again use kubectl apply to deploy this new service.
So far, we've issued our certificate
and we've deployed the demo application.
Now we just need to expose this new application
using a Kubernetes Ingress resource.
We'll create a new file called example-ingress.yaml,
and add the following content.
We'll add our load balancer's DNS name
under the tls host and rules host field.
Now we just need to save this file,
and go ahead and apply this resource as well.
Okay, our ingress controller has been created,
and it now has a certificate issued to it
to secure communications with TLS.
And that's it, we've issued a certificate
to our EKS cluster that will be used
to secure communications to our applications using TLS,
with TLS terminating at our ingress controller.
Thanks for your time, and make sure
to consult the ACM Private CA documentation
for more information on issuing certificates
for Kubernetes workloads.