Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Luciano: In episode 112, we talked about SCPs, or Service Control Policies. SCPs are about setting a maximum boundary for permissions in an account or in an organization unit within an organization. There is another kind of policy that is important to understand, and this is the Permission Boundary Policy. If you don't fully know how this works yet, you can run into all kinds of problems. But once you know, you have a tool that allows you to enforce further security, prevent something called privilege escalation, and overall will let you sleep a little bit better at night.
Today, we will try our best to give you an effective introduction to the Permissions Boundary Policy. My name is Luciano and I'm joined by Eoin for another episode of AWS Bites podcast. AWS Bites is sponsored by fourTheorem. fourTheorem is an AWS consulting partner. So if you need help to start your journey on AWS or build ambitious projects on AWS, check us out at fourtheorem.com. Okay, back to the topic of Permission Boundary Policy, what it is, let's try to give a little bit of an overview.
There are additional policies that can be attached assigned to identity policies. So what do we really mean by this? That means that we can attach them to IAM users, we can assign them to IAM users, we can assign to IAM roles, we can assign them to IAM Identity Center Permission Sets, which are still roles under the hood. But the idea that we need to clarify is that they don't really have an effect on resource based policies. So like SEPs, they never grant any permission, it's just another mechanism that allows you to set a maximum boundary around all the possible permissions that you can have in a given account. So the question might be, if we already have SEPs, why do we have another thing in place? Why do they really exist? What is the use case for other kinds of policies? You might say that the reason for these permissions boundaries to exist is all to do with the whole idea of security shifting left.
Eoin: So what does that mean? Well, I suppose IT security used to be an area exclusively for operations teams to worry about. But the trend in recent years has been to shift left the responsibility so that development teams and architects are part of the approach to operations and security and it becomes a collective responsibility. There's an understanding that in order to be productive now teams need more control over infrastructure and security and don't just throw stuff over the wall to another team.
This is really what the DevOps movement was all about. The approach really has the benefit of removing barriers and blockers to innovation. The other benefit of it is that you have greater awareness of security requirements and practices throughout the whole organization. So to shift security left you need to give teams power to administer things like IAM roles and maybe even users within their domain.
But you also have to limit the potential risk, right? Before the introduction of permissions boundaries, if you gave a developer role the permission to create other roles, they could actually use that privilege to create a role with more permissions than they had themselves. And then they could just assume that role and become like a super user. That is what we call privilege escalation and it's something security admins would be very careful to avoid.
So it's not just about escalation for developers, but obviously any attacker that might gain access to the developers credentials could do that as well. So then to explain how we prevent privilege escalation by using permissions boundaries, we might think of an example. So let's say Bob is a forward-thinking but security conscious AWS account administrator and Bob wants to delegate IAM administration within a development account to Alice, Alice the developer, and giving Alice permissions to create roles within that account.
And I think a lot of people hopefully have the experience of doing that as AWS developers. Ideally Bob would like to be able to give Alice the permissions to create, edit and remove roles and users within that account. But there are a couple of things you would prefer that Alice is not able to do either intentionally or accidentally. And those are things like Alice should not be able to update or delete her own role and its policies because that's managed by somebody else.
Alice should not be able to update or delete roles that are created by the administrators or be able to assume a role with greater privileges than Alice's own role. And Alice should also not be able to pass a role with elevated permissions to an AWS service. And if you think of an example, let's say you have a role exists and EC2 is a trusted service in its trust policy and has the administrator access permissions policy attached. Alice might have permissions to start EC2 instances and could then specify this role as the instance's instance profile. And then Alice could then log on to that EC2 instance and perform actions that are not permitted by the role Alice has herself. So this pass role idea here with EC2 is also something you need to be careful of with privilege escalation. And this whole area is something that permissions boundaries are designed really specifically to help. So Luciano, would you like to describe how permissions boundaries are the solution to privilege escalation?
Luciano: Yeah, let's say that Bob now needs to fix this problem, right? What can I do? And the idea is that Bob can create a permission boundary policy, which is just a normal policy in AM. But it will allow him to restrict specific actions like create a role, but make sure that Alice must assign a permission boundary to it. So the idea again is that Alice will have a policy that permits her to create a role, but that role cannot be unconstrained.
It needs to have a very specific constraint, which is it needs to allow to assign specifically this particular permission boundary to that role that was created. Then, of course, it denies the ability to update or delete role when that particular role is managed by the administrator. So it's kind of sealing the role in that way. It denies changes to the boundary policy itself. So it's also sealing the boundary policy. And then it denies the deletion of centrally managed policies.
Finally, also prevents IAM pass role with a role that doesn't have the same permission boundary. So again, it's just trying to make sure that the permission boundary is kind of a common denominator in all the roles that are managed this way. And pass role is what mentioned that is a special IAM action that doesn't have any specific API call associated to it in the SDK. It's just another way to prevent privilege escalation by basically defining or controlling who can pass a specific role to an AWS service.
So you have a way to express this concept of an entity passing a role to another AWS service, and therefore create restrictions around that particular action. Now, when Alice creates a role, she can basically give it whatever permission makes sense for the particular context. She also has to set the permission boundary on this role to the REN of the boundary policy set by Bob, which basically means that the policy itself will follow whatever the boundary policy is limiting.
And this will restrict the action that the role can perform. So Bob at this point can say you cannot spin up an EC2 instance. And at that point, this way, the new role is in editing that limit action. And this is also going to prevent elevation of permissions or messing up with the roles in ways that were not intended for. Now, what are the disadvantages of boundary policies? Because it seems like they solve a very interesting problem that might happen, and it might be very tricky to even realize that you might have this vulnerability in your AWS architecture. But is there anything else that we would need to be concerned when it comes to boundary policies?
Eoin: Yeah, they're quite a nice thing to be able to allow somebody the freedom to create a role with a policy like administrator access attached, and then worry that you still got some boundary that would prevent them from doing really serious things like privilege escalation. But there are, like you say, some disadvantages. And really, it comes down to the fact that you have to attach them everywhere you create a role or a user if you want to use them effectively.
And that can become a little bit of friction. It's just an extra step when you create that role and you have to remember, oh, what is the ARN of this permissions boundary I'm supposed to attach everywhere now. It's easy enough to do in the AWS console, or with CloudFormation and Terraform. Some tools, however, make it a bit of a pain. There are a lot of serverless framework plugins that create roles implicitly, just for convenience.
But a lot of them don't really have good support for permissions boundaries, or they've got inconsistent support for attaching boundary policies. And I've had the case in the past where I was working in an environment where I was explicitly forced to use permissions boundary policies. But I ended up having to define that in like three or four different configuration formats in the one serverless YAML file just to get it working.
And in other cases, you might have to do some hacky stuff if it doesn't support the boundary policy. So I think most tools are getting better at it, but it can be inconvenient. So just watch out for that. Another thing is that having multiple policy types in your organization, like we talked about SEPs, now we're talking about boundary policies. You've got resource based policies and endpoint policies, as well as the principal policies, and having permissions defined in all these different places can make troubleshooting more complicated.
Luckily, the IAM policy simulator can help with this. I think we mentioned in the SCP episode is that we mentioned the fact that the policy simulator wasn't great for SCP errors, but it is good at pointing out where permissions boundary policies are restricting you from performing an action. Boundary policies can be abused as well, have become too fine grained. Like service control policies, they should really only be used for broad permissions and really not much more than privilege escalation. Otherwise, they'll become very maintainable and really slow productivity down, which is not what you want. But maybe as a quick aside, Luciano, we keep talking about Bob and Alice. Can you explain to the audience and to us who are Bob and Alice in the first place?
Luciano: Yeah, I think if you have done any cryptography at college or in general, because maybe you like to read this kind of stuff, you might have come across Bob and Alice. But there is an interesting story behind it, and I think it might be nice to just mention it. And basically the idea is that when people were trying to describe cryptographic algorithms, you generally have at least two entities and they were called A and B.
So Alice and Bob are kind of an evolution of that. That was introduced by Rivest, Shamir and Adleman when they wrote the famous RSA encryption paper. Rather than just using A and B, they introduced Alice and Bob. So they kind of created characters, which was, I guess, something interesting to do in a scientific paper. But it was well received by the community to the point that everyone is doing that now.
And there are also interesting side stories that gets created around the life of Alice and Bob. And we will have a link in the show notes if you're curious to look more into that. So these papers can be fascinating because sometimes you have this kind of Easter eggs that end up becoming kind of a standard across the entire literature. OK, what is the summary for today? So today we try to give developers a way to control IAM to some degree while still retaining administrative permission.
So we want to give freedom to developers to be able to set the permissions that make sense to them. But of course, there needs to be a boundary somewhere so we can use these new tools that we talked about today. And this also allows us to prevent privileged escalation. So if you set them up correctly, they will help you to make sure that as a user, while you still have all the freedom that you need to do your job as a developer, then you still are not going to be able to do something nasty and escalate permission and suddenly become an administrator or delete things that you were not supposed to delete.
So permission boundaries are the way to achieve all of this. And also the concept of IAM pass role is very important to understand to really master how to craft permission boundaries and how to use them. The idea again is don't abuse them, keep them at very high level and mostly focus on the privileged escalation use case. If you try to be over specific, it's going to become very, very hard to maintain them.
And you will always have tickets opened against you as an administrator because somebody needs to do something and suddenly they don't have the right permission to do it. And that will slow down the entire development chain. So just be very aware of all of that. And this brings to the end of this episode. I hope you found it interesting and I hope that complements all the other episodes that cover permissions and IAM and policies. And hopefully we are giving you over time a good overview of what are the best practices or the tools that you need to use to really put your AWS accounts under control and make sure you have proper security and power permissions set up. If you have any other suggestions on topics that we might cover, just let us know. Or if you have any interesting story around SCPs or boundary policies, also something we'd like to know and maybe talk about. Thank you very much and we'll see you in the next episode.