While I couldn't attend in person, thankfully the AWS team published all the sessions from last week's re:Inforce conference on YouTube. I've made it through a good amount of the Identity & Access Management talks, so I'll dedicate this newsletter issue to a few takeaways from my top 3 sessions below. If you have the time, I recommend checking out the full playlist here.
There were a few recurring themes throughout each session - most notably Least Privilege and Data Perimeters. Zero Trust was brought up less than in previous years if my mind recalls, but maybe that's because we've all finally come to realize that Zero Trust is just proper IAM :)
Personally, I've never liked the term "Least Privilege" as it's so often defined. I prefer to say, "Right Size" because that factors in the right amount of context and intent. What I appreciate from the sessions I watched is the practicality of taking things in stride, and balancing security goals with the needs of developers.
Now it's time to look forward to re:Invent, which I really hope I can attend to keep my attendance streak alive 🤞
Ivan at IAM Pulse
PS - I'm reminded of a Tweet that still cracks me up – Least privilege IAM is the new “100% code coverage” 😂
From AWS re:Inforce 2022
In this session, Becky Weiss, Senior Principal Engineer at AWS, walked through in detail the behind-the-scenes work of the IAM service when evaluating requests, factoring in the nature of such complex distributed systems.
What I appreciate about this session is the clear delineation between the control plane of IAM and the data plane of IAM. One thing that separates IAM from other AWS services is that the data plane’s function isn’t exposed via API, but is rather the internals of processing auth at a very large scale.
As with any good system, the functions behind the IAM service are deterministic – and it does a pretty damn good job at such a massive scale. What makes managing the system so challenging from an end user perspective isn’t necessarily the control plane, it’s the understanding of what goes into the data plane and how everything gets evaluated to make an access decision.
In its policy evaluation logic, the AWS IAM service assembles a request context, which includes all of the applicable policies that determine whether a single call will be allowed or denied. Once you grasp the logic & pieces, you can make sense of how a single request is evaluated, but what makes IAM so hard is determining applicability across all hypothetical scenarios – “who can perform which actions to which resources under which conditions?” is a much harder question to answer with multi-dimensional considerations than the question, “can this principal perform this action on this resource given these conditions?”
Understanding how individual requests are evaluated is fundamental to understanding the whole, and this session did as good a job as I’ve ever seen in describing the underlying system.
In this session, members from the AWS Identity team walk through a series of nine recommended strategies for least privilege access – a 3x3 across Plan, Policy, and Process.
The presenters did a really good job setting up the topic as a mental model, something I always try to do when reasoning with the complexities of IAM. I won’t go through all nine strategies in detail, but there were two topics that sparked some thought – feedback loops and security invariants.
I think feedback loops are an under-discussed area within IAM as there are always various perspectives across teams – differing incentives, goals, and skillsets can lead to tension, missing context, or intent getting lost in translation. Something we strive for here at IAM Pulse is formulating a shared language that everyone can reason with, always factoring in the right context and intent.
The other area that caught my attention was the discussion around security invariants – or guard rails. Setting things that should always be true at the organizational level is very much a good thing – but one pitfall to avoid is not disseminating that information with teams. Nobody likes getting blocked from performing a task with no explanation why, which can easily happen if an admin sets the boundaries and doesn’t say anything. Per my commentary on the previous session, applicability is the key to understanding the logic behind IAM – but if you’re in the dark about what policies apply, you’ll undoubtedly be lost. Something to be mindful of as you set guardrails – make sure to tell the team!
Overall, this was a great session that clearly described a number of solid strategies, with supporting mental models to make sense of it all. Kudos.
Closing out my top 3 sessions was a customer story with Guardian Life, walking through their thought process and technical implementation to validate policies inline their CI/CD pipelines.
This is a highly relevant topic as it aligns with what we’re building toward at IAM Pulse – always helpful to see how teams built it themselves (so we can help other teams avoid having to build it themselves!). This session put a lot of the strategies from the previous session above into practical use, naturally uncovering a few considerations along the way.
I’m a proponent of automation, of course, but very strongly believe that infrastructure code reviews need human eyes to make the right calls. Rule-based configuration & permission checks can tell you what’s wrong with your code, but have a much harder time describing how it would land. An added layer of insight is needed to determine what could happen when a change is applied where it’s better for a human to navigate.
As you might have guessed, this is what we’re building toward at IAM Pulse. The pipelines and processes as described in this session align with the workflows we’re aiming to support – but we don’t treat checks as pass/fail scenarios (aka configuration whack-a-mole), rather a complete picture of the downstream impact (aka confidence through clarity).
Now seems like a good time to mention (once again) that we’re seeking select design partners to give our working product a spin for feedback as we march towards a public launch. Throw your most complicated Terraform and/or AWS accounts at us, we’ll see how we make sense of it all – hit me up!
Enjoy this Issue? Subscribe to Get it in Your Email.See All Past Issues ->
Join the beta waitlist
Enter your email to get notified when our product becomes available to try.
Sign Up for the community
Create your member profile to get involved with our content, programs, and events.