Amazon AWS Certified SysOps Administrator Associate – Security and Compliance for SysOps Part 7

16. [CCP] AWS Certificate Manager Overview (ACM)

Now let’s talk about AWS Certificate Manager or ACM, which is a service to easily provision, manage and deploy SSL or TLS certificates. What do you use the certificates for? Well is to provide inflight encryptions for your websites by providing an Https endpoint. So the second example, we have our application load balancer and it is connected in the backend through Http to an autoscale and group with our EC.

Two instances though, we want our end users to have Https exposed on our application load balancer. So to do so, we’re going to use ACM. And ACM, once it’s connected to our domain, is going to be allowing us to provision and maintain these TLS certificates. They will be loaded onto our application louncer and then automatically the Lobanor will be able to offer Https as an endpoint for our clients, which allows us to get inflight encryption over the public web.

So ACM supports both public and private TLS certificates and it is free of charge for public TLS certificates. There’s also a very nice feature which is automatic TLS certificate renewal, which is very helpful. I use it all the time and it has integration. That means that it loads the TLS certificates on different services. It could be your elastic load balancer, your platform distributions or your APIs on API gateway for example. Okay, so anytime you see web service can help us do info encryption and generate these certificates, then think ACM. That’s it. I will see you in the next lecture.

17. [DVA] AWS Certificate Manager (ACM) Hands On

Okay, so first I’m going to open ACM, also called Certificates Manager in the console. And in here I can see that I can provision certificates and these are public certificates, or I can provision private certificates and they’re a bit more advanced and they’re not in school for the exam. So just remember that ACM can be used to manage public and private. But in this case, we’re just going to deal with public certificates. Okay, we’ll get started here.

We can can either import a certificate if we already had one from before and we just want it to be managed by ACM, or we can even request a public certificate directly from Amazon. So let’s do this. We’ll request a certificate and the domain name is going to be Acmdemo Stefantheteacher. com. We could add as many domain names as we want, but I’ll just keep this one and I own Stefanterteacher. com. It’s in my Route 53.

So that’s perfect. I’ll click on Next and we’ll choose DNS Validation to validate that we do own that domain name because we already have Route 53. So that’ll be very easy. I’ll click on review and say yes. Confirm and request. Okay, so now the validation is in progress. And if I expand this, it says you need to create a CNAME record in your DNS configuration for this to work. Very easy though, we can directly click on Create Record in Route 53 for having AWS create that DNS record for us. So it says, okay, we’re going to add this CNAME with this name and this value. And all these things look very random because this is how SSL verification works. And we’ll say, okay, create. Great. So now the DNS record was written to Route 53 hosted zone and it may take up to 30 minutes for the changes to propagate and it is to validate the domain.

So I click on Next and right now we’re pending validation. So we’ll just pause the video until this is fully completed. Okay, so my certificate has now been issued and so what I’m going to do now is use it. And for this we’ll go to Beanstalk and we’ll try to create an environment that leverages that certificate. So I’m going to do action. Create environment. It’s going to be a web server environment. Click on select and for the domain I’ll just keep the auto generated value and I will choose a node JS and I will choose a sample application, but I will configure more options. And in there I’m going to go the paid route. So I’m going to choose High Availability so that’s a load balancer is provisioned for me. And in the load balancer configuration, I’m going to modify it. I’ll choose an application. Load, balancer. And here I will add listener. So I will add a listener. The port is going to be four, four, three, and the protocol is going to be Https. And this is how we’re going to load a certificate.

So it says, okay, which SSL certificate would you like to load? I would like to load the one that was just provisioned. Scmdemo stefanoju. com. Excellent. And the SSL policy is, how strong do you want your SSL policy to be? I will choose the strongest, which is the very last one. But if you wanted to support older clients like Internet Explorer Five or whatever, you would choose a lower SSL security policy. So in this one, I’ll just choose the highest ELB security policy.

Click on Add and we’re good. Now I can even disable Http if I wanted to, but I’ll just keep it for now. And in terms of the rules, everything looks good. I scroll down. Yeah, everything looks perfect. So let’s go. So this is all my custom configuration, and I’ll create my environment right now. So this is going to create just a very simple Beanstalk application with a load balancer. But now the specificity is that that load balancer should have an SSL certificate on it, and we should be able to access our environment from there. So let’s wait for Beanstalk to be provisioned and then we’ll see what happens. Okay, so my Beanstalk application has been created, as we can see. I can click on this, and we have the congratulations.

