All right. Welcome back to another episode of Modern Cyber. And we get to delve into a topic that it's funny, it goes back, I think more than ten years for me, I've been working in this domain space. I was actually at AWS when IAM, AWS IAM was introduced. So I remember the very first versions of it. And even then it was confusing. And here we are fifteen ish years later and it's even more confusing. So I've got a guest on the show today who's going to help, I think, clarify some of how it actually works, share some of his work on how he's tried to help bring light to the darkness as far as understanding who actually has access to what, because that is ultimately one of the questions that we always have to answer in cloud identity. I am delighted to be joined today by David Kerber. David has been building software for about twenty years across consulting, Fortune 500, and startups. He's been involved in cloud security tooling since twenty eighteen. He's currently part of Act Security, which you can find online at act.security. An early stage startup focused on cloud security. He also operates Cloud Copilot, where he builds tools to demystify AWS IAM. We are definitely going to talk a little bit more about that as we get into today's episode. He's got a bunch of degrees and AWS certifications. Self-taught technologist. David, thank you so much for taking the time to join us on Modern Cyber today.
Yeah. Thanks, Jeremy. I'm excited to talk with you.
Awesome, awesome. Well, I know one of the things that is kind of a well-held belief by you is that no one actually understands AWS IAM, and I think I would largely second that kind of sentiment. We all have what I think of as kind of a high level view that, you know, IAM has users and groups and roles and policies and all these things. How do you see those pieces coming together? And what do you think are the things that people don't understand about it?
Yeah, I think, uh, when we look at AWS IAM, the way we're taught about it is like a 101 level. You know, you kind of do your introduction to physics and you talk about, you know, force and momentum and things like that. And you leave out inconvenient things like wind resistance and, and those more complicated things. So the way we're taught at the 101 level is like, you're denied unless you're allowed, unless you're denied. Right? Okay. It seems very straightforward, but there are immediate cases in AWS that that model doesn't hold, right? So there are AWS services that will always allow you to call a certain action. And there are AWS services that will not let you call the action, even if the IAM policies allow it. And so our, our model that we're taught from the beginning is actually a little like reversed from reality. The services make their decisions and then they delegate to IAM. And then IAM kind of kicks in at that point and does some different things.
Um, so I think you're right there, but I want to just come and double check that I hear you right? Because that is more or less kind of opposite of what I think a lot of us do understand. We, you know, we generally understand that you make some kind of service call, EC2 launch instance as an example, and it goes through an IAM evaluation to determine whether you're allowed to make that call. And but it goes through that on the IAM service as opposed to on EC2 service. And if I heard you right, what you're telling me is that that's actually evaluated on EC2, and then it goes to IAM for confirmation. Or did I get that right?
Yeah. You're correct. So everybody's mental model is my request goes through IAM. And then from IAM, it goes to the service, it actually goes to the service first. And then that service invokes IAM and says, here's the policies, here's the context. What's your answer? But that's why like STS get caller identity will always return even if you're denied. Okay. Because it's, it's not asking IAM. It just always returns. Um, because it. Yeah. Go ahead. Go ahead.
Yeah. So so the service is invoked first. Same thing if I like go to the IAM service and try to update a service linked role. The IAM service isn't even going to check what my policies are. It's just going to say, hey, users aren't allowed to do this. Right. And so, so it's that it's that kind of slightly different model that really explains a lot of the weird nuances and exceptions that we run into when we're using it.
So is the right way to think about it then effectively, like you said, it goes to the service and then from the service, the service calls out to IAM, which kind of implies in my mind that there's like this round trip from EC2 to IAM in the example that I gave earlier, and then back to EC2, and then it either executes or denies. and then, you know, gives me the response based on that, which would either be, you know, the IAM deny or the completion of the execution task. But it has this kind of round trip out from the service to IAM.
Right, right, right. Okay.
And I mean, I still think, you know, from a, from a, if we zoom out for a second, I mean, first of all, the fact that this is happening, whether it goes in that way or it goes, let's say, the way that, uh, a lot of people have it in their minds, the volume of calculations and the speed of calculation is still bonkers. Which kind of brings me to my next question, which is, is there some kind of like caching mechanism within the services to know, you know, what the effective policy for a user like Jeremy, who tries to do launch EC2 is, or is there actually a real time calculation done on every single call?
Yeah, that's a good question. And I should say like, I don't have any firsthand personal knowledge of how these systems are implemented. I just, I just know what I've learned from talking with, with different people that, that do have first hand knowledge. Uh, but yeah, there, there is a, a library, an IAM evaluation library that ships to all of the services. And that includes caching of policies. Right. And so, um, I'm, I'm confident the evaluation of the policies is, is very fast and they've probably optimized the path of that code incredibly well. But you've also just got the raw I/O and network of how many policies apply to this request. How far away are those policies right to be able to get. And so there is different levels of caching. And there's probably, I would guess, some level of, of caching involved based on, you know, these request parameters, this set of policies, you could kind of hash those into a combined result, but I don't have any first hand knowledge of that.
Okay. Fair enough. Fair enough. Well, what are some of the examples where you mentioned that you think people get this wrong. Awesome. I think, you know, you've already educated me on something that I had wrong in my own mental model of it. What are some other examples that you use to kind of educate people on how it actually does work, as opposed to some of the ways that they might think it works?
Yeah. I think, um, what I just see is a lot of misunderstanding, right? Uh, and so I'll give you an example. I was, I was interviewing for a company last year and I had to do a live coding exercise of figure out what roles can assume what other roles, and IAM trust policies. That's the JSON document that defines who can assume a role, uh, are a little different than a normal resource policy. And I was in the interview doing the live code. You know, this is like super high pressure situation kind of thing. And I was like, oh, uh, it's in the same account. So it doesn't matter what the identity policy says, the trust policy allows them. You're good. And the interviewer said, no, no, no, that's not right. That's, that's, that's actually not correct. It's got to be both. Trust policies are different. And so I took their word for it in the, in the exercise. And then right afterwards I looked it up and sure enough, I was right. Right. There's just these, uh, common myths that, that persist around IAM. Yeah. Same thing with kind of same account versus cross account, um, uh, permissions and, and how those work and, and so you see that a lot.
The other thing I've noticed is like AWS has a ton of IAM documentation, but it still seems to never be enough, right? Um, so a great example is there's all these different condition keys, right? So there's, there's these base condition keys for like a string equals this or a number is greater than that. But then you can totally right. Uh, some are single value. Some are multi value. You can put if exists on all of them. And so you end up with like one hundred and fifty different combinations of, uh, condition operators. You can put in an IAM policy. Yeah. And those results can dramatically differ based on like adding a suffix, right? Or you might think adding a suffix does something when in fact it doesn't do anything. Um, and so like, one of the things I did was I went through and I documented every single one of them along with, uh, examples, like for an allow statement. If you have this condition and these values, you know, would it be allowed or not for a deny statement? You know, if you have these values, etc. So like for all values, string not equals ignore case in a deny statement. Yeah. Like no, no normal human can quickly explain how that works, and no one they would talk to would actually understand that. And so I built that out to kind of help people understand those things.
Got it, got it. And so as you think about that, I mean, one of the other things that comes to my mind is that I think like a lot of people, myself included, who got our start at a, let's just call it a certain era of, of computing. We were very used to kind of role based access controls, right? There are users. Users are in groups. Groups have access to whether it's applications or data stores or whatever. What's different about IAM? Because I know that's like a piece of IAM today, but I think it's evolved beyond that. When you sit down and you talk to people, how do you help them make the kind of transition in their own mental models from like classic RBAC to what AWS IAM looks like today?
Yeah, I think, I think it's to AWS credit that they have such an amazingly flexible access model, right? You can, you can really do anything. And when you talk to people that are like trying to decide, you know, am I going to primarily deploy to Azure or deploy to AWS, etc? One of the things I hear is, uh, you can do anything in the AWS permissions model, like pretty much anything you want you can do. And, uh, that's a selling point, but it's also really easy to get it wrong. And so that's a, that's a challenge, right? Um, I think of it almost like a functional programming language. Okay. Right. You're not, you're not so much defining, uh, your groups and your roles, even though the word role is in there, you're really defining for a, for a given principal, uh, and a given set of variables that might get passed in, right? Like what's it going to evaluate to? And then the same thing on the resource side, right? How do you, you, you're basically defining, uh, a set of functions that, that get applied, uh, based on, you know, passing in the global context and the resource that's being requested and the principal that's requesting access to it. And if it returns true, they're in. And if it doesn't, they, you know, they're not. And that's a great way to have that flexibility that I think AWS customers need and builders need. It just leads to this infinite set of possible outcomes that are difficult to reason about, especially when they're combined together in confusing ways.
Yeah, that leads me to a question, though. When I get, you know, and I used to get this question a lot, not so much today, but let's say going back like eight years ago when a lot of organizations were starting to make a big push into the cloud called like the twenty seventeen, eighteen nineteen time frame. Um, and then of course, obviously, you know, during COVID, there was a massive rush to the cloud as well. But I would see one of two patterns emerge from organizations that were making the shift to the cloud, and one was either like organic. It was just happening. Um, you know, people got access and they just kind of did whatever the heck they wanted. And that led to all kinds of mess and disaster and misconfiguration and blah, blah, blah, you know, all the sprawl and terrible configurations that you would have ever wanted to see. But the other pattern I saw from organizations that were maybe a little bit more thoughtful and had a little bit more of a kind of at least some level of control was they would often want to try to balance like, you know, freedom to go do stuff quickly in the cloud with some level of corporate control. And what I would often see is they would say, okay, some team, the quote unquote, cloud center of excellence or something like that would define like the VPC structures and the IAM structures. And they would say like, hey, I've designed our networks are like this. Our segmentation is like that. We have this type of like gateway and NAT translation and public facing private, etc., ET cetera. And then on the IAM side, we've laid out basically like, these are the roles that should need to exist in order to run the different workloads that we anticipate having within this cloud account or within this VPC or whatever the case may be. It's for that use case that I've always kind of struggled to explain to people, like how they should think about it differently when in particular, again, a lot of these people come from similar backgrounds to myself and they're like, great, well, I'm just going to create these roles and, and these groups and that should govern everything. And anybody who needs access, they're a user. They get added to a group and that group gets them access to the things they might need to do. What do you think about like that strategy in terms of doing a cloud migration or doing a cloud architecture today? Is it appropriate for the way that IAM works, or does it like miss nuanced use cases that are nuanced, valid use cases that every organization ends up needing?
Yeah, I think, um, you always have this kind of tension between, uh, that kind of upfront control and planning and then the agility that the cloud is supposed to give you. Right. Right. And one of the big selling points of the cloud wasn't necessarily cost savings. It was agility. Agility. And if you've if you've got that centralized team that is that bottleneck for those things, uh, you, you inevitably have to trade off some of that agility. So, so it becomes a challenge for sure. And I've definitely worked, uh, in some of those environments where, uh, everything is very well curated. You're in your VPC, it's got a VPC endpoint. And every single S3 bucket you want to access is in that endpoint policy, right? And, uh, so incredibly secure and does a great job preventing data exfiltration or things like that. But we would inevitably lose significant time to, oh, we, we need one more exception or... Yeah. It turns out when you install X, there's this undocumented bucket you need to pull from, and we need to add it to the policy. Right? Right. All kind of run into those things.
Yeah. I think the, the sweet spot from an IAM perspective is, you know, if you can do more of an account based deployment, because that really is the, the primary unit within AWS where, where permissions are kind of managed. So you can put in your, your security tools, your, your audit roles, things like that. Put in some QA to make sure those don't get interfered with. You know, maybe some things to prevent data exfiltration, things like that with SCPs. Put a data perimeter around it. To me, that's the simplest. I have seen folks go down the ABAC path. Yeah, I describe that as a, as a path to madness. It's just so difficult to get it working well in AWS, and they don't support it very well. So that tends to be a challenge. But if you can go down that path where you don't have to define everything perfectly, you can kind of delegate to that team, but know they're within their kind of account container, and you can kind of trust them and give them some flexibility within that. That's where I've seen it work best.
Gotcha. Gotcha. I was about to ask my follow up question was going to be exactly that on ABAC. If you say that like, hey, this, this kind of old school model always breaks at some point because of some exception or some new resource or service that you want to adopt, is ABAC the path towards like this is the quote unquote cloud native way to do things, but it sounds like it while it might be, it's also the path towards like losing, losing oversight onto who has access to what.
Yeah. And it becomes a challenge to reason about, right. Especially when another one of the things that's kind of unclear about IAM is you talk about that EC2 create instances, right? Yeah. It's going to or launch instances. It's going to invoke IAM. Right. But if you're, if you're launching that instance with some tags, it's going to invoke IAM once to go, do you have permission to create an elastic IP in the subnet? Right. And then it's going to go, do you have permission to read this EBS volume? Do you have permission to create these tags. Right? And every one of those has like slightly different context keys that goes into the request. So to write a policy that says Jeremy can only create EC2 instances with these tags. Yeah. And control EC2 instances with these tags. It becomes such a non-trivial problem that I think a lot of teams give up. Um, and I don't blame them. That's why I recommend the account approach.
But that comes with real tradeoffs, right? Like networking in particular gets really challenging in an environment. Access from workload A to workload B for data sharing, copying like service calls, etc.. Yeah. And unless you want to route all that stuff over public facing APIs, which comes with its own set of challenges around one, how good are your APIs? And two, that has cost, you know, you're routing some set of calls externally. There are, you know, it might be small, it might be trivial, and it might even be in the same region. So you, you can mitigate the cost element of it, but there is some cost involved unless you want to do, you know, trust relationships. And then as soon as you start poking holes between account one and account two, you start breaking that barrier and that kind of blast radius control as well. Right, right. Yeah. You do it at the network layer then, right? Instead of the identity layer and it becomes a, it becomes a huge challenge. I'm blessed in that networking is somebody else's problem. So I don't worry too much about it.
Yeah. Fair enough. I, I came actually more from the network side. So I was happy. I was always happy that IAM was somebody else's area of expertise. My greatest kind of, uh, let's say like claim to expertise on IAM was I did some time studying graph databases and graph technologies, and I realized that IAM was much more of a graph problem than it is a relational database kind of problem. And so like, okay, as long as you can map out the principals and you've got enough time and compute resources, you can eventually calculate the answer to a problem. So, um, speaking of that calculation, I, you know, I have a story from years ago with a large e-commerce company that I was working with at the time. I wasn't working for them. I was helping them through their cloud security strategy. And they told me this story at the time, they had about eight hundred software developers. And I don't know how many AWS accounts, but they, they would go through a quarterly audit exercise where they generated a random set of tasks for every developer, and they stopped all production development work for a day. And they would give to each developer a set of tasks and ask them to try to complete those tasks. And they would be like, hey, David, go run EC2 launch instance in this account, this region. Hey, Jeremy. Go create S3 bucket, this account, this region or try to access S3 bucket, this account, this region. And they gave these out in Excel spreadsheets to all of these eight hundred developers. And then they took the results back. And I have no idea what they used to correlate it. And I hope it wasn't some poor intern, but I kind of in my head think it was. And then they would just like go through an audit and be like, oh, yep. Jeremy S3, this account, that region, oh, he was successful. He should not be able to do that and then try to track down like, where did I get that access from? And so like, I know that this is a problem that continues to exist today. And this was, you know, roughly eight or nine years ago that I had this experience. But I take it you've done some work in trying to write some tools that can help organizations answer some of this. And some of these are open source on your, on your cloud copilot dot io, if I'm not mistaken.
Yeah, I, I'm sorry, before I answer. That is such an amazing story. And you could tell by looking at my face. I knew exactly where it was going, but I didn't want to spoil it. I'm just like that. Um. I just would have loved to have been a fly on the wall in that meeting where they're like, what if we just... Oh, it's amazing. Yeah. Uh, but yeah, absolutely. I did build some tools to, to work on that. So for a little context, uh, in twenty eighteen, I joined a VC backed, uh, CSPM. And that was really my first introduction to like building cloud security tooling. And, uh, and that was a fantastic experience. And once I really dove in deep on IAM, that's where I became so enamored with the space and just kind of fell in love with it. Nerd sniped is the term I used, right? I just, it's just like, oh, this is amazing. I love it. Um, so yeah, starting in, uh, let's see, I think twenty twenty four, I started kind of building some tools around it, really just saying, okay, if it really is just like a functional programming language, I should be able to implement the runtime, right? So starting from the most basic units of like, okay, if we have a policy that allows an action and a resource and a principal with some given conditions, how do we evaluate those correctly in all the different circumstances? And starting from that kind of fundamental question of, uh, you know, what's a good policy look like? How do we properly interpret a policy, uh, build on top of that? How do we map, properly model these interactions between all these different policy types? Uh, yep. Uh, and then combine that with data. So getting the data was actually probably more work than building the evaluation engine. Uh, just because of the disk, the network I/O and rate limits and things like that. So I have a library called IAM Collect that, you hook it up to an AWS account and it gets, uh, all of the policies and all of the resource policies from pretty much any service that supports resource policies. Yep. And downloads them to a file system, an S3 bucket or a SQLite database. And then I have a project called IAM Lens that puts together that evaluation engine with that, with that store of data. And that's when it gets really interesting and cool. You can start asking really interesting questions. So the simplest is like, let's simulate Jeremy trying to read from this S3 bucket. And if you're not allowed, we can see a verbose output of line by line like which, which SCP blocked him, which statement in that SCP blocked him and even like, which, uh, you know, every single condition and how it matched or didn't. Right. Yeah. So then you start kind of scaling that out and you can go, okay, now that we can run this at scale, we can look at the S3 bucket and say, show me everybody who can access this S3 bucket and just get that information and show that. I remember, um, a couple years ago, I was talking with a security leader at a bank, a very big bank, and I just said, hey, if, uh, you need to know who has access to an S3 bucket, what do you do? And their response was, oh, I have a person that I assigned that task to, and they go figure it out. Exactly. Right. And so this kind of, this kind of automates that and, and provides that information along with, you know, what policies and path they follow to get to that, uh, if they want to get that information. Um, the other big thing it does is kind of the inverse, right? You start with a principal. So you say, give me, give me a role and just show me everything that role can do. And it will look at all the policies and subtract out all of the SCPs and RK and look at resource policies and give you kind of a JSON view in the AWS IAM policy format of what those consolidated permissions look like, which is another, another big problem to work on for sure. For sure. Yeah. Yeah.
That's awesome. We'll have all this linked from the show notes for anybody who's interested in cloudcopilot.io. I want to change gears for a second. So. Sure. Okay. That's where we've been. And I know we continue to have challenges around that. What are you hearing from organizations that they look to build out kind of AI backed workloads on cloud platforms, those who are building with bedrock, bedrock, agent core, all these things. What are some of the IAM challenges to be aware of as we start building out in this direction?
Right. I think before we, before we even like deploy to bedrock or anything like that, we have an AI challenge around, uh, Dave is running Claude Code on his laptop and his laptop has credentials or environment variables. And I know FireTail, you know, helps with some of that, right? Yeah. Um, but, you know, how do we know the difference between Dave is running a AWS CLI command and Claude Code is confused and running a CLI command. And, you know, we trust Dave and his judgment, but not, but his AI, we might want to apply a different level of scrutiny. And, and we don't have an easy way to do that right now. Um, so that's, that's definitely a big challenge. I think the other one is just, you know, how do we know who's doing what? Um, in terms of, I ask an AI agent to do something and what is the intersection of that agent's permissions and my permissions. And that goes both ways, right? So it's the agent may have more permissions than me and I can abuse that. Right. Or I may have more permissions than the agent. And how do we make sure that if I direct the agent to do something, it's limited to the scope of what the agent is authorized to do. And then how do we have the proper kind of logging and things like that in it? Um, so it's a huge challenge for sure. Uh, I would say, you know, a lot of my feelings about this kind of AI era is like, we didn't understand IAM going into this and now we're, and now we're adding all of this on top of it, like, oh man, we really got to focus on fundamentals here and get that right. And I think, um, we need some new primitives from AWS to be able to really support this properly, right? So for example, in the, uh, one of the communities I'm in, somebody was asking, I have a human who logs into Identity Center. Um, they should be able to delegate to their AI, but when you assume a role in Identity Center, that role can't assume itself. So you can't easily scope down those permissions and give the scope down permissions to the AI. What do you do? Right. And so it becomes, uh, you know, something that really the, the CSPs need to address directly. Uh, but these, these are big ships. These are hard problems. And as soon as you put it out there, it's kind of there forever, right? As we've seen from some of the quirks of, of IAM behavior. And so I respect it. It takes some time to sort it out, but I hope they get to it soon.
But in general, like, would you say that the same kind of principles around like, hey, let's make sure that, you know, we have an over scoped, um, let's say on IAM roles that get assigned to different workloads that have access to the different platforms, right? Like, and, you know, and let's say best practice is if you're going to do role based, uh, IAM role based workloads, then you should use a unique identifier for each workload. And that workload should be like at least, you try to do your best in terms of giving at least privilege and what it has access to, like what it has access to, to execute the workload and no more, you know, kind of least privileged principles around that. Like that all still holds true, right?
Yeah. And the fundamentals become more important, right? Because we've, we've all seen the report of an AI assisted attacker gets into an environment and they escalate from initial access to admin access in less than ten minutes. Yeah. So that that least privilege you're talking about that we've all talked about for, for many years, right, has gone from like, well, it'll probably be fine to if it's wrong, it'll get exploited and it'll get exploited very quickly. Yeah. How do I find that and, and remediate that ahead of time? It's, it's really raised the level of urgency on the, on those.
Yeah. I think that's one of the things that I, I try to emphasize in people that I talk to today about AI workloads as opposed to user AI. And I always try to make the distinction for people. Like even when you think about things like open Claude, those are generally what I think of as kind of workforce AI. Like they're either personal usage or they're personal automation, right? I'm trying to accomplish Jeremy tasks as opposed to like workloads and applications, which I think of as like, I've got an agent that is a customer support chatbot that operates autonomously, or I've got an agent that is meant to process a loan application for somebody, right? You know, that's like a workload, right? And I think like the least privilege principle should apply to both. We tend to be bad at it in both environments. In my personal opinion, I don't know which environment we're worse at. I tend to think it's the employee side. I tend to think employees have access to too much, because I tend to think that application environments are a little bit more controlled. Uh, like they're a little more deterministic, right? Yeah. But I don't know if I'm right about that. And I'm sure the answer is it varies from organization to organization, but in any way, it's great to hear your thoughts on, you know, how to think about it. And certainly like that kind of mean time to exploit or exploitability is just like dramatically shrinking. And I point people to the zero day clock around vulnerabilities and everything around that as, as kind of proof of where we're living today. We're coming close to the end of today's episode, and I've got a couple more things I want to kind of get your thoughts on. First of all, we've talked a lot about AWS IAM. Pretty similar for Azure and GCP? Or do you see a lot of difference between them?
I, uh, I will confess it's been a, it's been a while since I've looked at them for Azure and GCP. Uh, I would say the Azure model, uh, is, is simpler in some ways and kind of easier to reason about. But people I talk to in that space say they have the same problem of, I still don't know who has access to this thing. Um, GCP, being the new kid on the block, relatively speaking, I think has come up with some really novel solutions to problems that that older CSPs have run into. But we still run into the same things, right? We build things of sufficient complexity, and then we just lose the ability to kind of reason about them. And without good tools, we, we are probably making mistakes. And because access denied alerts or access denied problems get tickets filed. Excessive access problems are probably the direction we're leaning in. Right? Yeah. Yeah. Yeah. Fair.
Awesome, awesome. Well, uh, let's talk a little bit about Act Security and what you guys are up to over there.
Yeah, sure. So, um, Act Security is an Israeli cybersecurity startup still technically in stealth. And, uh, it's a very simple value prop, I think, uh, but a very difficult technical problem. So when you decide what access you want to grant, right, you might file a Jira ticket or you might make an architecture diagram, say, you know, Jeremy wants to invoke this lambda and this lambda should have access to these two DynamoDB tables or whatever. Yep. Uh, that gets turned into some Terraform or some CloudFormation. It gets deployed. You might have CloudTrail or some other tools that are monitoring what's actually happening, right? Uh, but you don't have a tool that shows you, uh, what permissions your Terraform actually granted, right? Right. And, and then when you get into those complex interactions between different policy types or different deployments, that that might impact that original intention that you had, you don't have anything that shows you, uh, that delta between, oh, here's what I meant to do. And then here's what I actually did. And that, that delta is just risk, right? It's literally just risk that none of your existing tools can show you. And so that's what we're trying to help customers find. And then creating the policies and the pull requests and things like that to, to eliminate that risk.
Awesome, awesome. And people can find you guys online at it looks like act.security. Yeah. It's a great domain, isn't it? Yeah. That's a great domain. All those dot security domains cost a pretty penny, though. I will tell you, we've, we've looked at them for ourselves as well. And yeah, they're, let me say premium priced even, uh, even more expensive than dot ai domains, but awesome. Awesome. Nice. David, any final thoughts as we wrap up? You know, like if you were to tell anybody what they should take away from today's episode around AWS IAM in particular. Obviously there's the kind of, hey, it works slightly different than what you probably assume, but what are any other kind of, let's say, like nuggets of wisdom that you would share with anybody to make their own lives easier as they struggle with managing IAM inside their own organization?
Yeah, I would say when you're, when you're going down that path, just start slow, really crawl, walk, run. Right. Okay. And, and really focus on trying to understand exactly what you're doing when you're doing it. Uh, if you're a developer, I know *.* makes all your problems go away. And I would encourage you to just kind of push through the pain of like, let's find, uh, exactly what we need.
And especially if you're... sorry, I don't mean to interrupt, but especially like nowadays, you can go to ChatGPT and you can go to Claude and you can describe like the task that you're trying to accomplish and, you know, it'll tell you here's the permission that you need. And by the way, here's the JSON representation of that permission. If you really need, you know, like to, to codify it. Like, it just seems like there's, there's less and less excuse for *.*. Sorry. That's that, that's my little soapbox rant around that.
I, I've also seen, um, them hallucinate like they'll make up condition keys that don't exist. Uh, and, and it's, and it's unfortunate too, because you're like, where did it get this from? And then you find blog posts of people that have published those, those policies with condition keys that don't exist. So just, just be careful. Um, but, but really, I would say, um, you know, there are tools now that exist that would allow you to almost like unit test your permissions that it allows what you think it allows and it doesn't allow what you don't want it to allow. And I would encourage you to lean in on those tools and learn how to use them and, and keep your customers safe.
Awesome, awesome. Well, I think those are great words of wisdom to end today's episode on. David, thank you so much for taking the time to join us on Modern Cyber today.
Thanks, Jeremy.
Awesome, awesome. And for all of our audience, all of our listeners, rate review, like subscribe, all that good stuff. We will talk to you next time on the next episode of Modern Cyber. Bye bye.