Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Eoin: Access control policies in AWS are one of the most difficult concepts to grasp. And yet this is something that everyone has to deal with and understand at some level. If you understand how all the different policy types work and how to troubleshoot them, it's like having an AWS superpower. You'll be able to stay more secure, you will save tons of time and you'll have a very sought after skill. So how do you level up your skills in this area?
Well, today we're going to help you in some way by covering one of the least understood policy types in AWS. SCPs or service control policies. By the end of this quick episode, you should know what an SCP is, how and when to use them, and you should be better equipped to troubleshoot access denied errors. I'm Eoin, I'm here with Luciano for another AWS Bites. AWS Bites is sponsored by fourTheorem. If setting up service control policies seems like too much hard work and you'd rather let somebody else deal with it, give us a shout or check out fourtheorem.com.
Back in episode 40, we talked about identity and access management or IAM and quickly covered the high level concepts around the different policy types. There's lots of different policy types and if you've ever created an IAM role, you'll be familiar with some of them. You might have used resource policies in the past as well, like an S3 bucket policy. As an AWS developer or user, you often have the rights to create those kinds of policies, but there are other different types of policies that are usually taken care of by the people who manage the AWS accounts and administer the whole organization structure. And that includes permissions boundary policies and these service control policies that we're talking about today. And because they're maintained by administrators, usually they're less well understood, probably for that reason. So to understand them, we need to think a little bit about AWS organizations because SCPs are actually a feature of organization service rather than IAM as you might expect. So let's maybe start Luciano with a quick run through of AWS organizations. We covered it in more detail in episode 96, but we should remind ourselves so that we could talk about SCPs with a bit more context. Yeah, of course.
Luciano: I think it's important to discuss what organizations are because it's something that is becoming more and more prevalent in the industry. Most companies would have more than just one account. And this is for two reasons mainly. One is security, which is probably the biggest reason and we'll talk more about that during this episode. But the other one is also quotas because with different accounts, you are not going to have quotas in one account affecting the other.
For instance, an application running in, I don't know, a development account, maybe where you're doing some load testing is not going to affect your production account and maybe stop things from scaling up because you are running out on your quotas. So having multiple AWS accounts is something that it's actually done a lot in the industry. It's very important. You will see that more and more, especially going to bigger companies.
And the thing that is interesting is that AWS kind of recognized the need for seeing all this pattern, the need for allowing companies to effectively manage multiple accounts inside an organization. So they built a service called organization, which should make it simpler to manage all of these accounts consistently. So if you go to the organization panel, you will see that there are a bunch of different features.
And if you start to read about what can you do with organization, you'll see also a bunch of other interesting stuff. The main one from an accounting perspective is that you can have consolidated billing, which basically means that you can pay from one bank account for all the different AWS accounts that you have enabled under your own organization. Also, you have a hierarchical structure. So you can imagine like you have a file system with folders and files, where the files are kind of the actual accounts, but you can also have folders which you can call organization units.
And the idea is that you can group accounts logically. And you also can have centralized management of auditing and compliance. For instance, you can have things like CloudTrail, AWS Config working at the organization unit level. So you are kind of centralizing the management of all of that. Also, you have resource sharing across the organization. You have the ability to create new accounts within the organization or invite other accounts into the organization.
You can do centralized access for identities, so users using SSO, which is something called IAM Identity Center. So the idea is that as a user of that organization, you will have a dashboard that you can log in using your own company SSO, and then it's going to show you all the different accounts and roles that you have access to. And then you can easily jump from that to the specific account you need to work with.
And finally, we get into organization policies. Organization policy also includes SCPs, which is the topic of this episode. And these are policies that are applied to organization unit within an organization. So in order to use SCPs, you need to select the enable all feature within your organization. And the other option just gives you consolidated billing only. So it's not a feature that you get out of the box.
It's something that you need to explicitly enable in your account, well, in your organization. Once you have enabled that, you will have the management account and possible other accounts as well, which are going to become part of your organization structure. Just to give you an example, you have at the top, you can imagine again, you have this kind of tree structure, and at the top, you have the management account, which you can also call the root account.
And then you can have organization units like security or workloads. Inside security, you can have an account where you are storing, where you are managing things like guard duty or other security services. You can also manage accounts for auditing. So maybe where you're going to store logs that you might need in case that you need to perform some kind of auditing. And then if we go back to the workload units, these are going to be things where, for instance, you run applications and you might have a production account, a development account, you might have, I don't know, a testing account or maybe a QA account that really depends on the way you ship software from maybe a development to production.
You can also choose to organize your accounts by department or project. It's not uncommon to see that if in a big company you have kind of big applications and they are all part maybe of a microservice architecture, you might have different services running in dedicated accounts, which makes it simpler to organize, for instance, the deployment pipelines, avoid that again you have conflicting quotas or even just make it simpler to have very specific policies and control exactly what kind of accounts, what can they do account by account. So the structure that you choose is highly influenced by the kind of company you work with and the way that you actually ship things to production, but also what kind of service control policies you want to have because defining service control policies is going to affect what you can do in every single account. So I guess at this point we should say what SCPs are and what they are good for.
Eoin: If you've ever written a policy for an IAM user or a role, you'll probably have written or created policy statements, either doing this directly in JSON or YAML or with the AWS console. And in a policy statement, you have things like an effect, which says are we allowing or denying action and then the properties of the statement that is often referred to as the PARC model, P-A-R-C and PARC stands for principal, action, resource and condition.
So the principal part is the identity and this is an account or a user or a role and you only normally have that in resource policies, not in role or user, not in identity based policies because the identity is already implicit. Then you have the action, like something like S3 list buckets or easy to start instances. Then you have the resource or resources, which are ARNs of the resources you're trying to allow or deny access to.
And then you have conditions, which is a bit of an advanced feature, becoming more and more common where you're providing restrictions on the action, the allow or deny based on attributes of either the identity or the resource. Now, I think there's a few important things to know about service control policies that are a little bit different to identity policies or resource policies you may have seen in the past.
The most important one is probably that service control policies never grant any permissions, ever. So that might sound surprising for an access policy, but a service control policy is really just a limit on the actions you can perform in an account. You still need to have an identity based policy or a resource based policy to do the actual granting to do the allow part. So if you think about an identity policy and then a service control policy within the same account and those two sets of permissions are in a Venn diagram with the identity policy in the SCP, the action needs to be allowed by the intersection of the allows in those two policies.
And another important thing is that everything is denied by default in an SCP implicitly. And for this reason, when you enable service control policies in your organization, AWS will create a full access service control policy for you by default. And this is basically action star, resource star, effect allow. And that pattern is pretty familiar to anyone who's ever seen administrator access managed policy.
It looks exactly the same. And this seems like a very permissive thing to have by default from AWS. But of course it isn't permissive because as we just said, SEPs don't actually grant any permissions. They just set the boundary for all the permissions within an account. See the idea here is that they give you everything by default and it's up to you then to start creating service control policies to scope down the boundary for all of the organization units or individual accounts and refine it as you need for your organization structure.
And the last other important point about SEPs is that they don't affect the management account. They only affect the member accounts within the organization. So you talked about that hierarchy, Ushano. We started with the management account at the root. The SEPs are applied to OUs which are beneath that. So that's important to realize. And that's exactly how you apply them. Once you create these policies, you attach them to organizational units within the organization.
Now you could do this at one level of the hierarchy or every level of the hierarchy at OU level if you want. And the effect of that then is that for an identity to have permissions in an account, if there are multiple SEPs within the hierarchical structure all the way down to that account, that the user is in, you have to explicitly allow the permission in all of the SEPs. So because they're denied by default, you have to make sure that the permission you're looking for is denied in each one of them.
There's no like trickle down from the top SEP down to OUs beneath that with additional SEPs. It has to be allowed in all of them. And if there isn't that explicit allow in all the applicable SEPs, you'll get an error and the errors are getting a little bit better here, but usually it says something like the identity is not authorized to perform an action because no service control policy allows the action.
That's basically saying it's implicitly denied or it'll say it has been denied because of an explicit deny in a service control policy. And that basically tells you that there's a deny somewhere. And if you've got a deny in a policy in the whole IAM service control policy evaluation logic, an explicit deny beats everything. So that's why it's denied. And service control policies can be one of the more difficult ones to troubleshoot because as a developer, an engineer in an AWS account, you don't have visibility often into the service control policies. So sometimes you just get a hint that it comes from the SEP. Then you might have to go to somebody else or look in the infrastructure as code for those policies to see where the error is coming from. It's not as explicit as with other cases. Now that we know how they work pretty much, what are they good for Luciana? What are the use cases and why should people be interested in applying them to their organizations? SEP are used as very broad set of controls on the maximum permissions as you very well explained.
Luciano: So they are rarely very fine-grained. So they're not going to really talk about specific resources, it's more groups of things that will allow or deny certain specific actions. So the idea is that you still should do fine-grained controls, of course, but you should do them somewhere else. So you should probably do them as you have done them before, inside specific accounts, create specific types of policies and identity policies for specific resources.
So when you think about SEPs as kind of the macro level, then everything else, all the other type of policies that you know well are probably more on the micro fine-grained level. There are some typical use cases for SEPs. For instance, one that we see a lot is specifying which regions can be used for a given account or sets of accounts. And this can be important because you know that different regions might have different costs.
And generally, as an organization, you might be using a few regions, you're not going to end up using all the regions most of the time. So it makes sense to limit things that you can do only on the regions that you are actually really intending to do, to use. There is a little bit of a gotcha there that certain services will require specific regions to work. For instance, US East 1 for AEM. So just be aware that you cannot just say I want to use one region, maybe you, Central 1, because that's the closest to you, and forget about all the others, certain services will require specific regions to be enabled.
Another example is somewhat related where certain services are only available on a subset of regions. So for instance, if you want to use Bedrock right now, it's limited only to a couple of regions, I believe. So if this is something that you want to use, you still need to enable those regions as well. Or at least one of the available regions as well. Another good use case is prevent root user access, which is, I think, a very good practice to have.
You can also prevent accounts from leaving the organization if somebody might accidentally do that at the account level. This is something you can prevent with an SCP. You can also enforce data governance with S3, for instance, you can have specific SCPs that block public access at the global level, so nobody can create a bucket that has public access. Or you can prevent people from disabling something like S3 object questioning.
You can even force all the buckets to have encryption enabled. So things like that will make sure that when you're using a service like S3, you actually follow all the data governance rules that you might have within your company. You can also limit services that people can use inside the organization. For instance, as an administrator, you might say, okay, I don't want people to use Lambda, because maybe you only really want to do easy to use, you are old school that way, you can disable access to the Lambda service.
You shouldn't probably do that. But if you really want to do it, it's something that you can do. And another thing you can prevent people from deleting or modifying resources, and you can have, in a way, those resources centrally managed. For instance, you might have administrator access in development accounts, but still, there are things that you can limit even to people that have administrator access in those accounts.
For instance, you don't want them to be able to delete organization managed roles, or turn off config rules or crowd trail logging, because you can guarantee that they won't be able to do this using specific SCTs. Another use case that I've seen quite commonly is that you can limit the type of EC2 instances that can be launched. And this is something that is done because there are some EC2 instances that are very expensive.
Imagine the ones with like tons of GPU, or the very advanced ones, maybe for, I don't know, graphics use cases, or AI model training use cases. Those are very expensive, and you rarely need them, unless you're really trying to cover that particular use case. So I think it's a good practice to try to disable those using an SCP, because that's going to make sure that you're not accidentally going to spawn up EC2 instances that might end up being very expensive. So at this point, you should have a good idea of what SCPs are, what they're good for. Now, how do you start creating them? Well, you can create them in the organization section of the AWS Management Console.
Eoin: Ideally, you should use some form of infrastructure as code. AWS Control Tower will create default SCPs for you with some sensible first best practices. So that's a good first option, and that's kind of, I suppose, a gateway for a lot of people in this area. Terraform, again, we seem to be mentioning this repository almost every episode now, but Conor Marr, our colleague, has some nice examples in his Terraform landing zone repo.
Link will be in the show notes. And if you're using CloudFormation or OrgFormation as well, the OrgFormation repo has some examples. And this is all stuff that we covered in episode 96. So we don't have to go into too much detail around how to create them. Essentially, we're talking about infrastructure as code for organizations, which was the exact topic we covered in episode 96. So if that's of interest to you, feel free to go back and check out that episode.
Maybe before we finish, it's probably worth mentioning that troubleshooting SCPs, as we alluded to, can be a bit difficult. For other policy types, you can use the IAM policy simulator, and usually it will be able to highlight the area that denied or didn't really allow access well. So it can highlight denies and specific policies. But with service control policies, you don't get to see in the IAM policy simulator what is being explicitly or implicitly denied.
It just says denied by AWS organizations, which can be a bit frustrating. So it's one of the areas where I think SCPs scare me a little bit, even though in general they're really good practice and everybody should use them, as long as they're pretty coarse grained and you don't go to town on them. But maybe this is a general appeal. If anybody has any great tips for troubleshooting SCPs, we're pretty interested to hear about them. So please share them with us. And let us know as well if you have any other neat use cases for service control policies. And with that, thanks again for joining us, and we'll see you in the next AWS Bites.