And here the URL is definitely not what we want, and it’s also not secure. So what do we have to do? If you remember this course correctly, we would have to create a CNAME record first to have the right domain point to this. So let’s go back to our services. And I’m going to go to Route 53. And in there, I’m going to go to my hosted zone, my domain, click a record set. And this is going to be a CNAME. I think I called my ACM demo for my SSL certificate. So ACM demo stefanother. com and the value of it is going to be this right here. So we have created a CNAME record. And here we go. So now that means that I should be able to access my website using ACM demo Stiffandotcher. com. So let’s have a look and see if that works. ACM demo stiffanderteacher. com.

Okay, here we go. So we have access now to our Beanstalk environment using this URL, but it’s still not secure because right now I only have forced Http, but if I do https boom. Here we go. It works. And we have a little lock here saying the connection is secure. That’s because the SSL certificate gap generated and it’s valid. And if I click here, it’s a Chrome feature. It says that it was issued by Amazon and it is fully working so I can get the details and so on. And it is valid until Saturday, July 25, 2020, and it will be automatically renewed by Amazon in case we need to. So this is really good. That means that ACM did provision our SSL certificates. And finally we can just verify that if we go to here so let’s refresh this. It says that now my certificate is in use and if we go here and see what’s in use by we need to go actually to the ELB service. So we’ll go to EC two console and on our EC Two console I’ll go to my load balancers, find my Beanstalk balancer that was just created, which is one of these two.

So let’s have a look. Is it this one? Let’s see the listeners. No, it’s not this one. Is it this one? Yes it is. So now we can see we have two listeners. We have port 80 and port four four three. And in this case four four three is Https. So we have a security policy that we did apply and we did add the SSL certificate directly from ACM and we can click on view edit certificates if we wanted to, to just change that certificate. So that’s it hopefully really helpful. But in the end we did manage our own application using Beanstalk and Https, which is a cool demo to do. I hope you liked it and I will see you in the next lecture.

18. [SAA/DVA] Secrets Manager Overview

So here is another service in which you can helpfully store secrets in AWS, and that one is called obviously AWS Secrets Manager. So it’s a newer service. It came after the AWS SSM parameter store was out. And really the sole purpose of Secrets Manager is to be storing secrets. So the difference between Secrets Manager and the parameter store is that Secrets Manager is more oriented towards secrets and it has a capability to force the rotation of your secrets every x number of days. There is also the capability to automate the generation of secrets on the rotation.

So it uses database lambda for this integration. On top of it, you can integrate Secrets Manager with RDS to synchronize your secrets between your databases and Secrets Manager. The secrets are obviously encrypted and you can encrypt it using Kms. So when you go into the exam, anytime you see secret storing rotation of secrets integration with RDS, think Secrets Manager. It’s a really simple service. And in the next lecture we’ll go see in the hands on how it works.

19. [SAA/DVA] Secrets Manager Hands On

So now let’s look into a service called Secrets Manager. And the name is extremely obvious for one of the services that will be easily storing secrets into AWS. And so with this you can rotate them, manage them, and you retrieve them with API calls for their lifecycle. So the big difference of Secrets Manager you’ll have with something like Parameter Store with an encrypted value like the secure string, is that with Secrets Manager you can set up some rotation and you can link it to a lambda function that will allow you to rotate your credentials on top of it. It has a very tight integration with RDS, Aurora, Postgres and so on. And so the idea is that it will be a little bit more easy to use and more secure with this. But the idea is the same.

You are going to store secrets into a store and retrieve them at runtime. So the pricing is that you have forty cents per secrets per month and $0. 05 for 10,000 API calls and you get a 30 day free trial available for the Secrets Manager. Okay? So it’s all obviously managed by Im for access to the secrets. So this is kind of like a similar thing to Parameter Store. So let’s go ahead and store a new secrets. And so, as you can see, we get different type of secrets. And I’m pretty sure they will add secrets over time to make this even more integrated with other AWS services, where we can do a Credential for an RDS database, a Credential for Redshift Cluster for a document DB database for another database, or an other type of secrets. And this is, for example, an API key.

So here this is really important. Whenever you have a database, it will prompt you with a username and a password and pretty much a username and password for everything here. Okay? But if it’s an other type of secret, then you will have key value pairs that you can place. And you would have secrets placed in here. So you can say, for example, API key, and then you would have the secret value of the API key, right? And this would be your keyed value pair, but you could have multiple ones. You can just store, not just one API key. You could store, for example, secret key for the API and you have a second value, a secret secret value, right? So you’re really free to have as many key value pairs. And that’s also a little bit of a difference versus something like the Parameter Store.

