- Welcome back to the Cloud Academy course on Governance on AWS. In this lecture, we'll be spending some more time in the console going over the different tools and technologies that we have for transition action governance. So those will include some technologies like AWS CloudTrail, CloudWatch Events, AWS Config Rules which we saw a little bit in the last lecture, the AWS Service Catalog, and AWS IAM policy actions. Without further ado, let's get cracking and spend some time in that console. So we're back in the console, going to be spending some time looking at our transition actions governance and management. First things first when we're thinking about managing our transition actions, which in AWS they're our API calls to the AWS service endpoints, there is one service that is very good at doing this. It's called CloudTrail. If we look in the All AWS Services, this is alphabetically ordered, so we have CloudTrail right here. But the CloudTrail icon shows up inside of the Management Tools subheading, for those of you that are using these subheading navigations. So what CloudTrail is, is effectively just an API timeline for all of our activities. If you look here, we can see in my API activity history there's two tabs here on the left. My API activity history is telling me all of the things that I did to my account. So if we look in this region, we can see that I have a console login at this time, the 1:51 on the 10th, it looks like. Then, I have this whole set of things that I was doing. I created a VPC, a route table, an associated route table. I did these all one second together, because I used the VPC Wizard in the console. But you can see that from a governance perspective, it'd be extremely helpful to have this nice audit log of everything that anyone's ever done. So if we open up and look at this individual line item, CloudTrail will actually tell you the access key that was used, the event source which is usually the service endpoint that you're associated with, the region that it was called in if there was an error or anything, the request or event ID, and the source IP address from which you just operated. This is really handy, and now you all know my email. This is really handy. It tells me exactly when, who, what, how it went, and the different resources that are accessed. If you can see here in the bottom-left, the text is small, but if I hover over this link I can actually click into this resource directly from the CloudTrail console. So I have the ability to not only monitor all of the different API events that have come through, or my transition actions that have come through. I can also directly link into the resources that they were acting upon from this console, which is pretty handy. So in terms of using CloudTrail, all I need to do is go into this Trails user interface. I can actually add a new trail and just give it a name, say, "Apply trail to all regions," which means I'll get events from all regions. I would create a new S3 bucket, so we'll call that one "foobar-ca-demo," and we can actually from a governance perspective, one, encrypt it so it's safe. We can select a KMS key. Actually, I'm not going to do that, because it'll make the demo more difficult. But we can select a KMS key that we can encrypt it with, enable log file validation, which will make each log file validate the previous log file using a SHA1 hash, and I can even set up SNS to notify my system. So if I create that CT-CA, then I will have this system. It's actually not going to let me create this, because I already have all these trails in existence on my account, but you get the idea. We can set up that nice, little API activity history timeline simply by turning on CloudTrail here. It's super, super-easy. As you saw, it just created the SNS topic and S3 bucket for me. It was getting ready to. So when we're talking about our API transition functions, we should immediately think of CloudTrail, because that is just a fundamentally awesome way for us to have a nice audit log, for us to make sure that people are doing the right things and that we don't have any suspicious activity in the past going on. So while CloudTrail is nice, it is not real-time in the way that we would really want. It's batched, so even those SNS topic notifications are when we get a log file delivery. That's what we're getting the notification on. What we want is another way to regulate our transition functions in real-time, or very close to real-time. So the way that we would do that is via CloudWatch. A recent addition to the CloudWatch offering is CloudWatch Events, which are these governance-useful rules that we can create that effectively work like CloudTrail does in real-time. So let's go take a look. I can create a rule for an AWS API call on, say, oh let's find an interesting one, IAM that I want to know when any IAM operation happens. So essentially, what this is telling me is that CloudWatch Events is going to tell me whenever I have any kind of IAM alteration. So if any new user is created or a user is altered, I want to know. Or if somebody grants access keys, you can imagine how from a governance perspective that's extremely helpful to understand when those kind of API calls are being made, who is making them, and so forth. I can select different target types, so I can either submit the event to a Lambda function to automatically act upon it, perhaps to undo any kind of nepharious activity or do any kind of custom logic I want. Or just select an SNS topic, so I can get a nice stream of the changes that I want. So I just want the entire event for the API call to come through with all the associated metadata that's pretty similar to the CloudTrail data that would come through, and then I want to set up my Config CA SNS event. So let's configure the details there. We set up an IAM change there and say it's enabled. If I create the rule... Whoops. That's because I didn't hit a hyphen. So now we have an IAM change event that will just tell me whenever somebody makes event source changes to AWS IAM. If I'm looking at it from a governance perspective and I want to have fast reactions in real-time, then I should probably be subscribed to SNS. So if I open up my Config CA, I can subscribe my email. Okay. So the next thing I should do since I've created this subscription is go actually do something that will make IAM send an event to validate that this is working. I'll just create a new user. I've named them "fake-person-hacker-oh-no", and I've given them some security credentials which I'm not going to download. Then, I'm giving fake-person-hacker-oh-no super-user access, which is not good from a compliance perspective. So that is not necessarily the best way for you to set up your IAM accounts. You don't want to create a super-user that's a fake user hacker. What we should see is a notification from SNS shortly here to that email address that I configured, and it's going to tell me that somebody just made that change. So after confirming your SNS subscription like you normally do through email, you would immediately start getting emails whenever those kind of changes are made. If we go back to CloudWatch here to pop that open one more time, look at the events, then we can see that it's all set up and we can actually open up the metrics of that rule, and we can see that we got a hit here. We got a match on the event pattern, which means that I just got an email to my account. I'm not going to bore you to death by going and looking at it, though. But you can see, wow, from a governance tools perspective, that's pretty wild that we're able to set up a system for a very specific thing that we cared about that was actually useful already. Just automatically made this crazy cool DevOps system, where it will tell us if people are changing the users and the access. Similarly, when we are looking at managing these transition function issues here, we can go over to AWS Config and get near real-time, although not as broad scope as these CloudWatch Events. You can tell AWS Config to automatically run manual compliance rules. There we go, noncompliant resources in my tag. So we can tell Config basically to do... So we can use these CloudWatch rules coupled with SNS events to automatically create these transition function notifications as well. So that's nice and we can set up another way for us to manage resource change over time by doing something like this, setting up these configuration rules. Seeing the differences in the timeline between now and these past events, this is another way that we can manage or audit our transition functions. So another way that we can lock down the different types of things that are happening on the account is by using something called AWS Service Catalog. Service Catalog is effectively an enterprise shop for the users on your system to go and create different predefined stacks. Say you want to allow users that are not familiar with AWS or you don't trust very much to self-serve create infrastructure that they need as they need it, but you don't want to give them master controls over anything or give them a lot of control over many things, then you can create a portfolio of these different things that you're going to allow them to create. So you would do something like create one of these portfolios and select different products that you would add to your Marketplace, where you need to import values from your portfolio. The Service Catalog, while we are not on an account that has anything uploaded into the Marketplace, please go and review the documentation for Service Catalog. It's effectively allowing you to make a one-stop shop for users on your account to launch CloudFormation templates, which contain predefined resources and allow people to have self-serve infrastructure without giving them the permission to create arbitrary infrastructure. It's a way for you to allow restricted transition functions that are still useful without compromising your security. Beyond that, when we're thinking about our AWS API calls, of course, of course, we need to be thinking about policies and the different policies that'll actually allow us to restrict on the basis of different action or resource types. When we think about the IAM policies, the first place that we should look is these managed policies so we can create our own managed policy by copying or completely creating a new one using JSON. But the idea is that we can use the massive flexibility of IAM to define different roles or different users, or different permission sets that we need for these users to lock down our governance on our system where we need to be watching our transition functions. Your transition functions again are your AWS API calls. So your primary mechanism for locking down these API calls ahead of time, rather than most of the tools that we just looked at are part of our compliance and reactivity, and perhaps our enforcement. These IAM policies are going to be your primary vehicle for applying a policy up front and creating a nice governed, compliant system without having to rely on reactivity only. Which is helpful to have CloudTrail and CloudWatch Events to fix things when they go wrong or address them when they go wrong, but we also want to make sure that they work at first. So we should be looking at understanding how to write policy documents with principle of least permissions or least access on the effect action and resource statements for our different policies. So again, there's a number of different ways to work with our transition functions or our AWS API calls from an auditing perspective after the fact with CloudTrail, from a real-time reactivity and notification standpoint when we're looking at CloudWatch Events with our arbitrary rule matching for different services, and to look at timelines for individual resources over the history of our lifespans in AWS Config. Finally, to either package up prepackaged systems in service consoles so people can be self-service, or for developers to grant them selectively the different IAM actions that they need to be able to perform to do their job. But no more and no less. So in our Transitions Action lecture we learned some different tools and techniques that we can use while perusing through the AWS Console. In our next lecture, we'll be going over actor states and some tools and techniques that we can use to manage different actor governance problems.