I used to be a picky eater when I was young. Veggies like tomatoes, peas, and onions were always left untouched on my plate. My mom's solution was straightforward: eat your veggies or lose out on TV time. It was a cycle of negotiations and scoldings. One day, a guest was over for dinner, and the same old routine unfolded. However, this time, something interesting happened. The guest said, 'If you don't like it, you can leave it on the plate.' That sounded like music to my ears, but there was a catch. I knew that once the guest left, I'd still have to face my mom's disapproval, even though I had been given 'permission' not to eat my veggies.
This childhood memory reminds me of something quite technical - IAM Permissions Boundaries. In the realm of computer systems, it's like my mom setting the rules for my veggie intake, while the guest offered a contrasting 'permission'. But there's more to it than just veggies, and it all ties into how we manage access and actions within digital spaces.
Imagine you're playing a story mode game, something like God of War, which by the way was my favourite game growing up, on PlayStation, you go through the story mode to collect power-ups and souls to upgrade your weapons which can later be used in the game. Think of these as "permissions", something that gives you permissions to do certain actions, ie. use powers and deal more damages. But sometimes, when you're fighting a boss or doing some quests, you're not allowed to use those powers, even though you have unlocked it. If you're a keen story mode games player, I'm sure that you have experienced these sorts of scenarios.
Now let's get back to the real world of AWS. Consider a user or a role in AWS having multiple permissions to carry out actions, eg. being able to create a database or reading a secret text from the vault (Parameter Store), but bounded by a Permissions Boundary of only able to carry out actions that are database related. So in this case, even if the user has the ability to read the text from the vault, they can't do that, since they're bounded by a fence known as IAM Permissions Boundaries.
Now let's take this approach into AWS environment, our digital playground. Consider a user named John. John loves managing Amazon S3, CloudWatch and Amazon EC2 - her favourite parts of the AWS playground. To make sure he sticks to these areas, you, as the administrator has set up an IAM permissions boundary. This boundary says, "John, you can only play in Amazon S3, CloudWatch and Amazon EC2".
But remember, the boundary doesn't grant John the powers. He needs policies to do that. So, you create a policy that allows John to perform actions, both his policy and the Permissions Boundary need to agree. If they don't, his request is denied, just like I couldn't leave my plate without my mom's whopping.
However, IAM Permissions Boundaries aren't the only rule setters. There are other types of policies too, like resource-based policies and session policies. And sometimes, there might be conflicts between them. It's like having multiple referees in a football field, each enforcing their own rules of, in-game referee and referees from the sidelines.
So, to sum it all up, IAM Permissions Boundaries are like the rules that determine how far you can go on the AWS playground. They ensure that even if you have many different powers, you can only use the ones that are approved by all relevant policies.
In our next blog post, we will dive deeper into the security pillar of the AWS well-architected framework.
Top comments (0)