AWS Secrets Engine Lecture

00:03

Welcome back in this module, we're gonna be putting dynamic secrets interaction through a course of lab activities.

00:10

We're gonna start out by understanding the AWS Secrets engine. How that works that we're gonna configure and use the eight of us secrets engine that we're gonna touch on the database secrets engine. And we're gonna do some preparation by creating a mongo DB server on AWS and coming back to use vaults, Deputy database secrets engine

00:28

to manage accounts on that mongo DB server that we just set up

00:33

in the remainder of this lecture video. We're gonna cover some background on identity and access management practices for AWS. And then we're gonna talk about the role in the value of the vault AWS secrets engine and how it complements those principles of identity and access management.

00:52

Let's cover a little bit of background on identity and access management in AWS. And really, what that is is the way of authenticating users, individuals and things trying to interact with the AWS service and then authorizing those authenticated things to make sure they have the appropriate permissions to

01:11

use. Resource is create resource is and perform a variety of actions with an AWS.

01:18

When you create an AWS account by default, there's the root user, and that has privileges to create. All sorts of resource is modify, do pretty much everything. And it's a really bad practice to just have that single account and pass around the credentials and have the various individuals and team using that account,

01:37

um, and different services that are interacting with AWS to form automated processes.

01:42

Such is automatically creating virtual machines, setting up storage and so forth to all be sharing this common root user account. But what is a good practice is to create separate and additional accounts. This would be accounts for human beings as well as a separate accounts for different applications. And to that end, even

02:01

different applications and different environment tears

02:05

on the right. You can see an example pulled from Amazon's documentation, where it breaks down different sub accounts beneath roots. In this case, we have user accounts Lee and Matteo, these air people, but we also have the specific service accounts which are catered to individual environments such as Dev, App and Test AP accounts.

02:25

With that background in hand,

02:29

how does the AWS secrets engine fit into things Will it build on that good practice of creating separate accounts for different tiers? And it specifically focuses on accounts that are going to be used by automated processes and procedures, right to to do things and setting up those accounts using the concept of lease privileges,

02:49

so that the deaf one account

02:51

would be set up in such a way that it can only perform certain actions in the development environment. And it can only interact with Se Ri sources that are associated with application one at one.

03:04

Similarly, the Dev app to account would be restricted to access Onley in the development environment, but furthermore, it's restricted to interacting with the resource is that pertained to application to. I think you get the concept and so the eight of us secrets engine it dynamically generates the accounts for you. The benefit of managing this account information involved is

03:23

well, it's secure in its own right.

03:25

But then all the accounts have a certain time to live and after that time to live expires. The accounts get revoked and regenerated and you handle it. Of course, Vault also is providing you with additional auditing so you can understand who's retrieving the access keys

03:42

and information associated with these different accounts and Dev App Juan de Vap, too

03:46

detect anomalous behavior. And, of course, just at a more simplistic layer. Looking at a security paradigm, we are really constraining the cause of damage of any one of these secrets gets out.

03:59

There's a lot of them, and they're each limited to performing certain functions at a certain level of an environment. So it really creates a lot of defense in depth kind of layers to protecting who can do what and which accounts conduce things with AWS.

04:16

So what do we talk about in this video? We covered identity access management concepts in aws what it is some of the best practices. And then we discussed how the AWS Secrets engine enables that keeping good hygiene on the accounts, rotating them on a regular basis,

04:33

creating multiple of them to exercise the concept of

04:36

least privileges.