Hello, my name is Stuart Scott. And today I should be looking at AWS Secrets Manager to understand how it can be used to help you implement security best practices by protecting your secrets such as database credentials, API keys, and plaintext. By the end of this course, you will understand when and why you might want to use AWS Secrets Manager and how it can be used to effectively enhance your security posture when working with different secrets within your AWS environment.

During this course, I mention the AWS Key Management Service, known as KMS, which is used for the encryption and decryption of data. If you'd like to learn more about the service, then please see our existing course here. It would also be beneficial to have an understanding of IAM policies, but this is not essential. If you have any feedback on this course, positive or negative, it would be greatly appreciated if you can contact support@cloudacademy.com.

Okay, so let's get into it. And I'll start by telling you a little bit about AWS Secrets Manager. Historically when developers were building custom applications to access your databases, they would need to directly embed credentials into the applications, allowing them to authenticate to the database. And this allowed the application to access the database as required. However, when it came to rotating the password, like best practices require, it would also mean you would have to update your custom application with the new credentials. And this is both time consuming and prone to errors, not to mention the security risk. You should always avoid embedding and hard-coding credentials in an application. This problem is alleviated with the introduction of AWS Secrets Manager, a service which allows you to store the secret such as database credentials in a secure store.

Now, when your application needed to access the database, it would simply make an API request to retrieve the required credentials from AWS Secrets Manager, which would then be passed back to your application over a secure channel using HTTPS with TLS, allowing it to authenticate with your database. The benefit is that it removes the need to hard-code credentials into the application, in addition to having AWS Secrets Manager being able to automatically rotate your credentials without having to update your application code with those new credentials.

So we have spoken about using database passwords as a secret. And in fact, AWS Secrets Manager supports RDS, DocumentDB, Redshift and rotates these secrets automatically with backend support from built-in Lambda functions. However, AWS Secrets Manager also supports other types of secrets such as helping you protect API keys and other plaintext data as key/value pairs. When using this option, you can define key-value strings which form the secret itself. When using these types of secrets with rotation enabled, then you'll need to ensure you associate your own custom Lambda function to perform that rotation. The secrets themselves are protected and encrypted using the Key Management Service, KMS. And you can select either the DefaultEncryptionKey, which is an AWS owned CMK, the AWS managed CMK listed as aws/secretsmanager, or your own customer managed CMK.

With this integration of KMS, the encryption backing your secrets are managed by hardware security modules, HSMs, that are validated under FIPS 140-2. Due to the sensitive nature of your secrets, the encryption aspect is crucial, but you can also control access to each individual secret using both fine-grained IAM identity-based policies in addition to resource-based policies. By default, access to secrets are denied until explicitly granted through a policy. Identity-based policies can be attached to users and other identities to govern their permissions to the secret.

Here's an example of an IAM policy allowing an action to be carried out on a secret called cloudacademy_secret in the eu-west-1 region of an AWS account. Resource-based policies are attached directly to the secrets themselves and define which principals can perform which actions against that secret. This can be done using the Management Console or the AWS CLI. This example of a resource-based policy allows the user, Stuart, full access to the secret in which the policy is attached to.

If this policy was created on the AWS CLI and saved as a file called resource.json, then I could use the following command to attach it to a secret called cloudacademy_secret. Another great feature of AWS Secrets Manager is the ability to share secrets between multiple accounts. You might want to do this to have a centralized and managed store of your secrets instead of having multiple stores between different accounts. You can then share your secrets to AWS accounts as and when needed in a secure manner using different policies. To understand how to do this, take a look at our existing course here.

I now want to show you a quick demonstration of how simple it is to create a secret in AWS Secrets Manager. I will create a new secret for an RDS Database with automatic rotation enabled. So let's jump straight into it.

Okay, so as you can see, I'm in my AWS Management Console and the first area I need to go to is to Secrets Manager, which is under the Security Identity & Compliance category here. So if I go to Secrets Manager, and this will open up the Secrets Manager dashboard. At the moment, I don't have any secrets created here.

So the first thing we want to do is to store a new secret. And this takes us to the first step of four in creating our secret. So like I said, I want to create a new secret for my RDS database. And this will be the log on credentials. So we have lots of different options here. So we can use RDS, DocumentDB, Redshift, another type of database or another type of secret. So I'm gonna select RDS.

Now, the username will be Admin, and I'm just going to set a password of My Password. Now here, we can select the encryption key that we want to encrypt the secret with because as we know, by default, all secrets have to be encrypted. So we can use the DefaultEncryptionKey or the AWS managed key here, the aws/secretsmanager. I'll just leave it as a DefaultEncryptionKey for this demonstration.

