Amazon AWS SysOps – Security and Compliance for SysOps part 5

12. MFA + IAM Credentials Report

So, as we all know, IAM can be integrated with MFA. And MFA is multifactor authentication. What would you use? MFA. Well, you use because it adds a level of security. That means that whenever you log in, you’re also prompted with a code and you have to enter that code. And that code must be in your possession. So that just guarantees another level of security. If your password gets compromised, a hacker cannot get access to also your phone or your codes or your hardware. That means that they won’t be able to get into your account anyway. For MFA, for AWS, you accept either virtual or hardware MFA device.

So for virtual MFA device, that includes Google Authenticator or my personal favorite, which is offy. Now, for MFA, how can we configure it? Well, for the root user, it can be configured from directly the IAM Dashboards. But also you can configure it using the cli. Also you can set up not only MFA for the root user, which is the recommended way, but also for your normal users, for your individual users. And then how do we know whether or not our individual users have enabled MFA? Well, you can download a credentials report and that’s very important for coming into the exam. So it’s a CSV file and it will report on which users and which credentials are basically enabled with MFA.

So let’s have a look at how this works. So, I can go into the IAM console and from there I’m able to do a lot of things. So right now I’m logged in with my root account. And as you can see, the first thing that we have to do when we create an account is to activate MFA on the root account to basically protect our account. You can also manage MFA and basically change how you can do with MFA. So right now under MFA, I can see that I have a virtual user device under MFA that is attached to my root accounts. Okay? Now the really important thing to see is the credentials report. So the credentials report is just one click and we can see that the report has been downloaded right away.

So if we look at the Csv that I just opened, it shows me all my users from me, I have my root account and Stefan, as a user, I didn’t create many users. But you get as many users as you want as rows. We can see when the user was created, whether or not the password is enabled, when was the password last year. So you get a lot of information, less change next rotation. And very importantly, we get MFA active. So whether or not the MFA device has been activated and used. So I can see it’s root, my root account is using MFA, but my Stefan account is not using MFA. And so that could be something that’s very important for compliance or whatever.

To look at this report and ensure that every user in your account does use MFA. We can also get information around the access keys when they were activated, last rotated, et cetera, et cetera. And so you get a lot of really good information right here. And we can only get some information around the certificates that are attached to our users. So that’s it. This report is quite easy. But what you have to remember is that if you want to get access to how do our users how do we know if our users are using MFA? Then the answer for the exam will be the Im credentials report. And we’ll we just saw how to download it. So that’s it for this lecture. I will see you in the next one.

13. IAM PassRole Action

All right, so one very important feature to know about IAM and policy is the IAM password option. You will be asked by it at the exam. So when you create an easy two instance, we usually assign a role to it. And we’ve done this with a UI. The thing is, to do this, to assign a role to EC Two instance, we’ll need a special permission which is called IAM password. If you don’t have an IAM password permission, you will not be able to assign a role to an easy to instance. Because we’ve had administrator rights all along this course, it was easy. We used it without knowing. But now we need to explicitly know that this is required to assign a role to an easy to instance. To make this debt clear, here is me. I’m the user and I want to create an EC Two instance. But I want to assign a role to this EC Two instance.

So I need to call IAM pass role. It goes on in the back end, but it’s still a permission that I need to have. Then we’ll have an easy to instance with an IAM role. Now, just know that pass role can be used for any service where we assign roles, not just EC Two, okay? So anytime there is a service and it needs to assume a role or get a role and we pass it to it, then we need the IAM pass role permission. So, what does it look like? As a policy, you need to be able to read this kind of policy. So if we look at it, the first part is admin rights on EC Two service. As we can see, we have EC Two star effect allow resource star, so we get to do anything we want on EC Two. We can create the elite, terminate whatever we want. But for passing an IAM role, we need to have this extra permission called IAM pass role.

As I said, the effect must be allowed, obviously, and then the resource points to the kind of role or roles that we are allowed to pass. So here I’m only allowed to pass the simple EC Two role to EC Two. Overall, I cannot pass any other role. Even if I could see the other roles, they would not be able to be passed to EC Two because I don’t have the permission to do this. So here, in this IAM pass role option, the only thing I can pass to my EC Two instance is sample EC Two role. It’s super important for me to walk you through one of these example because the exam will ask you something like this and you need to be able to analyze the IAM policy and understand which kind of roles you can do and pass to an EC Two service. So I hope that was helpful and I will see you in the next lecture.

14. STS & Cross Account Access

