19. EC2 Instance Compliance
So we’ve seen a lot of different services here for compliance and so I want to contrast them one with the other by looking at a theory of the easyto instance compliance so we can understand really how config is different from service catalog and different from Inspector and so on. So let’s start with config. Config is a service to ensure that the instance, for example, will have proper aws configuration. And so that includes having a rule set to evaluate the configuration of your EC two instance, for example, against your rules. And for example it could be do not have openssh port if we’re talking about a security group and so on or make sure that the instance is no more than a C four X large, whatever your rule can be.
Right? And with this Config service we are able to track the configuration over time of your EC two instance. We’re able to audit and audit the compliance as well over time. So these are really important keywords to understand when you go to the exam, whenever there’s an audit needed, compliance and so on. Configuration is a service that would be really helpful for that and we can have automations and remediations on top of config again using cloudwatch event rules or the native feature of config to integrate with automations in ssm. Okay, next we have inspector. And Inspector, as we’ve seen, can do security Vanelli scans from within the OS using the Inspector agent or can be from outside using network scanning.
And in this case we don’t need the Agent to be installed on the EC two instance. What you remember with Inspector is that with Inspector you do need in advance to launch any EC two instance. Inspector does not launch the instance for you. So Inspector will have assessment targets and it will look at those using tags for example. And then Inspector, if your easy two instances of the right role, will be allowed to run a command on these instances and install the Inspector Agent on its own. Otherwise, if you want to roll this home you need to install the Inspector Agent yourself before they can launch the Inspector service. Okay? So remember, Inspector is something if you launch yourself and doesn’t uses ami, it uses already existing easy to instances that you’ve launched on your own.
Now, Systems Manager will allow you to run automations patches, commands or track the inventory at scale. So that could be really helpful for east two instances to get a global view of how your entire fleets of vms is running. Now, service catalog is going to be really helpful when you have beginners on your team and you want to restrict how these EC two instances for these beginners can be launched and minimized configurations. So when we go for this course and we launch an easy two instance it could be be quite intimidating how many options there are, especially if you’re a beginner and if you have strict requirements in your company around tagging, around mandatory parameters, stuff users should never see and so on.
Service catalog is really helpful for these beginner users. So with service catalog we would say okay, you can launch your instance but you only have three types of instance types. You only have two tags to put in their mandatory and whatever you can do. Okay next you have configuration management tools that you can use to configure your easy two instances and so one of them is ssm. So ssm does have a way to manage configuration but we also have opsworks as a service that will be underlying using Chef to manage the configuration on your EC two instances. We also have puppet, we also have the user data, we have nsible, which is an open source tool and so on.
So there’s different ways in this case it’s quite varied and there’s a wide range of availability and solutions out there but it’s definitely possible to do configuration management using many tools on your EC two instance. And why would we do this? Well, this way we can ensure that the EC two instances have proper configuration files. So hopefully through this example we can really see the difference between aws config inspectors, systems managers, service catalog, configuration management tools, even cloud formation and so on. Okay, so I hope that was helpful, hope that puts things into perspective and I will see you in the next lecture.
20. Health – Service Health Dashboard & Personal Health Dashboard
So when you’re using a provider, for example, the cloud provider, such as AWS, it is super important for you to understand if the person of the organization giving you a service and providing your service has good health status. Because if they don’t, they need to remediate these actions and be aware of them and communicate to your own users that something is going on with your cloud provider. And so, as such, there are two ways in AWS to get started with this. The first one is the global status AWS amazon. com, which is a service health dashboard. And this represents a global view of all the events that happen and all the health of all the services within AWS for each region.
So we can have north America, south America, europe, asia pacific, middle east, and so on. And we can get information around, hey, for now, everything looks great. It looks like every service is operating normally, okay? And you have a long list. You also get an information around status history, and you can look at how these services is behaved over time. So, for example, here in northern Virginia, there was increased API error rates and latencies for EC two. And so this could be really helpful in type of information. So all the kind of history will be here, and that’s good. And what you can get out of this is an RSS feed. So RSS is a way for you to subscribe to events of this.
So, for example, whenever you have an RSS feed reader and you would hook this into your health, then you would know about if something is going on with one of these services. So it’s really important, for example, that if you know that you’re relying on amazon API gateway in the Montreal region, then subscribe to the RSS feed. But the problem with this service health dashboard is that it’s quite global, really. It’s not tailored down to you. And so to tailor something down to you, there is the personal health dashboard or PhD. And the personal health dashboard is something that comes out of this bell.
So if you click on this bell right here and click on view alerts, you get taken straight into your personal health dashboard. And here you get issues that actually relate to your usage of AWS. So you have the event log of all the things that have happened. And if you click on this, for example, in us east one, there was an EC two operational issue, and that was the one we just saw in the status health, and you get some information and so on, and you can get a list of the affected resources within your accounts, if there are any. Okay? And using the dashboard, you get some information around the open issues that are currently happening with your accounts.
The schedule changes so you can plan an event and see what’s going on. For example, maybe they want to terminate one of your EC two instances because the hardware is not working great and therefore they give you seven days to just terminate yourself if you want to and create a new one in replacement or other notifications where you get some history around things that have happened in your account for the health dashboard. So the difference here is that the status health dashboard does give you the history and the RSS feed for all the services, all the regions, whereas the personal health dashboard is a bit more personalized and you get information about the open issues for yourself.
So the question is, hey, how do I get an information around, how do I get notified about these issues without clicking on this little bell to see those? Right, well here is set up notifications with Cloud Watch events. And so if I do this, it takes me straight into the Cloud Watch event rule and I can choose Health and within Health, I can look at all the events or specific health events for a specific service, for example, any of the service you want to track or all the services. And then you can look at the event category. So if we look for rds, we can look at an issue, a schedule change or an account notification, and then you can look for specific event type codes.
For example, AWS, rds, operational notification, and then you can also track specific resources. And out of this you could, for example, at a target to be a lambda function, to notify a slack channel again and get some nice operational insights around what’s going on in your personal health Dashboard straight into whenever an issue happens, going into your Cloud Watch event rules and triggering a lambda function. So that’s just one of these examples, but it’s really one that’s going to be coming up to do and to be tested on at the exam. But also there’s this really, really cool GitHub that I like which is saying, okay, let me show you how we can get some notifications and automation around if the credentials are exposed.
And so this is an idea that if you have an iam access key that’s publicly exposed maybe on the GitHub repository in public, then the health service would be aware of it. So Amazon dash track, for example, all the GitHub repositories and look for any publicly exposed keys and we’ll remediate them so you would notify the health service, then we get a Cloud Watch event out of it. So this is the integration we just saw, okay? And then out of it, what we would do is get step functions. And that step function, what would it do? It would use a lambda function to talk to iam and then it would delete that key. It would talk to Cloud Trail to look at all the services that were invoked by that role, for example, if that was a role or user.
So we can get a list of everything that might have been compromised. And then finally a last lambda function that would summarize all the findings and send a summary message to SNS, for example, for all the subscribers to be notified by email and so on. And so this is a very common architecture and here it’s pretty cool because we see a list of other services such as iam, health cloudwatch events, step functions, lambda and so on, and we cannot really understand why. Here we have a step function. It’s because we have multiple steps in our remediation and we’ll be able to track those and get audits of all the times the step functions were invoked.
And then we have each small lambda function in here to do the API calls to each service. So this is a stack that you can launch. So if you go into Us East Northern Virginia, you can click on this to launch the status. And then I’m in the right region right here, and then you click on next. And this is for AWS health creds exposed. We’ll click on next and then create this tag as well. So I acknowledge that it might create im resources with custom names and so on.I’ll say, okay, you’re good to go. And now let’s wait for everything to be done. Okay, so everything has been created and if you look at the resources that have been created, we have a few lambda functions.
So let’s go into lambda and check that out. So we have a few lambda functions in here and three of them. So one to delete the access key pair, one to look up cloud trail events and one to notify security. So notify SNS topic. Then if we go in here, we can also look at the fact there’s a step function that was created. So we’re going to the step function and this is the state machine that will be invoking all the lambda functions. As we can see here, it will delay the access key pair, then look up clutter events and then notify security. And that’s the end. So this is a very simple state machine, but a very helpful one. And then we can look at the fact that there was also a cloud watch event in here.
So there’s an event role in here that has been created for us. So let’s go to this event role. And in here we can find the rule and it says, okay, look for health events source being able to health risk credential exposed services risk type issues. So this will be triggered only when an im credential has been exposed. Okay? And then the target of this rule would be the step function state machine. Okay, so if you want to test this, we are going to test this without doing something too stupid. But we will not commit the credentials in the GitHub. We’ll do this by directly invoking the step function. But if you go to this topic.
And this one I’m going to just add a subscription and it’s going to be an email subscription. It’s going to be Stefandevops@melinator. com and this is an inbox I can check. So I’m going to create the subscription and then I’m going to mellynator. com and I’m going to view stiff on devops@melinator. com and I’m going to confirm the subscription from SNS. So excellent. Now have a mailbox being confirmed. And so now to test the state machine itself, we’re going to click on the state machine and we’re going to first go ahead and create an im user because we need something to delete the credentials of. So we’re going to I am and we’re going to create a new user.
Now you are going to add a user, call it test user and we’re going to enable programmatic access that will give it an access key and a secret access key. So here we go, programmatic access. Then make sure to add zero permissions to that user please. Then no tags review. And so we have created a user without any permission but it has programmatic access so we’ll get an access key back. So we are good to go. Now I’m going to use this access key in a second. So back into the GitHub. There is this entire event that you need to copy and so we’ll just copy all this into the step function and do action and start execution and then we’ll pass on some value. And what we have to replace in here is the access key ID.
So the access key, so the account I need to change it. So let’s make sure we have the right values for everything. So we’re going to SNS and I’m going to support, support center. Here we go. This is my account ID. So I’m going to put it in my step function. There we go. And then finally the region is us east one. That’s excellent. And I will scroll down and the effective entity is you need to put the access key ID here. So we’re going to im copy this and paste this. And so if we go in I am right now and go to see this test user as we can see this test user as of security credentials has one access key ID that has been created already. And so now we’re going to trigger this entire execution and see what happens.
So the execution is now instead of running and it starts to delete the access key pair. Then it will look up cloud trail events and there shouldn’t be any cloud trail events because that is a new user and that user hasn’t done anything. And then finally notify security. So if we go to the mailbox and I go to my mailbox, I have received an email saying exposed im key for user, test user on my account. And so it says that the access key has been deleted. And so this is really nice now if we go to iam and we refresh this page, what we should be seeing is that this access key should have been gone. So the access key is now gone, automatically deleted by the lambda function invoked by the step function. And this is good.
And now if you want to look at why we’re doing a step function instead of just doing one massive function, well, if we rerun this execution, okay, so we’re going to rerun it with the exact same value and start a new execution. Now the delete access key pair shouldn’t work. There’s an error here because we’ve already utilized the key pair and there’s no new one. So it went into the error states and because we’re using step functions, it cut, the error went into notify security. So it was still able to continue and back into my emails. I should have had a new email. And now it says, error deleting key. So here it says an error occurred when attempting to delete an exposed im key. And so therefore, you should look at things on your own.
So the beautiful thing about step functions is that we’re able to really track down how every of this execution went and what happened, which is extremely helpful when you have security type of things. So in here, I’m able to see all the executions that happened and I can drill down and look at their states and so on. So I think this is a really cool example again, because it does bring everything together into how we can integrate so many different services in AWS. So quite a cool hands on to do when you’re ready to play around and you’re done. Never ever commit credentials in public, please. And when you’re done, just delete the stack and you’ll be good to go. So that’s it for this lecture on AWS personal health dashboard and status. I hope you liked it and I will see you in the next lecture.
