AWS re:Invent 2020: Getting started with AWS identity services

this talk is an introduction for builders to the set of aws identity services that you're going to be using pretty much every day you use the cloud um so that's what we're here to talk about here this session you are in the right place if you are a hands-on builder in the cloud if you're somebody who builds applications you're a developer you are in some kind of uh operations role uh or some kind of hands-on role securing your infrastructure in the cloud you've come to the right place it is my opinion that of all the many skills that you can and will be learning in the cloud of all of the technical skills this one is the most fundamental this is the one that's going to make you effective at security across the whole landscape of aws and the reason why i say that is because this what we're going to talk about in the next half hour is all about authentication and authorization in the cloud the ws and aws stands for web services and what that means to you and the good news about the cloud is that all of the resources all of the data you access everything you set up everything you tear down well it's all done by apis and these apis are authenticated and authorized apis you need permission to do whatever it is that you're going to do and these are the most fundamental security controls they're across the entire aws landscape these are your fundamental security controls so you want to get good at them and in fact it's not that hard to get good at them and that's what this talk is going to set you up to do we're going to first start by talking about authentication in aws and then we're going to talk about authorization uh okay but even before we get started on those things uh let me define a couple of terms and they seem like very kind of basic terms in the english language but it's important that we be sort of precise about it okay the word account right you know you have accounts with many different service providers out there in the world and colloquially like in the english language when you have an account uh what it means is that you know often you have some sort of number associated with you as a customer account kind of means customer number you you're a customer maybe you have a way to pay for these goods and services that you're receiving out in the world so typically out in the world account means customer now it's true in aws it used to kind of mean that as well you know a bunch of years ago you would come to aws you'd bring your credit card and you'd create an account and the account is you know the thing that owned your resources and your data and your ec2 instances and how your credit card associated with this and that the account kind of was you as the customer of aws fast forward to today and the word account in aws is actually transformed it means something a little bit different and it's helpful to understand this in your head as you're setting up your environment today i would define the aws account as a nice little container a little box around your resources in aws around the things that belong in this box a workload a project that kind of thing now if you think about it if you're a customer of aws whether you're a small customer or a large customer well today nowadays you're probably going to have multiple of these accounts you'll for example have different accounts for your production environment versus your development environment you'll have different accounts for the different workloads that you have in each account you know again it's this nice container of operational and security blast radius it's a really nice boundary of ownership that's kind of what the account is today so what's the unit that corresponds to you as a customer well today that is the aws organization aws organizations is in fact an aws service we're not going to go into detail on that specifically today but i will mention sort of where it kind of comes into play in your authentication and authorization strategy but the organization it kind of corresponds to the customer there's a single account it's called we call the management account it's in charge of the organization uh you know most notably it pays the bill for all of these accounts um organizations also there are a lot of aws services that are the most effective when you can configure them across an entire aws environment with a couple or hundreds or thousands of accounts so you'll see integrations with many of our aws services with organizations uh one service that's integrated with aws organizations is identity and access management which we're going to talk about today uh i'll mention it briefly at the end but the operative word here if you're looking to learn more about it service control policies if you're in charge of an organization and you care about authorization that is a word to know okay so you have your organization it corresponds to you as a customer even if you're a small shop working on aws you'll have a couple aws accounts and if you're a large shop you may have hundreds or thousands of these aws accounts each a box around the resources now uh i haven't yet said how anybody gets authenticated to aws uh in order to make any of these ap authenticated api calls well aws has its own identity system it's called iam identity and access management and in the aws iem system because this is an aws service its resources are the identities in this system they're called we call them principles that's the catch-all term and you'll see me using that word a lot today um but it's the iem roles and iam users i'll define each of these uh but these are your identities in aws and because they are things because they are resources in aws they themselves live in a specific aws account so there's two kinds of these principles out there there's the iem user uh which is you know is gonna follow a very familiar pattern for you it's got a username it's got a password an optional multi-factor auth device and it's long-term credentials uh that authenticate you in some identity and some account in aws um these are less commonly used the one that you'll see used uh more and more both for human and application access is the iam role iem role is also an identity also a particular identity in a particular aws account the difference here and you know and as a security minded builder part you know something that will be significant to you is that these iam roles they're always given short-term credentials so they don't have any long-term persistent access of their own you always get into them from somewhere else we'll talk about some of these somewhere else's but in order to act in aws you're going to need the credentials for one of these principles a role or a user and you know in addition to having the identity they each have permissions on them which we'll talk about the second half of this talk okay now the thing is um i don't know about you but uh you know i feel like i have an identity and i don't live in an aws account a human being i live in the state of virginia um so the question is how do i get into one of those roles in one of those accounts because i i myself i am not those roles i need to somehow get into them so now we got to talk about how human beings get access to your aws environment if you are setting up an aws environment nowadays my recommendation would be in order to set up permissions to your environment for your human beings use our aws single sign-on service it does single sign-on like the name suggests uh as an example here i put up a very small organization with uh two workload-based accounts in there one for the green project one for the purple project although i might have two hundred or two thousand of these but the picture is better with two and let's say i have an employee in my organization and i've given him the generic name richard rowe uh richard maybe you know because maybe he specifically or because of a work group that he's part of my intention is that he would he should have read only access to these two environment maybe he's an operator of some kind maybe he's somebody who needs to look at their graphs in cloudwatch or something like that i want him to have read-only access um to both of these accounts and you'll notice that i put these two roles in each of these accounts administrator and read only uh this is an absolutely minimal setup here you probably will have these roles in each of your accounts and probably in a real life scenario a couple of different roles for other sorts of job functions maybe you got a database administrator or a network administrator each of them with different sets of permissions but at a bare minimum you might have a setup like this well richard over here uh richard actually has an identity in my corporate directory uh maybe in an azure a. d that i have and he um you know he authenticates under this identity uh you know he's got a username password maybe he has multi-factor auth set up here um these are his persistent credentials he you know he takes good care of them and what aws single sign-on does is it allows you to take that identity from the identity provider like the real identity and then map it into these different roles that he's supposed to get to so when he connects to our single science aws single sign-on to get into one of these environments he authenticates to this his identity provider and then he is and then he's shown this list of roles that he he can uh get into and then he picks the right if he's gonna start up if he's gonna start looking at graphs in the purple project he'll pick the purple one if he expands that out he'll see that he goes to the read-only role so our single sign-on service it integrates with identity providers that support the skim interface in order to sync the identities over into single sign-on and if you're a smaller shop and you don't ha don't already have a corporate directory or maybe you're in a position where you need to set up your aws environment and you don't have access to be able to set up the kind of sync into your into single sign-on well our single sign-on uh product also allows you to create users and groups directly in the application so you don't even need a directory to go in there but the nice thing if you create your users and groups there again it's like one identity for uh for richard over here even if it's 200 accounts that he can get into so if you know if you're the person in in charge of setting up such an environment this is what we would recommend today it gives you a lot of good control over who has access to what um but i recognize that many of you watching this talk you're working in an already established aws environment somebody else set it up or somebody else controls it or you set it up a long time ago and it's working and it's it's quite helpful to understand how it is that you're getting it and you probably have some way to authenticate to aws and it's useful to understand the particulars of what's going on we talked about a bit about single sign-on single sign-on federates you into one of those roles in one of those accounts similarly if you notice that you're authenticating directly to your identity provider like maybe to an on-premise active directory probably what's been set up is some other kind of federation like active directory federation services in active directory federation services they have a way to set up you know what they call claims uh that that uh entitle you to some set of roles in aws there's a bit of a dsl for defining that other identity providers of something similar um there's even you know if you work for a large sophisticated organization they may have even more complex rules about who can get into what and when and they may have built their own broker uh for giving you access into aws built directly on top of our apis that's that you may you may see something like that where you work and that's you know it's certainly possible to build and then finally many of you are are probably using iam users and what that would mean is that you have if you have five different accounts you need to get into you would have long term you would have and manage long-term credentials for yourself in each of these environments iam users have been around for quite some time so if you have an aws environment that's been around for quite some time that might be how you're getting in and you know once again it's an i in any of these patterns you end up in a particular iam principle in a particular iam account now uh probably if you're watching this video you're probably a human being i don't want to make too many assumptions here but you're probably a human being and uh you probably know that there are entities who need to access your resources and data in aws who are not humans these are the applications that you build and if you're building an application on one of many different environments in aws uh and i'll use the word application broadly because some of these are not you know directly compute environments but any any time that you are standing on an aws provided environment to interact with data you'll notice that there's in that you know as you're creating that ec2 instance as you're creating that lambda function as you're configuring that sagemaker notebook you get the opportunity to associate an iem role with that so that is a role for your environment the nice thing about that is aws takes care of distributing the temporary credentials for that environment to the environment the language sdk that you use to make api calls to aws knows exactly where to find those credentials and as a result the nice thing about this from a security perspective is that there is absolutely no handling of secrets or passwords you have no responsibilities here all you do is configure the environment with the right role and then your application code is going to be able to take advantage of you know whatever permissions you you know whatever specific permissions you assigned it uh for your application that's supposed to run on ec2 so for applications this story is very you know has been for quite some time very simple and straightforward to be able to use these temporary credentials okay now it's not enough to be somebody you actually in aws you need permission to be able to do what it is you want to do and i talk about this topic a lot in fact this is my favorite topic to talk about in aws and um the reason why i enjoy talking about this so much is first of all it's such an important skill and second of all it's easier than a lot of people think because it just follows a couple of really straightforward rules it's a giant string matching exercise it's a giant literal string matching exercise at the end of the day so here's what happens whenever you make an aws api call to any of our services on your client side that request is going to be signed i won't go into the details here but that's how you assert your your identity uh to the service so that it can authenticate you know that it is actually you who's making this call in and and you are who you say you are um but now it's the service's job to authorize your request do you have permission for the thing you just asked to do some very simple rules here in iem you'll notice that there's all of these json statements associated with all these json objects these policy statements that are associated with your principle and sometimes with the resource we'll talk about that later but what i what authorization does in aws it picks up all of these policies first it goes through a string matching process to figure out which of these match the requests that you just made because not all of them will some of them are irrelevant so for example we could run this filtering process and we could find that just this one policy statement has matched your request or matches on the action on the resource on any conditions well this one says allow and if somebody says allowed and nobody says denied then your request is allowed there's another case here where i make my request and now it matches a couple of statements it matches these two statements one of them says allow one of them says deny well if anybody says deny doesn't matter what anybody else says so my request is denied in this case and a third scenario here where i make my request and none of the policy statements match it nobody's saying anything about what i just asked to do and in that case i also get an access denied because nobody allowed it these are the rules and that's all there is to it and so then understanding iem policy is really just understanding how the string matching works so we're going to go through a couple of examples here i just wrote this great application it runs on ec2 and it uh you know it sort of uses the node. js sdk so that's the application code that you're going to see here uh s3 get object it's going to read the object path to data.

