AWS re:Invent 2019: [REPEAT 1] Getting started with AWS identity (SEC209-R1)

well 9:15 a.m. on reinvent Friday these must be the true believers here all right well it says something here about getting started with AWS identity so let's do that and as a matter of fact you know at least from a security perspective actually from any sort of a builder perspective getting started with AWS kind of means getting started with AWS identity I'll explain okay so you think about security before the era of the cloud now I'm gonna grossly exaggerated the state of the world there just kind of make a point right if you think about you know what you had you have like data center some servers in it data bases in it right how do we secure this thing how do how do we keep you know unwanted access oh well you know network firewall maybe around the whole thing once you're in you're good but once you're out you know you're behind this plot you know you're up you're outside this firewall right you know you put you know like somebody's in charge of the security not happy about it right and you know maybe this the security is mostly at the perimeter and and you know there is maybe some a little bit of finer grained control in there but if you're gonna have some finer grained controls in there is typically kind of you know domain-specific things you have to be an expert at you know database access controls and that's kind of the world before the cloud we move to the world of the cloud in AWS and the you know the elasticity of the cloud is a direct consequence of the fact that everything is you know pay for what you use provision things with api's I mean that's why you can work so much faster in the cloud than you could before and well everything's controlled by api's which means that you have authentication and authorization at every level everything in AWS that you access is mediated by AWS as authentication and authorization that's AWS identity and access management so if you're gonna build anything at AWS or any loved these are the these are the security controls that you're going to need to use and the nice thing about it is they are not only pervasive but the pretty uniform across the across the surface and you know of course this is not the only thing that you use to secure the workloads you build in the cloud there's a whole bunch of you know you may have spent the whole week here at reinvent looking at various security service this is not even a complete this is even close to a complete list we do a whole separate security conference in the summer you know we have it's called reinforced we have these we have these security services to assess you know to do with advanced threat detection and all kinds of ways to assess the posture of your environment and understand what's going on moving down a little bit we have application level security controls you know for example certificate management to give you a encryption in transit key management service to encrypt your data virtual private cloud network security controls and all the way at the bottom of this pig pile the service that you you that a hundred percent of AWS customers use is Identity and Access Management that's the fundamental security control here in AWS and that is what we're going to go into today at length so this is a talk here for builders you're in the right place if you're in some kind of engineering or operational or your security engineering kind of role if you're actually building things yourself and putting them in the cloud this talk is going to give you some very concrete hands-on practical skills for securing those things and we're gonna do this in a way we're going to do this in a way this is kind of as an engineer the way I like to learn about things as I like to kind of distill them down into first principles I feel like if I understand the parts of it and how they fit together I then have a much easier time you know applying these patterns and building things out of them so that's how we're gonna do it this is gonna be a real sort of nuts and bolts introduction we're gonna start with talking about authentication you go a little bit fast through that part but just so that you understand how as as a human being authenticate to the AWS environment so that you can either recognize the pattern that you're already using or you choose a pattern that's appropriate for what you're doing and then we're gonna do lots and lots and lots and lots and lots of I am policy if you want to see I am policies you've come to the right tack if you don't want to see I am policies I don't know we're gonna do a lot of iam policies by the time by the time you leave you're gonna be pretty good at writing a lease privileged access policy these this is very easy to do from first principles and that's what we're that's what we're gonna do and then a few pro tips at the end okay and my hope is you know you might be new to the you might be new to AWS you might have been building on AWS for a while you might have joined a project that's using AWS and you're trying to understand it anywhere you are in the learning curve I'm kind of hoping you come away from this with an understanding or a perspective of how at least authorization works in AWS that you may not have had before okay but you know in order to make any call any of these Amazon Web Services in order to call any of these ApS you need to be authenticated and let's talk about how human beings people like you and me authenticate to AWS how they get in well first thing you got to know is you know when you showed up to if you've ever showed up to AWS with a credit card what you end up with on that first day is an AWS account in AWS account is a container container with a small C for resources things and identities in AWS it's your stuff in AWS got a 12 digit account number it's a little box of resources now if you you know show up today WS with a credit card you're a hobbyist you're building stuff you might only have one AWS account but in any kind of in any kind of an enterprise environment in any kind of work environment whether it's a small one or a large one you're probably going to have a number of AWS accounts and they're probably in the modern era they're probably going to be collected together in something called an AWS organization okay so why do you have these diff and accounts well if you imagine you're kind of a small business maybe a startup you probably have a production environment and a development environment and a test environment these different staging environment these different environments maybe a small number of them and you'd want an account for each write because you want to keep those environments very separate each should have its own box of things each should have its own set of identities so that's kind of the simplest case now if you're a much much larger organization if you're much much larger organization you're gonna have many of these accounts you might have hundreds you might have thousands different divisions different you might even put a work load each in its own account and you might use AWS organizations to kind of divvy these up by organizational unit that you know maybe follow your business divisions the organization also has something called a master account you typically don't put anything in that that account pays the bill and controls a lot of the security controls throughout the organization we'll talk about those later but one thing you gotta know since we're here to talk about AWS identity your identities in AWS your iam identities they are resources things in AWS - and they live in these accounts okay so you know what are the so how do you become one of these identities because in order to make any of these API calls you've got to be one of these identities and one of these accounts so how do you become one of these identities well there are a number of ways out there the most basic of these is something called an I am user you'll also hear me use the word I am principle principle just means caller it means like somebody and I am who can be authenticated so an I am user is a kind of I am principle and I am user has some long-term credentials for example if you are signing in to AWS in a way that looks like this where you're entering a username and a password you are signing in as an iam user and I am users kind of a standalone identity in AWS if you're using the I am user identity programmatically like in our command-line interface you'll have a an alternative set of long-term credentials will be an access key ID and a secret key but you know it's a similar concept their long-term credentials iëm users are great for kind of the getting started mode the small-scale mode where you don't have your own directory of users you know you don't have your own directory of record for users you've got a small number of users you get a small number of accounts you know you're gonna be managing these long-term credentials you know with good password hygiene and all of that you'd be an iam user moving up the food chain a little bit you know in an environment where you have an environment where you have you know multiple accounts but not a huge number of accounts you might be using our service aw a single sign-on a single sign-on is integrated with organizations it's in single sign-on one of the modes in which you can use it is to create your users directly in single sign-on it's called a single sign-on user pool you create your users there now if you kind of look at this picture you can see what happens is they're actually authenticating to single sign-on and then they're getting mapped into different roles that's a different kind of I am principle we're gonna be almost everything we talk about today is gonna be a role they're being mapped into different roles in these AWS accounts now the nice thing is is that there's each human being is only gonna get one even if there's many accounts here each human being is only gonna get one set of credentials to manage and the mappings the entitlements are done up in single sign-on so you know when you have like simple rules about who should get into who should get into what and relatively contain a relatively small number of users and not a huge number of accounts this is you know this is this is a good way to do that to map people into roles one thing about roles we'll talk about this a little bit more later roles unlike the users do not have any long-term security credentials when you're in a role you're in a session for that role that has temporary credentials as security people you should you know your security ears should recognize that is somewhat preferable so the roles don't have their own long-term credentials the long-term credentials come from that user pool and so in a single sign-on like you're using single-sign-on you'll you know again you'll be signing in with your credentials from your user in the pool and you you wind up it takes you to this page where you know you see a choice of the different accounts and roles that you're entitled to you click through that and then you end up in one of these roles sessions we actually on the topic of single sign-on we we announced just last week an integration with Azure ad so if you have like office 365 identities in an azure active directory you can actually you can now take those identities and get them synched into single sign-on so the cool thing about that is if that is your directory of record your people are signing in with those credentials so there isn't a new set of credentials to manage and then again in single sign-on you would map these entitlements you know based on users and groups group memberships into these different roles around your account so it's definitely something to look at if you are if you have your identity if your directory of record is an azure active directory there's more options here for example if you have if you have an on-premise Active Directory and you're running Active Directory Federation services in Active Directory Federation service there's their claims language it's a DSL and Active Directory Federation service again where you can make in Active Directory administrator could make these mappings of your users to different roles you know that would look like this this is my Active Directory Federation service it's not very beautiful but you know I would sign in here again these are my Active Directory credentials and I'd get shown a choice of the different roles that someone had entitled me to going even further up the food chain some of you might some of you might even be using a custom Federation provider if there's some sort of like a poor tool that was written by your organization that's mapping you into roles that's what's going on here not gonna go into a lot of detail of like how to build these or anything but the point of the previous part is you know you might be you might be in the you might be working in the capacity of somebody who is deciding how people get into AWS and so I wanted to give you kind of a flavor of your choices here right if you have a directed the point is if you have a directory of record it's best to use that because then you don't have to manage for a set of credentials in AWS but there are a couple of options if you don't have your own directory outside AWS the other part of this if you you know probably most of you in this room are getting into AWS the way somebody else at work told you to and hopefully now you have an understanding of what that means you're either landing as a user or a role but in any case your landing is an iam identity in one of your accounts that's significant and and as we get through this talk you'll see why that's significant of course not everybody's human it's okay sometimes well I mean any application you write in the cloud is probably going to be accessing some other resources in the cloud like think about nearly any application you might write in the cloud and run on one of our compute environment so I've got ec2 instances and lambda functions up here but there's many many different compute environments on AWS there's ECS containers there's there's far gate there's you can even you know things like sage maker notebooks things like glue ETL jobs anywhere where you're supplying your own logic it's almost always the case that there's some access being made to you know maybe some data that you have in the cloud and so that's gonna be an API call it's gonna be authenticated and authorized and in order to do that you need an identity from which to make those API calls and that identity would be an iam role our compute environments are integrated very very nicely with these iam roles in such a way that when you're when you're doing this you as the engineer is the developer do not need to handle any credentials at all you just associate a role with this instance or with this lambda function and the temporary and and the compute environment takes care of obtaining the temporary credentials and making them available really seamlessly via via you know via the AWS SDK to your to your application and it's it's it's really easy to do and that's how you give your application code permission to do the things that it does I'll show you how that looks in the AWS console because you will definitely see this console page this is the console page that you see as you go to create and I Merl and you'll notice over here that there's four choices the first of these four choices is the first of these four choices is is this gonna be an AWS service that's running under this role to ask me was gonna be a non human process that you need to have access to this role gives you ec2 and lambdas the top choices cuz those are by far the most common but you see there's a really long list down here you'll also see that there's a number of you'll also see that there's a number of other options here another AWS account we'll talk about that later and then there's the human access options over there so this is how anybody who makes an AWS call needs to be authenticated this is how they get their identity ok once you have an identity you need permit you need permission to do something right being somebody isn't enough you actually have to be an AWS any resource you access you have to have had specific permission to access that resource so there's an easy mode here I'm gonna show you this I'm gonna show you the easy mode I'm gonna tell you when it's appropriate to use and then we're gonna get beyond easy mode you're gonna be able to go beyond the easy mode here but the easy mode here if you go to the iam console you'll definitely see this page go down the left rail policies and there's a really long list here and the first thing in the list here is the first thing in the list here is our administrator access that does exactly what you think it gives whoever has that policy permission to the whole account now there's you know the search bar here is definitely gonna be using that each AWS service has a number of managed policies these are kind of curated lists of permissions that we have put together that if you're using you know I guess the next one on this little is Alexa for business you're using Alexa for business this is a set of policies you would need for that we also have some managed policies that map to you know job roles like database administrator network administrator these policies are really useful for assigning human access to AWS environments and the reason why is we humans were complex beings we have hopes we have dreams we have ambitions we take complex set of actions on complex combinations of actions in an AWS environment so that database administrator is gonna need permission not just to the relational database service RDS but also you know to a couple of adjacent services like a few actions in ec2 and these policies take care of that for you we've already thought through what the sets of permissions that you're going to need I'll show you this is the first policy we'll look at this is the administrator access policy it's pretty simple I'm gonna will allow us stop and allow you to take action star to resource star that really does mean that you can do everything but I'll show you a you know I'll show you a different one this is Li the read-only one another really useful managed policy that we have and this one actually got a pretty long list of permissions you can see that it's you know for each and every service we've sort of you we've we've we've listed out the we've listed out the set of read-only api's so this would be a really good set of permissions that you would need if you were gonna go into an AWS account and look at things but didn't you know for operational safety reasons or because you're don't want to authorize this person to make changes you don't want to actually have the permission to make changes so as a result at a very bare minimum if you're setting up an AWS environment for human access you're probably gonna do more than this but at least I would do this in each and every one of your accounts you're gonna need an administrator role or an administrator user if you're using users but you're gonna need an administrator role in each of your accounts because somebody's in charge and you're also gonna want to read only role and yet even if it's just even if it's just a silly test account you'll want to read only role this is just for operational safety reasons if you're going in there and you know you're not gonna make changes you may you know I prefer to use read-only roles to access my AWS environments unless I actually know I'm gonna be making a change and that way if I accidentally clicked the wrong button I won't be able to make any changes so you'll want admin and read-only at least and you'll probably have a few more roles like maybe if one of these accounts holds a database you might have one for a database in minute straighter you might be writing some of these policies by hand if you want to be like very specific for about what a specific human should be able to do but this is kind of the idea so easy mode or these common eight these manage policy combinations of permissions good for the complex sets of things that human beings do not so much for your applications your applications the code that you write does very specific things in your AWS invite access to specific resources and the specific things to it it's totally deterministic it's code you know exactly what it does so you should write policies for those applications that match exactly what the application does that's the principle of least privilege and that is what we're gonna get into right now so we're to talk about authentication and authorization actually before we get into how to really write a good policy it's kind of helpful to understand how authentic I'm gonna give you a little bit of a peek under the hood of how authentication actually works in AWS if you don't understand this part it's okay and the reason why it's okay is because all of these all of these all of these methods that you could be using the access AWS whether you know whether VR console by pointing and clicking or with our CLI or with our SDKs they're all doing this part for you so you don't really need to know about it but in case you're curious which you probably are is how it works so I have an identity and I am roll its gonna make an API call to a service let's call it say dynamo DB are no sequel service let's say it's we're gonna call list tables that's an API that I would call to get a list of the tables in this account and you know of course this call like everything else in AWS it's authenticated and authorized this is a role so it's gonna have some short-term credentials so let me show you what goes on there you can in fact see what I'm about to show you in the command-line interface if you do a dash dash debug show you the headers okay so you know you can see a couple of things here you can see I'm calling the dynamo DB endpoint in Ohio US east to the interesting part here is the is the is the authorization header you'll notice that there's a card seneschal here if you've ever used AWS this credential part is that's your access key ID we pass it in the clear because there's nothing secret about it I exited out here just sort of as a good hygiene practice but I could have shown you my access key ID because there's nothing secret in it the secret part is your secret access key so the access key ID is an identifier in AWS land about the collar of this you know the collar of this API call who they claim to be but they haven't proven that they are this person yet but this is the this is the principle that they claim to be now the signature at the bottom this is an H Mac signature it was produced client-side with the secret with the secret access key that belonged to this since is a role that belonged to this session and you know the the important parts of this API call were sign and that means this was definitely made by you know whoever whoever this ASI a principal was it was definitely made by them and in the you know the contents of the request haven't been tampered with so this call makes it over to the service and it like dynamodb and DynamoDB make sure that the signature checks out you know that this call is actually being made by this principal who claims to be in that credential field ok so you didn't need to know that part because that whole signature thing we document how to do it but you'll probably never do it yourself you'll probably be doing it through you know through our sdk command line interface console but once you're in of course that's that's not the end of the story ok so now we know who you are did you actually have permission to make that call now this is the part you do need to understand so let's imagine you had a role try and access some resource in this picture I guess we'll be accessing some data from an s3 bucket here is exactly and literally how it works so there's a bunch of policies associated with this request associated with the principal making the call sometimes associated with the resource sometimes associated with a number of other things these policies all get picked up now these policies are full of kinds of statements right there might be a statement in one of these policies it's talking about permissions to ec2 well I'm obviously not calling ec2 here so that statement is not relevant so we do a bunch of string matching to figure out which of these policies are out some of these policy statements will match the statement most of them won't we'll take the ones that do and then each of these statements either set has a verdict it either says allow or deny and there are some very very simple rules here somebody has to allow it and nobody has to deny it and if nobody says anything about it it's not allowed right in AWS you need literally permission to do everything that you do in order to be able to do it and a story so you know if you imagine in this hypothetical situation where I'm calling you know s3 get object I've got you know found two statements that apply and this one says allow and this one says deny I'm not gonna be allowed to make the call that's how it works very very literal oh boy this is very very literal so we're gonna break this thing down to first principles we're gonna show you in I'm going to show you in great tedious detail how these how this string matching occurs how these policies get picked up and evaluated and we're gonna we're gonna do this with sort of four examples we're gonna kind of work through them in detail and the thing you got to remember throughout all of this is I am is very literal we're just coming off last week if you're you know if if you live here in the US last week was a is a you know great American holiday it's called Thanksgiving many of us get together with our families and you know maybe you have a maybe have a cousin or somebody who you know who like when they come through the door and you ask can I take your coat they're like I don't know can you that's kind of I am is a little bit pedantic like that like that's exactly how it works just remember that guy when you're doing I am policy and you'll just be just fine okay so let's get into our first example in this scenario I wrote an application I'm running it on ec2 I've got a I am role associated with this ec2 that I don't want to give that I permission to read and write some data from from this DynamoDB table as part of my application that's what this application does got to make sure I have permission to do that I want to make sure I have permission to do that and noting that I didn't need all right well let's get started here let's write some policy that's gonna work definitely a permission to do it I need to do from my application here so that's all actions I'm allowed to do all actions with all resources so this statements gonna match literally anything I do in AWS and it's going to allow it I'm going to introduce you here to the least privileged face of judgment does not like it no good that's a lot of permission that you didn't need like permission and services the you're not you're definitely not using from this application an application never belongs with a policy like that ever so okay let's do a little bit better it's just DynamoDB I don't need to make calls to like I don't need to make calls to I don't know cloud trail from you know from this application so okay all DynamoDB actions again all resources LP foj not so good keep going I could do better okay um specific actions right like dynamodb has a lot of api's on it right dynamodb a have a there's api's there where i could delete a table there's api's there where i could change the provisioning of a table my application uses the table it reads and writes data but it doesn't need to do these other things to the table it's not making you know what we'd call control plane changes to dynamodb I really know I looked at my code it calls these api's so let me write a nice least privilege policy that's these specific api's that are about reading and writing items in a dynamodb table by their primary key okay now deal with all the resources LP foj is doing a little bit he's not mad he's disappointed all right how do we do better than this well one of the keys to writing a good policy is knowing how to read the I am documentation for that service now I know that sounds kind of funny but this documentation is structured in a very specific way to help you write you know a good literal least privilege policy for your application this is my favorite page of the AWS documentation Bar None actions resources and condition keys for AWS services it's a super exciting name but it's actually very very useful if you go follow that link you'll see a list of each and every AWS service so you'll go to the page for the service that you're trying to write a good policy for so I'd go to DynamoDB and you'll be faced with a nice big structured table it tells you how to write the policy so you know I would I care about dynamodb getitem so this is what the row looks like for dynamodb getitem and you'll notice the action here is getitem and there's a couple of other fields telling me what else I can do here we're gonna get into all of these here but back to my policy looking at that table I see that I can the resource the resource that applies what I'm gonna do a get item is a table I can write specific I can do I can authorize specific tables that's what it's telling me so let me put that in my resource field here okay all right now you notice I have this long complicated string to describe my table that's something known as an AR an Amazon resource name all of our resources have them and they're all kind of formatted the same way you'll see there's the name of the service there's the region there's your account number and then there's a service specific part a fully qualified name uniquely identifies your resource across all of AWS so okay I'm have specific actions and now I have a specific AR n for a table LP foj is now happy about this okay how did I get to that well the way you get to that is you go and you look at so back to this documentation it said that for a get table I could authorize the table I can click on that and it'll show me each one of these pages of documentation will show me how to spell the AR n for that resource so you can see here now I know how to put this together and if I bring back that resource AR n that I wrote you can see that it does follow that pattern so that's how you do it I've written a nice lease privilege statement it's gonna match the request actually I'm going to show you how this request gets matched because as we get into kind of more advanced policies you'll want to keep this in mind my application here it's this is you know if it were written in nodejs it might look like this dynamodb PUD item bunch of parameters and you know this role that's making the call has a policy associated with it and this is how the string matching works well the action put item matches the action put item in my statement and the table name tape my table DynamoDB will construct the AR n out of that and it will match that to the resource that's in my policy and that's why this statement gets picked up and that's why this call gets allowed that's how it works so let's do our next example in our next example I've decided I'm writing a specific policy maybe now for my human users maybe these are for my developers and kind of like a development sort of science project kind of account and I've decided that you know I really like my developers but I don't want to spend a lot of money on them I want to give them access I want to let them run launch the the lower cost some of the lower cost ec2 instance types I don't want them launching a you know P 512 mm extra large right I don't want to pay for that I know they don't need it I want to be very specific I want them to launch ec2 instances try things out but I wanted not to break the bank so so what I'm gonna do here is I'm gonna write this I'm going to write this user a nice specific policy but actually we're gonna do a little bit of an audience challenge here I'm gonna show you three options and you're gonna tell me which one achieve my goal okay you're ready option a now the action for launching an ec2 instance is called run instances so I have that part right you notice that I have a star here at the resource you notice I have a new thing here called a condition if you notice that they when I showed you that snippet of the documentation table there was also a condition column the condition it takes an operator string equals and I'm saying that the ec2 instance type has to be t3 nano or t3 micro that's what this condition means okay all right so that's option a option B is exactly like option A except that for the resource part I have put I looked up how to write an AR n for an ec2 instance and I put it in there with some wild cards option C is just like option B except I've got this other policy statement that talks about a bunch of different resources that aren't the instance okay we're gonna do an audience vote here who thinks this is the right policy option a who thinks it's option B who thinks it's option C keep your hand up if you're answering option C because it was the longest one and you figured it's definitely gonna be the most complicated one yeah all right let me explain why it's option C you're very good test takers everybody and I'm so proud of you so is the LP foj well again I am is literal and pedantic so if you imagine if you've ever called EC to run instances or even actually just walk through the ec2 launch instance wizard you notice there's quite a few parameters there you get control over a lot of different things when you're gonna launch an ec2 instance it's not just what instance type but also things like what subnet you're gonna launch it into which you know you know that implies an availability zone implies a set of routing what security group who should be able to get into and out of this instance what what ami would input image ID like what's the what's gonna be running on the instance all kinds of parameters here gives you lots of control well you know what I am gives you a lot of control too if I showed you I can't really show you the screenshot for the run instances row over here because it would just be too much for a first slide but you should go and look at it if you go and look at the run instances I am documentation you'll see that there's not just one resource being authorised there but like seven or eight now why would we do that we would do that because a lot of these parameters are things you would want to authorize like you may want to make rules about which image IDs somebody could launch instances into you might want to make rules about which security groups like maybe they're allowed to you know launch into the internet facing security group maybe they're not right you're gonna want to control each of these and I am gives you the ability to control each of these now when there are multiple resources associated with the call each one of them gets authorized and each one needs to be allowed and if any of them is not allowed you're not allowed to make the call now if you think about that from a security standpoint that is exactly what you want right if you're specifying a security group you're gonna run and launch an instance into a security group you need permission to launch an instance into that security group so here's exactly what happens when we match this polit when we match this API call that you made to your pallas to policy C okay so going down the line of these different parameters instance type well if I look at my documentation instance type is an attribute of the instance resource so that part's gonna be authorized against the instance resource so that's gonna pit that's gonna match that first statement so the instance part's gonna match this statement you notice I have a condition here that was allowing T 3 micro T 3 micros on the list we're gonna match we allow this part we're not done there's a bunch of other resources here in each and every one of them needs to be allowed so for example the image ID well it's allowed because of this second statement the second statement means you know all these other parameters I'm really cool anything that they do here but you do still have to allow it so the image is allowed because it matches over here the key name is allowed because it matches over here and so on and so forth down the line there's about seven or eight of these depending on what parameters you specify for run instances each resource gets authorized independently and each one needs to be allowed that's how this works now if you think back to those other options you remember option eight options a and B didn't have that second part option a had a resource star now the problem is when it goes to authorize say the security group security group does not have an instance type attribute that does not make sense and so that part wouldn't match and it wouldn't have been authorized again this is literal and this is pedantic I don't know can you write an option B we just had the instance resource so all of these other resources when they tried to find a statement that matched them found nothing and since nobody said anything about the resource it's denied and since all of the resources aren't allowed the call is denied so that's how this works okay so let's do some more super literal policy writing here scenario three many of our services that hold your data also offer really easy to use encryption integrations with KMS key management service it's usually exactly as easy as saying yes I would like the data encrypted here's the key I would like you to encrypt it with it's it's pretty much that easy in most cases and you know I want to make sure that when people write to this s3 bucket that they be encrypting their that the objects be encrypted with a specific key I care about how encryption is done I want it done with a specific key this data is very important to me and I want very tight control over it okay let's try to do that you know let's write a deny policy and the good thing about deny policies is is they're pretty simple to an if you see a deny policy you know it is definitely going to take effect if it matches the statement regardless of what other policies are out there in the mix so they can be pretty useful that way and and that's how I want this to work with the s3 bucket no matter what other policies are in place I want to absolutely make sure that the unencrypt that the unencrypted or incorrectly encrypted objects aren't there so I'm gonna write a statement like this it says deny s3 put object that's how you put objects in s3 the resource the object of a put object the resource would be an s3 object that's how you write an AR N or that's how you wild-card in there and for object in a bucket and now this is this condition here I'll just explain this one little so I'm denying access this this if exists suffix to this operator if exists is useful when you have to think about well you think about the different sort of encryption dispositions that are possible then somebody puts an object in a bucket there's really there's actually three possibilities well the first possibility is they encrypted it with the right key and so that's good I want to want to allow that don't want my denied policy to match that the second possibility is that it's encrypted with the wrong key and the third possibility isn't not encrypted right and I want to deny it unless it's encrypted with the right key strictly speaking this isn't necessary because this field always exists but this is kind of I find this much easier to think about with the if exists I find it much easier to think about when you have a condition if you think about all three cases right one wrong one and absent and you use if exists to help you if exists evaluates to true if the thing isn't there so if the you know if this field weren't there I would wanted to I would want to denied right the fields got to be there and it's got to be set to the right value in order for me to allow this okay so now I'm blocking calling LP foj likes how specific we are about this okay got a question for you so can I can this guy write the data now I think well better ages law of headline says no why would I be asking you if he can write it if he could write the reason why he can't write it is because nobody said he could I am is literal and pedantic nobody said you could write the data and or you cannot write there's only a deny statement here it says what you can't do it nobody said what you can do well let's add something here you can't write it unencrypted or incorrectly encrypted but but you can write it okay so we're doing better here you've got an allow that's broad but a deny that's you know that's blocking a specific condition that I care about we done can I write this data nope I can't write it why can't I write it well when I'm writing this data with the key there's actually two AWS resources involved I didn't there's actually two AWS resources involved here there's the there's the object bucket I've got permission to that now but there's also the key right a KMS key is an AWS resource and I don't have access to do things with AWS resources unless somebody said I did so I cannot write my encrypted data until I do this until I also add and allow to you'll notice that I it doesn't say kms encrypt it says kms generate data key when you're using these integrations it's generally the generate data key API that that gets called by the service does something called envelope encryption you don't really need to know the details but that's typically the API that the service will be calling on your behalf as you upload the encrypted object so you needed permission to do both of these and now you can write your data but I know that you're not writing data that's not encrypted with the right key I've got one more example for you here this example is a little bit different it's gonna kind of show off just how flexible and powerful this I am languages so in this scenario I'm running two different workloads in an account in each workload let's represent it with a fleet of ec2 instances now in AWS the way I attach metadata to resources it's called tagging most of our services support tagging ec2 supports tagging so I'm gonna have my ec2 instances tagged to the project that they belong to I've got a red project and I've got a blue project now I've also my human beings who in this account I've got people assigned to the red project and people assigned to the blue project so what I'm gonna do is a minute create different iam roles one that's tagged to the blue project and one that's tagged to the red project I am roles are resource by now I am roles are resources in an AWS account there taggable so I'm gonna take this this individual who's in here wanting to terminate an ec2 instance he's he's tagged blue project and I want him to be able to terminate instances or operate on instances that are tagged to the blue project but not those tagged to the red project because that's not the project that he works on so that's what I want and this is how I write a a policy like this I'll kind of LP foj pretty happy with this if you look here there's okay so we understand the top part of this easy to terminate instances the resource for that if you went to look that up the resource for that is an instance so that's how that would look the condition here the condition here you notice there's a little bit of a variable substitution going on over there the way you refer to a tag and a situ is with this ec2 resource tag slash and then the key of the tag so project I'm saying the tag on the ec2 resource the tag on the ec2 instance the project tag needs to match the project tag on the principal color another thing you could refer to this is is attribute based access control this is how we do it in AWS it's it's a very handy tool for when you have large or rapidly changing sets of things like ec2 instances cuz ec2 and since the scale up scale down instances are always coming and going but if you have them tagged you can refer to them by group the other nifty thing about this is notice that this policy said nothing about red and said nothing about blue and yet it's a policy that you could use for any role that's assigned to a project and it would have the right effect so here's how to look for tag based tag based conditions in your policy in your in our documentation this is terminate instances terminate instance this takes just a single resource the instance but and you'll notice that there's a bunch of conditions here one of which is resource tag so that's what to look for sometimes you'll see it looked like ec2 resource tags sometimes you'll see it looked like AWS resource tag resource tag is how you do that there's another one here that's that I'm not showing in this action it's called request tag and this is for any API you call where somebody's tagging something somebody's supplying a tag you can also add restrictions about what kinds of tags they can supply what kinds of values that they can have for those tags and so on all right so that's the policy deep dive we're gonna do here what did we do here well this these this is a string matching exercise we're looking for an allow and the absence of a deny somebody has to say you're allowed and they have to say you're allowed for each and every resource you're going to touch and if you want to see what resources get touched an API call you go and look at the documentation for that API that's how this works okay we talked about doing this within an AWS account and you know as we mentioned at the beginning you're probably working in an environment where there's multiple AWS accounts and if you're working in an environment where there's multiple AWS accounts sooner or later you're gonna get into a situation that looks like this where you have you know because remember these identities they live in an account too so you have an identity a role in account one one one needs to read some data from a bucket that lives in account four four four different account for example maybe this bucket in your organization contains some you know config that everybody needs to read that all these applications need to read while they're bootstrapping it's that's fairly common okay I know how to do this let's write a policy we're gonna allow let's say in this case we need to both list the contents of the bucket and read objects you know for whatever it is that this does list bucket takes the bucket as a resource so that's the thing you just get this straight on the docs list Bucky takes the bucket as the resource that's why I have the resource first resource there is a bucket get object takes an object the AR n for that looks like the second resource I could have written these out as two different state but is a little more concise to write it this way and so okay so I have permission to do this right hmm LP foj now so sure right that is a good lease privilege policy but this should not work right if this set up work then I would be able to sit here in Becky's AWS account and write myself a policy that lets me access something you own and we're obviously not going to allow something like that well since two accounts are involved both accounts need to be allowed in the authorization and that's exactly how this works for many of our services including s3 that kind of anticipate cross account accesses being a common use case they support something called resource based policies though also most services have another name for them that's like specific to the service s3 we'll call that a bucket policy and a bucket policy well this is an I am policy it's not attached to an identity anymore it's attached to a resources attached to a thing it's attached to an s3 bucket that says who can access me now you'll notice you'll notice that there is a new part here there's this part here that says principal it's a resource based policy you'll notice that there's this part here principal it's something new and the reason why it's there is because well when we had policies attached to identities we knew exactly what principal they were talking about it's whoever's making this call that's what we're talking about with the bucket the bucket has to say who is allowed to take this action so this notation over here this AWS colon account number here it does not you might think it means okay I'm just gonna allow everybody from this account it doesn't mean that it means I trust this other account to write policies to allow access to me so if that accounts allowing access I'm gonna allow access it's like when you tell your kids if you're you know like you know go ask my spouse and if they say okay I do it's it's exactly like that right this bucket has said the other account is okay but now the other account needs to have permission you notice that we do have that here so each side is saying it's okay and that's why this action is now loud LP foj is pretty happy because both sides of this have been pretty specific in what sorts of what sorts of permissions to allow now you'll find as you scale up maybe you're in a large organization maybe this bucket needs to be reached by a lot of different accounts in your organization now of course you could go back and you can write that bucket policy just laundry lists out a whole bunch of different accounts up to a point that's totally fine but at scale in a very large organization you're probably gonna want a more concise way of expressing this and so that's why we support something called this condition called principle org ID it means what you think you'll notice the principle here now says star now that's something maybe you know maybe your ears are burning a little bit looking at that but it doesn't mean everybody because there's this condition here it means yeah they can access me but the principle had better the caller had better be a member of my larger organization and as of last week you can even do this on a you know if you had a particular organization unit in mind that would be called principle oh you path you could do that too this is really useful shorthand when you're working at scale in a large organization that you might come across now you also find you might be seeing this pattern in your accounts you also find that sometimes you need to access a resource in another account that doesn't support a resource based policy there's a way to do that too and I'll sort of show it walk you through this because I think sooner or later you're going to see this pattern occur in your accountant oh it's good to understand what's going on and I'll kind of walk through what's going on here in this scenario I've got a role in account one one one needs to get some data from a table and account four four four they're not in the same account the dynamodb table happens not to support resource based policy but I need to get to it and I know already that no amount of I am I can write on this role is going to get me into this table it should not and since the table doesn't have a resource based policy how do I do this well I do know that if I had a role in the same account as the table I'd be fine right I know how to write this policy this policy is just going to be like a DynamoDB getitem kind of a policy and you know in fact if I were this role I could make this call to get item with my table but I'm not that role I'm gonna count one on one so how do I get in there well in order to get in there we do something called assuming the role so in order to get in there this is this is a call to our STS service security token service if you look at what a sim role actually does when you call a sim role on another account the return value for this is a set of temporary credentials for a session in that role with those credentials I can make API calls as that role I can assume that role I can become that role so if you look at what happens here this role is calling a sim role it's getting credentials back now it is that other role and now that role actually can access the data often if you're using our SDKs you don't actually have to engage with that at quite that level of detail there's you look for classes like role credential provider names like that that allow that takes care of all of this mechanic these mechanics under the hood but it's good to understand what's going on what's going on is they is the first role called assumed role became the second role and then the second role made the access to dynamodb now if I show you how the permissions policy how the policies are set up well how did I get into the d DB access role well roles are resources - they support resource based policies as well and I am those are called either roll trust policies you'll also see them called us assume role policy documents and you'll notice that this policy here it doesn't say anything about what ddb access can do it says who can assume me and all I am roles have a trust policy because remember they don't have long term credentials of their own there's no way in other than coming from somewhere on the outside so the role has to trust somebody to assume it otherwise are it's a role falling in the forest and nobody is around to assume it I think well and you know over here the first the initial role has permission not to make any dynamodb calls because it's not going to it's gonna make this STS assume role and the resource for that that's the a RN for for another role so that's how this works so the role trust policy or the assume role policy document that's the resource based policy in I am okay so just to wrap up this part about cross account access keep it simple keep it simple if a resource based policy is available that's gonna be your simplest way to do it wherever possible and you can be you can be specific about which principle in the other account to allow I'd actually recommend just trusting the other account it'll make these policies a lot easier to navigate it'll make it'll just make it a lot easier for you to reason from first principles about what's going on and where you need to actually step into another account to take actions from within it assuming these roles is how that's gonna work so if you see roles with trust policies that refer to other accounts that is what's going on on this let I'm just one more thing on this topic of role Trust policy remember we talked about creating roles for to run on our various compute environment such as ec2 well if you look at if you you know the console to kind of take care of this for you but if you actually go look at the assumed role policy document that got created there you'll notice that you know it's it's it's like all these other ones except the principal now says service it's not another AWS account it's an AWS service and that's the name of the ec2 service so if you see those on your roles it means the intention is for some AWS service to assume the role and obtain its credentials literally what's happening here when you launch an ec2 instance and associate and I am role with it the ec2 service the AWS service ec2 is calling assume role for your to get some temporary credentials and delivers those to the ec2 instance where the SDK makes that available to you that's that's literally what's happening here so that's why you're trusting ec2 and another thing about resource-based policies brand-new launched as of last week we have this thing called access analyzer it's in the I am console you a little bit further down the left rail so resource based policies are the way that you allow other accounts outside your the you know the account is a pretty tight box and resource based policies are the way you allow other accounts into that box and access analyzer will go through a number of different resource types as three buckets I am roles sqs queues kms keys I think one or two others and it will go those that support resource based policies will go and analyze those policies this is a this is a static analysis using our automated reasoning so this is using math to do a static analysis of your roles to show you which of these resources is allowing access from the outside this is a really useful tool from a number of different dimensions I definitely recommend when you go home if you have an AWS account go look at your access analyzer report some of the some of the things that's finding are intentional right remember that bucket that I intended for other accounts to access like that would show up here and I would I would archive that finding I would say that's you know that's okay but you may also discover you know permissions the permissions that you have that you may wish to clean up or maybe it's a resource you just don't even use anymore because we're now showing you with the I am role when you've you know when you've last use it so maybe there's an opportunity to clean some things up so you know your findings are going to look something like that you know my bucket I've made it available to 1 1 1 etc alright we're gonna finish up with one Pro move here and that's with AWS organizations organizations offer something called service control policies these are iam policies they're not on they're not on a principle they're not on a resource they're on the organization and they help you make these security and variants these assertions across your environment like this we get 22 regions for on the way more all the time my guess is either almost nobody or literally nobody in this room uses all of the regions alright you probably use one maybe two maybe a couple so wouldn't it be nice if nobody your organization no matter what kind of privileges they gave himself we're able to use the regions that you didn't exceed you don't want to pay for those things if nothing else right well that is what you can that is one example of many useful things that you can do with AWS organizations it's a deny policy me it's not granting permission to anybody to do anything it's taking away permission and this deny policy is gonna get pulled into every policy evaluation for any principle in my organization and you know if you now that you know how to read these things that's going to say that if the if the region is not us East one or us West two I'm just gonna deny it even if the caller is some sort of admin that gave himself star star star star star this policy still gets pulled in and this deny still applies in our documentation page for organizations we have a number I think like twelve or so service control policies that map to a number of use cases if you're running an AWS organization if you're kind of in an administrative role there you should definitely go look at those examples see if they apply to you because it's a really powerful authoritative tool where you can just set these invariants across your environment okay so we're at the end here we're done getting started with AWS identity what do we do here we talked about getting in and getting around hopefully you can now recognize the way that you as a human are authenticating the AWS and have a deeper understanding of exactly what at a fundamental level is happening as you're accessing these resources I'm hoping you also understand at a fundamental level how those authorizations work their literal their pedantic their tedious and you can totally break them down to first principles and get your lease privilege policies right talked about how to do that and then finally you know we talked at great length about how you go and construct that you know perfect iam policy for the application that you're writing now you're not done there's homework this is a technical skill and you know as with all technical skills it requires hands-on practice and so what you should do is take some of takes take applications you've built that maybe you know you didn't know what you were doing with the policy try to tighten up that policy now that you understand exactly what's going on here see how see how good you can get that policy a little bit of practice you're gonna be an I am in no time thank you so much for coming have a safe trip home really appreciate your coming out here to reinvent thank you so much [Applause]

Channel: AWS Events

Views: 30,843

Keywords: re:Invent 2019, Amazon, AWS re:Invent, SEC209-R1, Security, Compliance, and Identity, AWS Identity, Access Management

Id: Zvz-qYYhvMk

Length: 62min 15sec (3735 seconds)

Published: Tue Dec 10 2019