Now down here, we can select which database that this secret will access. So I'm going to select this one here just called Stuarts database, and click on next. Now we can give the secret name. I'm going to call this My_Secret. And you can add a description if you want to there. Add any optional tags that you'd like to for this particular secret. This element here allows you to add some resource permissions to allow secrets to have cross account access. So this is only optional. We don't really need to do this. And here we can also replicate our secret as well to another region.

So here it says, if you enable secret replication, read replicas of your secret will be created in the specified regions with the same secret name. So if I wanted to replicate my secret to a different region as well, then I can select the relevant region and select an encryption key to go with that and it will, sequence manager when replicate this secret to that other region. But for this demonstration, I don't want to replicate any secrets to other regions. So I'll just de-select that. And then click on next.

Now, here we can decide if we want to configure automatic rotation. By default, it's disabled. But for this demonstration, I'm just going to enable it just to show you how easy it is to set up. Now we can select the number of days when we want the rotation to happen. There's some defaults here, we can customize it. I'll just leave it as 30 days. And the value can be anywhere between one and 365 days.

Now you can let Secrets Manager create a new Lambda function for you to enable this rotation, or you can use an existing Lambda function. So I'm just going to allow it to create a new Lambda function on my behalf to enable that. And if we give the Lambda function and name, let's call it MySecretRDS, and then down here you can just select which secret will be used to perform the rotation. So I'm just gonna leave it as the secret I'm creating now. Then click on next.

So this is just a review screen. We can see the secret type, the RDS database. Using the DefaultEncryptionKey. The name of the secret. We've enabled automatic rotation, one of 30-day interval, and we've disabled the secret replication. Now at the bottom here, we can just see some sample code that illustrates how to retrieve the secret in your application. And then there's lots of different examples of different code there as well. But for now, it just want to store the secret. So just click on store. And we can see here that the secret has now been stored. And when you first store your secret, it performs a rotation immediately. So that's what's happening at the top here. So it's very quick and easy to create a new secrets within Secret Manager that is associated with an existing RDS database.

Obviously, retrieving a secret is just as important as storing it. And there are a number of different ways you can do this. You can programmatically retrieve it via any of your own customer applications using the available AWS SDKs, or you can also retrieve it using the AWS Management Console or the AWS CLI. So let's jump straight back into another demonstration to show you how you can use a couple of these methods. 

Okay, so can the AWS Management Console and at the dashboard of AWS Secrets Manager. And here we can see the secret that we just created. So I just wanted to show you how you can easily retrieve the values of the secret from both within the AWS Management Console and from the AWS CLI. So if I select the secret, we can scroll down to this section here, the secret value, and all we need to do is simply say, retrieve secret value. And as long as you have access to access the secret, then you will get access to view the values within that secret.

So here we can see the username of Admin that we entered and also the password of MyPassword, and also the database host that it relates to as well. So using the Secret Manager Console, it's very easy. So let's now flip over to the AWS CLI to show you how you can retrieve the same value that way as well. So the command we need to type in is AWS Secrets Manager, and then it's get-secret-value using the secret ID. And you can just use the name of the secret that you created So mine was My_Secret, and then just press return. And again, as long as you have access to the secret, then you will get the values.

So here we can see the secret string and we have the username of Admin and the password of MyPassword. And again, we can see the host information database details there as well. Now, before I finish this demonstration, I just want to show you the simple access policy I granted myself to be able to retrieve these values. So if I flick over to identity and access manager, and if I look at my users, I set myself up an inline policy called My_Secret_Access. So let's just take a quick look at that policy.

So it's very simple. It's simply an allow action. So any action lightened as secretsmanager, and then just the ARN of my secret. And obviously, if you're setting up your own security controls, you won't be as open as this, but this is just the quick policy I added just to show you how I've granted myself access to retrieve the value of that secret. And then finally, one last point. If you go back to My_Secret within Secrets Manager. And if you scroll down to the very bottom, it gives you lots of different sample card that shows you how to retrieve the secret from using your own application, whether you're using Java, JavaScript, C#, et cetera, et cetera. So it provides a very quick way just to take some sample code, put it in your own application and quickly retrieve those secrets.

That brings me to the end of this course, which explained how AWS Secrets Manager can be used as a secure method to essentially store your secrets with enhanced security protection features backed by KMS and both identity-based and resource-based policies allowing them to be used within your own account and for cross account access. Management benefits such as automatic rotation also region replication make this a powerful tool to enhance your security posture.

If you'd like to learn more about some of the topics I have mentioned today, such as Identity and Access Management, and the Key Management Service, then please search our library for these services and you will find both courses and labs on these topics to help dive deeper into the understanding. If you have any feedback on this course, positive or negative, then please send an email to support@cloudacademy.com. Your feedback is greatly appreciated. Thank you for your time and good luck with your continued learning of cloud computing. Thank you.