Now let’s talk about Sts. You may already be familiar with it, but let’s just go of it one more time. Sts stands for Security Token Service. It basically allows to grant limited and temporary access to AWS resources. Basically, with Sts we’ll generate tokens, and these tokens will be valid for up to 1 hour. They must be refreshed, and they will allow to access some AWS services. What? We will use this where we use this mostly for cross account access. So we basically allow users from one AWS account to access resources in another account. We also use this for federation, and we’ll see federation in detail in the next lecture. But for example, for Active Directory, we’ll provide a nonaws user with temporary AWS access by linking Active Directory credentials.

Or we can use Saml to basically do the same. Or we can use single sign on to basically allow users to log into a Tos console without assigning im credentials directly. So Sts is used by many other things. Anytime you have a security code token that’s temporary Sts is in the play. We can also use Sts for federation with third party providers such as Cognito. And we’ll see all this federation stuff in the next lecture, don’t worry. And it’s used mainly for web and mobile application when you have cognito in play. And it makes basically the use of Facebook, Google, Amazon login to federate all these logins together.

So, SDS, just remember, overall it allows you to get temporary access to aviation resources, and it’s used for cross account access for the federation stuff. Next lecture. Now, for cross account access, how does that work? We’ll define an im role for another account to access, and we define which accounts can assess this IAM role. And then we’ll use Sts to retrieve credentials. And then with these credentials, we’ll be able to impersonate that IAM role. And that’s called the stream role API. Then the credentials can be valid for between 15 minutes to 1 hour. So as a diagram, what does it look like? We’re a user, and we want to access a role either in the same accounts or in another account.

So we want to access it. How do we do this? Well, we’ll do the assume role API on sts. Sts will check the IAM permissions, making sure you can do it, and then it will send you back temporary security credentials. And these security credentials will basically allow you to impersonate that role that you wanted to assume. So that’s it. That’s something to remember. It’s quite easy when you think about it, but it’s good to see it once again. Sts is a service to give you temporary security credentials based on what you can access. So in the next lecture, we’ll see federation, and that will be very interesting.

15. Identity Federation with SAML & Cognito

Okay, so let’s talk about identity federation. You may have heard identity federation many, many times in AWS, and to be honest, for me it was quite a cryptic topic, it’s really hard to understand. So I’m doing my best here to explain to you how entity federation works, what the Saml incognito, how it is integrated with all these things. So let’s take it step by step and hopefully you’ll have a clearer view of it after this lecture. So federation means that we let users that are outside of AWS to assume temporary roles to access our AWS resources. What does that mean? That means that our users don’t need to have a user in AWS to access AWS. How does this dark magic works? Well, basically the users will assume an identity provided access role.

So that’s a lot of information. Ready? Let’s go through a diagram to understand better how this works. So we are a user and we’re in our company, or we are a mobile app user, whatever it is, we’re a user and we don’t have an account in AWS. But what we do have is access to third party servers for login. It could be our companies, it could be whatever. And this third party is trusted by AWS. So we have defined preempt beforehand a trust between the third party and AWS. What happens is that our users will connect to this third party and through some complicated process that we’ll see in a second, the third party will give back credentials. They will be temporary to our AWS, to our user, to us.

Then as a user, what can we do with these credentials when we can directly access AWS through the console or the API? So this is how federation works, identity federation, that’s because the identity is stored somewhere else, it’s stored on a third party. If you understand this, you’ve basically understood identity federation. Now, identity federation, what is this third party authentication that we’re talking about? It could be ldap, it could be Microsoft Active Directory, which is also similar to being Saml. It’s Saml is a standard, but Active Directory is an implementation of it. It could be single sign on, it could be OpenID, it could be Cognito. So all these things can be third party authentication.

And so using federation, the thing you have to remember is that we don’t need to create individual IAM users. The user management is done outside of AWS. So for the exam, they may ask you about some very specific form of identity federation, namely Saml custom broker and cognito. So we’re going to see these three in details right now. The first one is Saml federation, and that’s for enterprises. Basically, if you’re a large enterprise, you most likely have a Microsoft Active Directory or you have something Saml 2. 0 compliance where you already manage your users through this and you basically want to integrate this with AWS. What this gives you is that now all your users ultimately have access to the alias console or the Cli through the temporary credentials.

So you don’t need to create a new IAM users for each of your employees, which is quite nice. So how does it look like? This is a diagram. Now, this may be a very complicated diagram, it comes straight from the aid of documentation, but it is very clear. So let’s walk through it one step at a time to understand what happens. We are the client app and we are within our organization, so a large organization. What we’ll do is that we’ll go to the identity provider IDP, which is Sam’l compliance. So it could be Microsoft Active directory and it will authenticate the user based on the user database. Then when we are authenticated to this IDP, the IDP will send back a SAML assertion. It’s basically a token, a sample assertion is basically a token.

