Do you work with infrastructure code and find yourself asking, “what would happen if we made this change?” Deriving meaning from looking at code alone is challenging – let’s visualize it!
When companies are small, they often grant administrative rights to most user roles. This permits team members to wear multiple hats and get work done efficiently. As the business grows, leaving most team members with admin rights becomes a liability. However, pulling rights back from team members can be a nerve-wracking situation - what exact permissions will be lost when changes are made?
To demonstrate a common permissions scenario, let’s introduce A Team Called Quest (ATCQ) – where the cloud is their native tongue. The infrastructure team aims to be a driver for innovation and has implemented clear procedures for peer reviews of code changes through a semi-automated GitOps workflow. While the process has improved collaboration and consistency, the amount of time required by senior cloud engineers versed in IAM to inspect code changes in pull requests for impact is significant. Any mistake in understanding could mean an unexpected change would be deployed to the environment – potentially compromising Confidentiality, Integrity, or Availability (CIA).
Let’s check in with the team at ATCQ to ask “what if?”
What's The Scenario?
As our SaaS product at ATCQ grows, the security team is becoming less comfortable with the development team having full admin rights to all of our production logging and data buckets. We’ve asked the Operations team to update developer access to read-only.
Since our production AWS environment is controlled via Terraform, we’ll make a minor change to create a new Group with a custom IAM policy attached. Before pushing this change live, we review the pull request to inspect what the impact of these changes will be.
You can see the full pull request here.
First, we can tell that a new group and group policy have been created.
Then we can tell that the Developers have been migrated from the old group to the new group.
It seems straightforward enough, but how do we know which permissions have been removed, and which remain?
The Old Way
Discerning the permissions changes from the Terraform code diff alone isn’t feasible given that IAM wildcard expansion only happens on the AWS side. For example, Terraform can’t tell you which actions are explicitly included in “S3:Get*” - you’d have to dig through the docs or use tooling to expand the wildcard and traverse the list of actions.
The New Way - Visualizing IAM
Let’s follow along with a visualization technique we use to explore changesets which helps us navigate exactly what would happen in our downstream AWS environment if we were to apply the changes.
First, we’ll look at the initial state of the environment before any changes are introduced – through the S3-Admins policy, members of the Developers Group have full S3 access to all logging and data buckets.
Let’s inspect the proposed change by looking at the diff – we can see that the S3-Admins policy is no longer attached to the Developers Group, and the new effective permissions come from the newly applicable S3-PowerUsers policy. S3:* has now been reduced to S3:Get* and S3:List*, which includes 60 of the 128 available S3 actions.
To determine the impact of the change, we want to first see which actions were explicitly removed. Our team primarily cares about the associated access levels (List, Read, Write, Tagging, and Permissions Management) over the individual actions, so we can group accordingly.
Note that the original intention was to enable Read access for the Developers group, but we can now see that there are 2 Read actions being removed. As it turns out, not all Read actions are represented by the string, “S3:Get*”. To remain consistent, we could go back and add the missing 2 actions to the policy statement.
We determined that the 2 Read actions not covered by “S3:Get*” weren’t necessary for the team, but before we approve this pull request, we want to inspect what the final outcome state would look like if applied. Through the change in policy attachment, members of the Developers Group are left with 60 S3 actions.
Expanding the outcome state, we can confirm the members of the Group and the names of the S3 buckets. The list of allowed actions are limited to List and Read, no unwanted permissions within this access vector. Great!
As you can see by comparing the Terraform code diff and our visualization technique, discerning exact IAM changes can be ambiguous, and any ambiguity in your cloud permissions can lead to the wrong rights being accidentally granted or revoked. The consequences for these improperly scoped commits can range from annoying (i.e. I can’t upload documents to S3 anymore?) to catastrophic (i.e. Our customer logging pipeline broke!).
In this scenario, the team saved time by using string interpolation in a policy statement. What we couldn’t derive in code was the list of actions mapped to access levels. By visualizing the change, we were able to measure the impact of the code change, and confirm access outcomes are as intended.