Welcome to this lecture which will provide a high-level focus on the AWS Secrets Manager service in addition to providing a demonstration on how to share secrets between multiple accounts.

Firstly, what is considered a secret? A secret in this instance can be passwords, third party API keys, database credentials on Amazon RDS or redshift clusters, or simply plain text. Essentially, it's typically something that you want to remain hidden from the open world.

AWS Secrets Manager is a great service to enhance your security posture by allowing you to remove any hard-coded secrets within your application and replacing them with a simple API call to the aid of your secrets manager which then services the request with the relevant secret. As a result, AWS Secrets Manager acts as a single source of truth for all your secrets across all of your applications.

AWS Secrets Manager enables the ease of rotating secrets and therefore enhancing the security of that secret. An example of this could be your database credentials. Other secret types can also have automatic rotation enabled through the use of lambda functions, for example, API keys. 

Being an enhanced security service, it also offers integration with other key AWS services such as KMS, the Key Management Service which is used to encrypt your secrets within AWS Secrets Manager. AWS CloudTrail on Amazon CloudWatch can be used to monitor the activity of your secrets, for example, when an API call is triggered to rotate a secret, CloudTrail will log this detail and cloud watch can be configured to report on this deletion through the use of CloudTrail logs and then notify your team. This provides full visibility and auditing capabilities as well as notification of any unexpected behavior, for example, a deletion of one of your secrets.

Access to your secrets within AWS Secret Manager is governed by fine-grained IAM identity-based policies in addition to resource-based policies. Identity-based policies are attached to identities that have been created within the IAM service and associated specific permissions to their identity. Resource-based policies are attached to an individual resource instead of an identity.

Now I've covered some of the high-level details of AWS Secrets Manager, let me now focus on how 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.

I will now perform a demonstration to show you how to manage and control access to a secret in Secrets Manager between two separate accounts. Let me call these my primary account and my secondary account. My primary account will be used to house the secret and the secondary account will have an IAM user who will retrieve the secrets from the primary account. 

For this demonstration, I already have an existing KMS key and secret created within the primary account and an IAM user named Stuart in the secondary account.

I shall follow these steps: firstly, I'll start by identifying the ARNs of both the secret and the KMS key as these will be needed through the configuration, I will then login to the secondary account to find the ARN of the IAM user Stuart, from here, I will add an in-line policy to the user allowing access to retrieve the value of the secret as well as access to decrypt the KMS key using the following policy.

{

  "Version" : "2012-10-17",

  "Statement" : [

{

   "Effect": "Allow",

   "Action": "secretsmanager:GetSecretValue",

      "Resource": "ARN OF SECRET"

},

{

   "Effect": "Allow",

   "Action": "kms:Decrypt",

      "Resource": "ARN OF KMS KEY"

}

  ]

}

I will then log back in to the primary and edit the key policy of the KMS key allowing KMS decrypt access for the user Stuart using the following policy.

{

   "Sid": "AllowUseOfTheKey",

   "Effect": "Allow",

   "Principal":

           {"AWS": "ARN OF STUART"},

   "Action": [

   "kms:Decrypt",

   "kms:DescribeKey"

],

   "Resource": "ARN OF KMS KEY"

}

Using the AWS CLI credentials of an admin in the primary account, I'll add a resource- based policy to the secret in the primary account allowing the user Stuart access to retrieve the secret value using the following policy.

{

  "Version" : "2012-10-17",

  "Statement" : [

	{

  	"Effect": "Allow",

      "Principal": {"AWS": "ARN OF STUART"},

  	"Action": "secretsmanager:GetSecretValue",

      "Resource": "*",

      "Condition": {"ForAnyValue:StringEquals": {"secretsmanager:VersionStage": "AWSCURRENT"}}

	}

  ]

}

Finally, I will test access by attempting to retrieve the values of the secret using the credentials of the user Stuart from the AWS CLI using the following command.

aws secretsmanager get-secret-value --secret-id ARN OF SECRET --version-stage AWSCURRENT

Ok, let's take a look. Ok, so I'm starting off in my primary account where I have my AWS secret that's already created and also my AWS KMS key. So, let's go ahead and take with both of those. So if I take a look at my KMS key first. Go to Key Management Service. I can see here that I have my key and this is the key that I'll be using, so if I select that we can take a note of the ARN here so you need to make sure you have the ARN of your KMS key to hand when you're doing this configuration.

