So let's go into the config service
and start to configure it.
So we are in it and I'm going to click on get started
to start recording some settings.
So we're going to record
all the resources supported in this region,
but if you wanted to,
you can record only specific resource types.
In which case you can find resource categories
and then resource types on the right hand side.
But because I want to show you
all the resources I can record,
I'm going to click on this.
And on top of it, you can include global resources,
such as IAM users, group roles
and customer managed policies.
Just be aware that again,
config is not a part of the feature here,
so the more resources you record,
the more money you going to pay.
And so I'm doing this to show you everything to you,
but if you don't want to pay any money from this course,
please do not follow on with this hands-on.
Okay, so we're going to record our resources.
We're going to include global resources
and then to record all the resource configuration,
we need to create a config service linked role.
So we're going to click on that.
Then all this information is going to be delivered
into an Amazon S3 bucket.
So once you create a bucket,
and the bucket name is already entered for me,
so that's perfect.
And then we can have a prefix if you wanted to.
And then finally,
this is where the data is going to be stored.
And in terms of notification,
we can stream all the configuration changes
and notifications into an Amazon SNS topic if we wanted to,
and again, remember this is for everything into one topic.
But I don't wanna do this, so I will leave this unticked.
I click on next and next we find some AWS Managed Rules.
So we have a lot, as you can see,
and I want to define them later,
so I'm going to skip that part,
but you can have a look at them if you wanted to.
So click on next, and we can review the configuration.
So yes, we want to record all resources,
including global resources.
And we're going to deliver this into an S3 bucket
and currently we haven't defined any role.
So let's click on confirm.
Now the role is being created, the bucket is created
and then config is going to be started.
Now it's going to take a bit of time
for config to have a look at everything within your account
and look at the configuration.
So I'm going to post the video until this is done.
Okay, so my resources are still being discovered,
but I can go on the left hand side to resources,
and actually we will see
that some resources have already been discovered
in my account as you can see.
Some route tables, sub-net, VPC and so on,
have been discovered.
So what I can do is that I can look at resource type
and I can look for example, for EC2 security groups
and find that yes, my security groups are here.
And currently, they do not have a compliance status
because we haven't defined any kind of rule on top of them.
So let's have a look for example,
at one of these EC2 security group.
And from within the group,
we can have a look at the rules applied, so currently none.
And we could look at the configuration
of the security group itself, okay?
We can also look at the resource timeline.
And the resource timeline will give you
all the events related to that resource.
So there's a configuration change,
which is the initial right here.
There's some CloudTrail events also
that were related to the security group.
For example, authorizeSecurityGroupingress rules,
CreateLaunchConfiguration and CreateSecurityGroup,
this kinda thing.
And we can go to CloudTrail to find these events.
So what I want to do is to figure out
whether or not my security groups are compliant or not.
And so for this, we're gonna go into rules.
And rules is going to be able to give us the option
to add a rule,
and we can either add an AWS managed rule
or create our own custom rule with a lambda function.
So to keep it simple, I'm going to add an AWS managed rule
and let's have a look at rules that are accessible to us.
So one that I like is for example, approved-amis-by-id.
So this is to check whether running instances
are in your account using the specified AMIs.
So if I click on it, for example,
and click on next, which is not related to security groups,
but I just wanna show you one rule.
So this one will check
whether or not your EC2 running instances,
will be using the specified AMIs.
And so you can trigger this
based on whenever a resource that's changed.
And then you can also specify all the EC2 instances in here,
and we have to specify a parameter for that rule,
which is the list of all the AMI IDs are approved
within their account and this is going to be used
by the rules and inputs to figure out
whether or not EC2 instance is compliant.
Because we do not have many EC2 instances yet,
we're not going to use that rule.
So instead we're going to use a managed rule,
but this time for SSH.
And this is going to be applied to our security groups.
So we want to make sure
that we're not allowing any incoming SSH traffic
from anywhere.
So we click on next, this is called the restricted SSH
and the trigger is going to be on our resource
whenever the configuration changes, okay?
But as we can see, if we define a different kind of rule,
we could have it to be run periodically as well.
So, okay, we're once.
Whenever our security group resource will change,
please evaluate that rule.
This is applying only to AWS EC2 security groups,
and we have no parameters for that row.
Click on next and click on add rule.
And now we have defined this first rule,
so let's have a look.
So currently it's not evaluated
and we don't have any remediation.
So let's wait a little bit until this is done.
So I just refreshed my page and as you can see,
an evaluation was done automatically.
And if we look at this rule,
we have seven security groups,
no six security groups right here,
which are not compliant.
So if we go into our resources on the left hand side,
and we're going to filter again by EC2 security group
and have a look at all our resources.
As we can see, some of them are compliant
and some of them are not compliant.
So if we look at the compliant and the non compliant one
let's see the difference.
So this one is compliant, okay?
And a rule was applied to it as we can see
it says compliant.
So if I go and manage a resource
and look at the inbound rules right here,
as we can see, we only have one inbound rule,
which doesn't have a port, so there's no port 22 in here.
So this is why this is working.
But if I look at a non-compliant resource,
for example, this launch-wizard-3
I believe it was not compliant, okay?
And you click on manage resource,
we are taken again straight
into the console for security groups.
And if you look at the inbound rule,
as we can see, port 22 on IPv4 from anywhere is being open.
So this is a big problem.
So what I can do instead is delete this rule right here.
And if I delete this rule,
this will retrigger an evaluation of my resource,
which should make it compliant again.
So let's delete it and save my rules.
So then security group has been modified,
and so let me close this.
So this is my non-compliant security group,
and I can go into resource timeline to have a look.
And so within the resource timeline,
as we can see the configuration change happens,
and then the rule was run and it was not compliant.
Now I did change yet again, the configuration,
so we're going to have to wait a little bit of time
for the configuration change to happen right here,
which should trigger a rule compliance
and then hopefully now a resource will be compliant.
So let me pause a little bit and get back to you.
So I have just refreshed my page,
and as we can see in here on July 12th,
we have after the rule compliance,
a CloudTrail event that happened
because I did revoke a security group ingress rule
because I deleted an ingress rule, that's true.
Then it recorded as well, a configuration change
saying hey, this rule that had the port 22 in it
got deleted so from and to is empty because it got deleted.
And then config, they run my rule again,
named restricted SSH.
And now my resource is compliant.
And so that means that yes,
I have fixed the compliance of my resource.
So I can go back into here
and we can have a look at another security group,
for example, this one.
And under the rule here,
you can do action and then manage remediation.
So this is to remediate this for this rule,
so if you look at this rule,
we have manage remediation
and we can have manual remediation or automatic remediation.
In which case, you can specify your number of retries
and a number of seconds for the retries to happen, okay?
So we can select a manual remediation for example,
and then you need to choose a remediation action.
So these are SSM automation documents that we can select.
So these are defined by AWS, but we can also create our own.
And for example, well, we could delete a snapshot
or delete an image if it's not compliant
to whatever we wanted.
So it's really up to you to define the action you want.
So for example, you could say, hey attach EBS volume
and here's the right limit
based on the non compliant resources.
The resource ID parameters,
if you need them to be given to the remediation and so on.
Now this doesn't make any sense,
this remediation action, right?
We need to define a remediation action
that makes sense for our rule,
but as you can see, we can set up automatic
or manual remediation and configure it and so on,
and also best in some parameters around the document itself.
So that's it for config, I hope you liked it.
And then aggregators is to integrate
across multiple accounts, okay?
And then under settings,
you can have a look at the settings we defined from before,
including, for example, sending all the data
into an SNS topic.
Or you can set up Amazon CloudWatch Event rules, okay?
From the CloudWatch consoles
or from the Events rules console
to intercept only specific non-compliant events
for some specific rules.
So that's it for this section, I hope you liked it,
And I will see you in the next lecture.