So you can do this in secret, or you can also do it in plain text in your passing JSON. So this would be a way to copy and paste a JSON. If you prefer this to entering things manually in this UI, then you select the encryption key. So do you want a default encryption key or do you want to use the Kms key? You have created and so on to encrypt these secrets. So I’ll use my Kms key, for example, and then I’ll click on next. Then you need to give your secret a name. So I’ll call it prod my secret API. And then you can have a description, you can have tags, and then you click on next.

And then here we can configure automatic or not automatic rotation. So that means that if you have automatic rotation automatically, your secrets will be rotated. And so that means that, for example, here I can say every 60 days I want you to rotate my secret. But you can have a custom value if you wanted to, the max being one year. And so that means that after 60 days there will be a lambda function that will be invoked. And so you need to create that lambda function. And that lambda function needs to have the role to rotate that secret. So that means for example, generating a new username or refreshing the API key credentials with a third party.

And so you’re free to do whatever you want with your lambda functions. But the idea is that after 60 days it will be invoked automatically by Secrets Manager to rotate the secret we have just stored. And that makes it a really powerful secret management solution. So right now I’ll disable the automatic rotation and I’ll click on next and so we are good to go. And we can have simple code in any of the languages that we commonly use to retrieve that secret. For example, with Python, if we look at it, there’s a get secret function and you pass in the secret name, the region name, and then you just initiate a boto client to do API calls. And then to get the value you do client get secretvalue, you’re passing the secret ID, which is the secret name, and then you get the response. And in the response then you can just look at the keys that you need. For example, in the key value pair we had and here secret string is the value of the key you want to retrieve.

And that’s it very, very fairly simple. And you have this for the language you are. So if you’re more of a go person here’s go JavaScript, Java and so on, okay? And that’s as easy as it is to use the Secrets Manager. And so this is just a normal key value pair secret. And let me just show you how to do an RDS database. So I’ll call this admin and then super secret password and then we would encrypt those as well. And similarly you can also link this to an RDS database that the secret will access. So the idea is that with these special integration with RDS or Redshift or document DB, you would have to select a database to integrate this with.

So that makes it a little bit more powerful because now the Secrets Manager will hold the value of the username and the password. But on top of it, it will also set these values on the linked RDS database automatically. And you can also enable rotation as well to make sure that the secret rotates every so often. So this one is just to show show you this. But you are not going to create an RDS database just for the sake of linking the secret to it. But you get the idea. So that’s it in a nutshell for Secrets Manager. When you’re done, you can just delete that secret and you’ll be good to go. And you can have a waiting period as well, just to make sure that it doesn’t get updated, deleted hastily. So that’s it for this lecture. I hope you liked it and I will see you in the next lecture.

20. [DVA] SSM Parameter Store vs Secrets Manager

So let’s talk about the differences between the SSN parameter Store and secrets Manager. So, Secrets Manager is more expensive and you’re going to have the automation of the rotation of the secrets using lambda functions. Some of these lambda functions are going to be provided out of the box. For example, for RDS, for redshift or Documentb that have strong integrations with Secrets Manager. So it saves you a little bit of time. Kms encryption is going to be mandatory for your secrets and you can integrate them with cloud formation. The Parameter Store has more as a wider type of use case and is less expensive. It has a simple API. There is no secrets rotation, although I will show you in the next slide how you can enable rotation on your own using a lambda function triggered by CloudWatch events. But this is not a nature feature.

Kms encryption is going to be optional because you can store secrets or just parameters in the Parameter Store and it also has integration cloud formation and it is possible for you to pull a Secrets Manager from a secret from Secrets Manager using the SSM Parameter Store API. This is a bit of a so if we would look at rotation of secrets between the Parameter Store and Secrets Manager. Well, first for Secrets Manager, say we want to rotate the password of an Amazon RDS database. Therefore we are going to set up Secrets Manager to automatically invoke every 30 days a lambda function. Now this ladder function for example for RDS is provided by AWS and is deployed in your accounts by AWS.

You just need to use it using Secrets Manager. What it will do is that it will change the password of your Amazon RDS database. So this is a nature functionality and in case it is just a random secret that is not deeply integrated with Secrets Manager, then you need to write your own lambda function for it. But again, the documentation is provided by AWS. Now for the SSM Parameter Store there is no nature feature to the rotation.

But let’s say you were storing an RDS database password into the SSM Parameter Store. Then what I would do is to create a CloudWatch event rule that would be invoked every 30 days and that will invoke a lambda function that you would have to write on your own to change the password of your armies and RDS database and also to change the value that is stored in your SSM Parameter Store. So hopefully that makes sense into what are the differences between the Secrets Manager and the SSM Parameter Store? I hope you like this lecture and I will see you in the next lecture.