Now, if I go across to Secrets Manager, now here we have my list of secrets and the secret that we're going to be using is MySecret. Now, here again we have the ARN of the secret and we need to have that to hand. Now, the values of the secret is simply a username key with the value of Alice and the password key with the value of password1. So they are the details that are contained within this secret but like I say, for this configuration, what we need is the ARN of the KMS key and also the ARN of the secret that we're going to be using. And this secret is encrypted with the KMS key that we looked at just now, MyKey.

Okay, so now we have those ARNs, what I need to do now is go across to my secondary account where the IAM user Stuart exists, so let me flip over to that account now. Okay, so I'm now in my secondary account so I want to go across to the IAM service first to look at my user. If I go down to users and select my user which is Stuart. Now, once we're looking at this user, we also need to make a note of the ARN of this user as well as we're going to need that going forward.

Now, from here I want to add an inline policy, so if I go across to to add inline policy here, and I'm gonna paste in a JSON version of the policy. So we just paste that in. So this does two things, this policy. Firstly, it allows this user which is Stuart access to get the secret value from this secret and this is the ARN of the secret from our primary account. Now, the second section here also allows access to KMS decrypt of our KMS key, so this user will also need to be able to have decrypt access to the KMS key that is used to encrypt the secret. So if you're setting this up in your own account, you'll need to ensure you have the right ARN in there for your secret and also the ARN of your KMS key in here.

Okay, click on review policy and then give this policy a name and then create policy. Okay and we can now see that we have the inline policy attached here—I call it Secret. Okay, so now what I need to do is go back to the primary account and edit the key policy of this KMS key. So let me flick back to our primary account. Okay, so I'm back at the primary account. Let me go over to KMS. Now, I need to edit the key policy because, although I've allowed decrypt access for the user, I still need to edit the key policy to ensure that the key policy of that KMS key allows that user to use it.

So now I'm in the KMS key, if I switch down to switch to policy view and then go to the key policy and I select edit, I need to paste in a new section, so let me just add that under the access for key administrators. Let me just put it in here. Okay, so this is the section I just pasted in. So what this does it allows the use of the key for this user here and this is the ARN of the IAM user in the secondary account, Stuart, and it allows these actions KMS Decrypt and DescribeKey and again is the resource of the KMS key. So, although we allowed KMS Decrypt on the inline policy of the actual user itself, we also need to add those permissions within the key policy of the KMS key itself. So if you save those changes.

Okay, so the next part what I need to do is create a resource based policy and attach this to the secret. Now, currently, that's not something you can do from within the AWS management console, so we need to use the AWS CLI for this. So let me jump across to the terminal. Now, I've already created a JSON file for this. So let me just show you that quickly. I've called it resource.JSON and we can see here that it's a very simple policy. Now, all this does, it allows the IAM user Stuart to get the secret value of the secret that I'm going to apply it to. So let me just go back.

Okay and the command to attach this policy is as follows. So the command is aws secretsmanager put-resource-policy --secret-id and then the name of the secret that we have which is MySecret, and then --resource-policy, file, and then the name of the file that contains the JSON policy that we want to attach. Okay, that is now attached. So now what we want to do is to test the access. So, so far, what we've done we have our KMS key created. We have our secret key created. And that secret is encrypted with the KMS key.

We have our user in the secondary account and we've added an inline policy that allows that user to get a secret value and also decrypt the KMS key. We've updated the KMS key policy to allow that same user that decrypt access and now we've just added a resource-based policy that allows the user to get the secret value of the secret and return that value. Now, to test that access, we enter the following command. So it's aws secretsmanager get-secret-value using the --secret-id and here we can paste in the ARN of the secret and then --version-stage of AWSCURRENT, then I'm going to use the AWS credentials of the AWS user Stuart.

Now, this profile here of Stuart matches the user credentials of the IAM user Stuart in the secondary account. So let's give this a test. And there we go, we can see that we have returned the values of the secret and we have here the two values where the username was Alice and also the password was Password1. And that's it. So that's how you can share secrets between accounts by attaching a resource-based access policy to your secret.

Feedback on our courses here at Cloud Academy is valuable to both us as trainers and any students looking to take the same course in the future. Any feedback, positive or negative, it would be greatly appreciated if you can contact support@cloudacademy.com. Thank you for your time and good luck with your continued learning. of cloud computing. Thank you.