csv from examplebucket great my ec2 instance is running under a role so those credentials are delivered and now i know from the previous slide that i currently don't have permission to do this my application is not going to work because nobody said i had permission to make this call to s3 get object for this object so i know that i got to put something in this policy here to say that that's okay so how do i do that well i go to my favorite page in the aws docs i got a qr code here to get you there um it is our service by service documentation of how to write iam policies it's a table for each and every service that gives you an exact cookbook for writing policy statements that will match your requests so here in this case i'm calling the s3 api get object i find the row of the table talking about that it says that for the resource i gotta say something about objects and all of these things support wildcards but i'm writing a good specific lease privilege policy so i want to be specific i know what object this application access is so i want to write a specific policy about that follow the object down at the bottom of the page it tells me how to spell object in arn arn stands for amazon resource name this is these are our fully qualified names for resources all around aws so back to my policy i can write this statement now the action was s3 colon get object the s3 colon part came from the top of the page they told me to do that and the resource here is that object they told me how to spell the object i could have put a wild card there if i needed everything under that path but maybe i know i need exactly data. csv um okay now my application works let's make things a little bit more interesting here uh not only do i need to get this object as part of my application but before i do that i've got a list the i've gotta list everything in example bucket under path slash two slash in s3 these look like folders they're not actually they're just strings they're prefixes so um you know uh what's gonna happen here so i have the policy i wrote before now the nice thing about this recorded format if you're watching this offline you can pause me you can see if you can figure out what i'm about to say here if you're watching it live you're gonna have to think a little bit you're gonna have to think a little bit faster but you know you might come back to it and look at these things these are worth actually understanding in some detail um so far not so good nobody said i could call that list objects api they only said get objects so none of my policy statements are going to match that part i don't yet have permission to do this so what do i do about that well i go back to my documentation page and i see uh i'll i actually picked this example deliberately because in most of aws the name of the iam action is more or less going to be the same method that you used in your sdk but sometimes that's not true this is an example where it's not in node. js it's called list objects v2 in the i am permissions it's called list bucket these are the same things you can kind of make that out from the uh from the documentation that we have so the actions list bucket now the resource is this bucket so they're telling me how to spell a bucket so i can do that and you'll notice that i actually i went a little bit above and beyond from a least privileged perspective i added a condition here i said well i know exactly what prefix they're going to supply when they make the request so i've got this s3 prefix must be like path to star okay um so uh let me ask you what happens here i changed my application code i left that policy statement the same i left changing my application code you know what let me just list everything under example bucket pause me for a second see if you can figure out why that is not going to work you know why it doesn't work it doesn't work because iam is very literal this string matching process in order to match that second statement and get that get credit for that allow you really need to match that statement which means your prefix needs to look like path slash two slash star over in my code i did not say path slash two slash anything and then i didn't have a prefix at all and that's why it doesn't work it doesn't match my second allow statement that is how this works now if i wanted to fix it i could either go back to my code and add the prefix again if that was my intention or if my intention is now to actually allow this application to list out the whole bucket i could get rid of that condition and now i'd be matching the statement next scenario okay we love security here uh a good security practice is encrypt your data aws services such as s3 and many others have a great very easy to use integration with kms our key management system our encryption service in aws really it's a matter of going to your s3 bucket and configuring it specifying the name of a kms key and really kind of you're off to the races it takes less time to set up than it just took me to describe it now this is called server side encryption sse and what the server side part means is that it is the s3 service not you who has to do all of the encryption choreography uh um it's called envelope encryption not going to go into it here but it's s3 doing all the interactions with kms and with your data to be able to deliver you that decrypted data when you read it okay great i've turned on encryption now i have path to encrypteddata.

csv and my application needs to read that i already know how to write the correct statement in s3 to be able to get me to path to encrypt i'm here i'm getting there by way of a wild card pause me and figure out why i'm not able to read my object yet why can't i do that well there was another interaction here now i wasn't doing the interaction directly s3 was doing it on my behalf using my identity and therefore my permissions to interact with s3 i could look at the s i could look at the kmsim documentation and see that the relevant action here is decrypt you know which does what you think and the resource here would be the kms key with which i've encrypted my data in s3 and they tell me how to write the arn for that and now i have permission to i have permission to the whole thing s3 can both get my objects and interact with at kms on my behalf to decrypt it and um and again i get really simple encryption here but i need permission to interact with all of the both of the resources involved here okay new scenario remember we talked about the fact that you're probably going to have multiple aws accounts in play you know really regardless of your size and i can almost guarantee you that if that once you do that someday you're gonna find yourself in a situation where a piece of data sits in one account uh perhaps in an s3 bucket sitting in a count two two two uh these account numbers actually have 12 digits but i'll give you three of them here um and uh some application in account one one one needs to get to it so what do we do here well okay i know what to do in account one one one because we've been doing this for the last couple of minutes uh i'm gonna call get object otherbucketpathtocat.