Now we get some Saml assertion and what we’ll do is that automatically we’ll call assume role with Saml to Sts, which is a special API on Sts. And Sts recognizes this Saml assertion and we’ll give us back we’ll trade this Saml assertion for temporary security credentials. So now we’ve basically logged in, got a SAML assertion, traded that Saml assertion from SDS to security credentials. And now with the security credentials we can for example access AWS just normally. For example an S three bucket that’s if you want to have a cli based access, if you want to have a console based access, there is also a nice diagram by AWS. The idea is the exact same from our browser we’ll access the portal of an identity provider. So it’s like a web based thing.

We’ll get authenticated same thing. Then the IDP will return a SAML assertion and now we can use that Saml assertion directly to sign in into the AWS SSO endpoints, which behind the scenes talks to Sts. And then once it’s all validated, once your Saml is traded for Sts, then we’ll validate the whole thing and you get redirected to the AWS management console right here. So the idea is the same, right? If you look again, we trade our identity internally for some AWS credentials and basically there is just a bunch of back and forth that happens. So if you understood this, then you understood Saml Federation.It’s actually not that complicated. Now, if you don’t have assemble 2. 0 way of identifying your users, then you need to use custom identity broker.

So that’s only if you don’t have assemble 2. 0 and that’s a bit more complicated. Basically you have to program what’s called an identity broker and it’s an application and you have to program it. And this identity broker must be used to determine the appropriate Im policy you apply. So what’s the change where here it is again. We have our users browser application, we’ll access our identity broker and the identity broker is something that we have to program okay, this whole thing in the green dot green circle is something that we have to program and the identity broker will validate our identity with maybe a corporate identity store authenticated. And then if it’s happy, it has superpowers.

It has super user superpowers. And you can ask from SDS any security credentials for any policy. So it’s up to the identity broker to really tailor a policy just for the user that was connected. So it’s a bit more work to do. And that’s why it’s called custom Identity Broker application. So we have to create this. It goes to Sts, makes a request for security credentials, the security credentials come back, they’re given to our users, and then they can either access AWS with the APIs or get redirected to the Aos management console and we can access AWS. So it is the exact same principles as Saml, but it’s not Saml. And therefore we have to do a lot more manual work.

We have to do a lot more work to implement that identity broker. So if you see custom identity broker, that means enterprises but not Saml 20. Whereas before if you see Saml 20, that means identity Federation directly integrated with AWS. And finally, this was for our corporate users. So anytime you are basically sitting at a desk at your corporation but what if you have an app? In an app, your users need to basically put files into an S three bucket. How do we do this? Do we create a user per app? No, that doesn’t sound scalable, right? So the goal is to provide AWS resources access directly to our users of our app. How do we do this? Well, we log in through a Federated identity provider or we can remain anonymous.

Then we get AWS credentials back from what’s called a Federated identity pool. And that comes straight from Cognito. And then these credentials will come with predefined IAM policy that basically allow users to do what they need to do. Don’t worry, there’s a graph. So an example is anytime you want to provide temporary access to write your S three buckets, maybe using a Facebook plugin, you should use AWS, Cognito, and Federated identity poles. Note there is something in the documentation called Web Identity Federation. You may have heard of it before and it is an alternative to Cognito. But now in the documentation, AWS recommends against it and it says you should just use Cognito because it does the exact same thing.

So for this reason, I’m not teaching Web Identity Federation because it’s not at the exam anymore. Cognito is going to be the way to have public applications access AWS resources now concurrently. How does that work? We have our app and our app is directly connected to our identity provider. It could be congrato user pool, Google, Facebook, Twitter, Sample, open ID, whatever you want, right? But it’s an app on the wild. It’s public. So our app logs in to our identity provider and gets a token back from it. Then the app will talk to the Federated identity provider Incognito. And will basically trade in that token that will be verified by the identity provider.

And then the identity provider will get credentials from Sts and then same pattern as before the identity, the Federated identity on Kunito will send us back temporary Aus credentials. And now using these credentials, we can directly talk to our s three bucket and make some calls and see if we’re authorized to do what we need to do. So that’s the idea here. The difference is that now we connect to public identity providers such as Cognito, user Pool, Google and Facebook. But the idea is exactly the same. We trade in a token we retrieve from a third party to a service on AWS to get back some temporary AWS credentials. So if you understood this, you understood Federation.

Take your time, review the graphs, look at the documentation, review this lecture. I promise it will make sense after a little bit, just write it down on a piece of paper. It’s quite hard sometimes to understand how these things are orchestrated. It takes a lot of time for me to get to understand this, but once you understand it, it makes total sense. And any question at the exam that talks about Federation, you will not be afraid of it, you will be embracing it and happy that you know the answer right away. So hope you enjoyed this lecture. I will see you in the next one.