Ashish Rajan: [00:00:00] Hey man. Welcome. How’s it going? How good morning man.

Fantastic. Cool. So before we get into it, I know a lot about you . I’ve known you for years , through the work that you do for the community, community hero APN Ambassador , and everything.

But so people who do not know what was your part into the whole cloud security space?

Ian McKay: Yeah, so I started off in thinking about cloud security. Even before I got into the industry, I started off playing with things like virtual, private servers and those low cost. Seven management tools learn the basics around server administration, the basics around security and authentication and things like that.

And I felt like that was really good. Why did you just learn? I’m a very learn by doing sort of person, I don’t really tend to, go through training and things like that. I just tend to break things and figure it out from there. And even from there, I moved into the industry and then went the basics.

General administration and in an on-prem environment. So that’s things like managing firewalls and VPNs and the server in sort of environment. And then when AWS released , [00:01:00] in the Sydney region and I started to, touch into cloud environments I believe the company I was working for was doing some sales environments at the time, and they really wanted to access that remotely and without any hassles.

And so I started to spin up. Environments in the cloud. And I learned a lot about, how it works differently in the cloud and how it’s not necessarily about firewalls and things like that anymore. It’s more around identity and what that really means in the cloud, which is very different. In my journey with consulting, it’s met a lot of great people.

I joined. Partner network ambassador program, where we met, like we said, and eventually became an AWS community hero for a bunch of the publications and the talks and things that I do online.

Ashish Rajan: So maybe the first one we should start off with considering you’ve had a long history of working in the space as well. How different is IAM in AWS or I guess compared to on-premise.

Ian McKay: Yeah, it’s very different sort of feeling in on-premise you’re dealing with firewalls and net goes and your general [00:02:00] basic security it’s that’s usernames passwords, usually backed by an LDAP server and things like that.

When you move into the cloud, it’s very different identity. Suddenly it doesn’t mean only your user identities, but also means. The components that make up your computer as well. So your servers and your things that are really serve like serverless Lambdas things like that. And so suddenly those servers take on their own identity and they have privilege to do things or not do things.

And that’s a very different way of thinking when you’re working in a traditional service environment, everything is just network isolation and you can see of the. The compliance and that sort of thing is still trying to catch up with that idea of identity in the cloud and trying to make sure that that’s correct.

Ashish Rajan: She has interesting, so for people who are watching it, I’m just curious if anyone knew that there are more than one identities in AWS, I guess the whole robot user concept. Where things could be happening.

Like it could be Ian credentials, but it’s not technically. Ian what, I mean, I hope, I wonder how many of you believe in knowing new about the [00:03:00] difference between on-premise and identity as you explained it, and whether they have you known that there are robot users, as well as the key. So. Since you’ve explained it what are some of the the building blocks for doing identity in Amazon.

Cause I think my aim with this episode is also to help people understand just the broad idea space, but they haven’t started on it or all the way up to they’re doing it, but they probably are not aware of everything that could be done with it. So from that perspective, what are some of the building blocks for?

Ian McKay: Yeah. So in, IAM there’s a few things that you need to understand pretty, high level, the main things you’re going to concentrate on are things like roles and policies. When you talk about user identity, although we have the traditional IAM users, that’s moving away from that space at the moment.

And that’s usually termed as a longtime credentials, perhaps. With your identity. Now we’re seeing a shift into Federation and identity via social provider or by some of the major players out there, like Okta author or things like that. And so, although. Those users have different ways of [00:04:00] coming into the environment.

In the end, they still have policies that are attached to them. And policies are statements that say, you can do a number of things, or you can not do a number of things. And this is what we call our allow or deny actions internally. And so these statements have a bunch of resources. So that’s the things.

And those resources can sometimes have conditions as well. So you can do X to this resource, or only when this condition is met. So it’s this time, or this resource is of a particular type of things like that. And so we write these,IAM policies to define what that means and define the rules about how things communicate within the class.

Ashish Rajan: And so to your point, then the roles but there are these service roles and stuff as well. Like what are those, like, how are they different?

Ian McKay: Yeah. So we mentioned that earlier that servers now have identity, but even managed services in the likes of valuables have identity now. You can say that, although this particular service is part of the cloud and part of what’s coming to the cloud, you can still [00:05:00] deny access to that service, to achieve what we call the least privileged in the environment.

And this concept of least privilege just kind of a difficult one to achieve and to understand, but basically what it means is you should only be allowed to do the things that the service or the identity needs to do. And no more. So this prevents you from, if those credentials leak having a broader impact against your entire environment, and it will impact the things that are in its immediate vicinity.

It’s like a blast radius containment, a sort of concept.

Ashish Rajan: Okay. And maybe this is a good point to kind of bring in that in how AWS itself has all these subcategories, as you mentioned as well with sub service roles and like IAM roles and everything. Is in a world where we are, I guess, moving quite fast.

Thanks to DevOps. You being the devops guy from Sydney . It’s also, asking a lot of people to manage a lot of things really well. And the scale of it is just going out of hand sometimes as well. What’s your opinion on using, say AWS given tools for managing identity [00:06:00] vs , Open source.

Ian McKay: Yeah, so this AWS tries their best to provide the tools that you need to manage your environment. But we’ve seen time to come in again, that isn’t always the case. And it was sometimes breaks its own guidance in this space. So really sickly, you should be looking at the tools that are popular in the open source community, within identity, and having a look at what they actually doing.

A lot of the times, these tools are trying to. fix a specific problem insecurity. And sometimes these problems are really focused on enterprise and sometimes these problems are really focused on the basics within security. And so, most people that I talk to you, I generally advise to do a mix of the AWS managed tools.

And when you see the gaps, you can substitute that with the open source tools or even in the SAS providers.

Ashish Rajan: Right. So to your point then well, I guess you can, you can choose to bring in the SAAS provider tool or it can do otherwise, but at what point do you think people kind of have to make that call?

Like what’s that someone with, I don’t know, five people think you have to make that call or, I mean, I imagine there’s some best practices there as well. [00:07:00] At what point do people have to kind of start saying, Hey, this is not good enough for me. And it need to kind of bridge or, , take a pivot.

Ian McKay: Yeah. When you’re, when you’re really starting off with. AWS will protect you generally. So you don’t really need to branch off if you’re a five or 10 person company, and you have maybe one or two engineers working on this, the AWS tools do do the basics of what you need, where it kind of becomes a problem is when you experienced that growth phase.

And suddenly you’re starting to do with new problems that you might not have dealt with before. So things like insider threats or things like lateral movement from an attack, a specific. When you’re just starting out, you’re not really focused on those things. Everyone is trusted. And if that person becomes compromised, your company’s compromised no matter what, then there’s no avoiding that.

Ashish Rajan: Right. Also it says more than a pro I mean, I guess, a measured risk approach, I guess, for lack of a better word. Yeah. Okay. So maybe another way because the reason that the thought for that question was also behind, , how you have mapped. Permissions and especially the ones that just don’t have any API calls in there.

I’ll let you drop [00:08:00] what the project as well, but what made you code on that part and what was the I guess the tool and everything. So if you don’t mind sharing that story for the audience as well. Yeah,

Ian McKay: sure thing. So I’ve recently I’ve been solicited number of tools that are in the,IAM specific space and that’s talking about mapping the API calls that you make to edit a service.

To the,IAM permissions that mapped to it. So you might’ve seen permissions like EC two colon describe instances for example. And they relate to the API call. Describe instances within the ECE two service. And generally you can look at them and most of the time they mapped one-to-one, but sometimes they don’t actually do that.

So sometimes if you do a S3 dot lists buckets, for example, that actually maps to the, I am call S3 list all my buckets. And so sometimes you get this weird mismatch. I constantly saw a lot of people getting this wrong and I’m seeing some problems in that space. And so I really wanted to create a mapping that shows you how X relates to Y in that API to IAM space.

And so, there’s a project out there called [00:09:00] permissions.cloud permissions that cloud now expense to both not only I, I w S but also to Azure and GCP now. And you can basically use that to look up. How x matches to Y and what are the various implications of that as well? So there’s a privilege escalation potential, or if there is a resource exposure, potential and things like that.

So it’s been a guide that goes above and beyond what AWS would generally provide, which is just the permissions themselves. Right.

Ashish Rajan: So would you be able to use permissions dot cloud to understand I guess if you’re truly doing least privilege based or an IAM role, or how would I.

Ian McKay: Yeah, it’s a really excellent for trying to go down that path of least privilege.

They actually, what came out of this was the generation of the mapping, which is, over a hundred thousand lines. And, that mapping really backs this tool that I made called IAM live that IAM live tool basically looks at your environment real time as it runs either locally or in. And generates the IAM policy dynamically.

So it will look at your network traffic and say, yeah, this coal had these, properties against it. And therefore [00:10:00] the ARN and the action should be this. And so you can really quickly generate the, your least privilege policy, but it’s a bit of an advanced tool. , it’s one for those who really want to go deep on least privilege and the way that you would achieve that.

But it helps if you have. large applications, which really there’s some really hard to kind of press reference from the drip system, the traditional ways of doing that, which is looking at CloudTrail logs and using some of the source tools in that space to, overprivileged something. And then reduce that back off to that.

Ashish Rajan: So this flips the script on that, is that why you feel it’s a bit more advanced because I think

Ian McKay: So this takes it back a bit from, looking the general way that we used to do this with things like, cloud trial scrape pro and the IMX analyze a recently introduced from AWS was that they would over privilege something with admin access was something similar to that.

And then observe the calls that were made and the permissions that were made real time. And then eventually scale that back. That’s kind of scary to me. So this kind of flips the script in that you can actually block the, permissions as they happen, and then gradually [00:11:00] introduce those permissions.

So you start from zero and go up to the permissions that you need rather than starting from everything in producing it back.

Ashish Rajan: All right. Okay. So kind of like falling AWS principle as well, where AWS kind of, doesn’t give you access to everything many kickoff on this, you get a role. So similar to that, basically you start from the point of least privilege and then you’re given more roles and everything.

And then you just basically to do some, the roles.

Ian McKay: Yeah, at least pretty much, this is the kind of learning concept because there is a various stages of least in least privilege. So at least privilege to some much mean, oh, I scrape it down to S3 Coinstar and I was keeping it down to just the service or I Skype it down to just the action and not, and wild Cod resource, for example.

So there’s a lot of different levels of least privilege, I guess you could say that isn’t very clearly defined. If you’re doing some of this, it is a lot better than doing none of it. So it’s one of those continuous improvement sort of things.

Ashish Rajan: Yeah. And it’s funny with, IAM specifically in AWS as well.

It’s always considered complicated and, we kind of spoke to the difference between the whole on-premise world, [00:12:00] as well as in the new world. Where do you see as some of the patterns for identity? I imagine a lot of people look at I didn’t, you didn’t go. Oh. And as soon around this conversation, when people talk about, I have an active directory, I haven’t been main controller around premise moving to cloud.

And I just want to make sure that I have a domain control. quote unquote login with the windows credentials. What are some of the implementation patterns that you see from that perspective? Cause there’s an identity perspective from say you logging into a console, getting roles and all that.

And then there is another concept of identity. , which is kind of where it just goes back to shape and people talk about domain controls and active directory and, AWS, what are you seeing over there in that space?

Ian McKay: Yeah, so there’s a lot of different implementations, especially in a user identity web.

This implementation can go kind of wrong. Usually people. Have a really fundamental problem with understanding the roles internally about who has access to what and what permissions they need to do their job. And so sometimes you can get this mismatch about the roles that they’re actually granted [00:13:00] and the things that you intended to grant them.

So that’s a problem in this space and of course, securing the boundary is also a big problem in that. It’s very hot. Let people do what they need to do, but also contain the blast radius, I guess, especially when you have public services that are things like cloud crowdfunded, S3 buckets, and all the types of stories that might potentially be publicly exposed and edit versus traditionally had this problem where buckets would be exposed to the world.

And they’ve introduced so many controls around trying to get that right. But now even, even though pockets started off secure by default from the very start, it was very easy to kind of unlock that and introduce that to the world. And it was just putting a lot of barriers in front of that to make sure that that doesn’t happen because in the end, if it’s confusing for customers, then they’re going to this configure it.

So that is the general.

Ashish Rajan: so to your point then, is there some responsibility with AWS as well cause how a lot of people talk about the fact that officiate AWS, Hey, security is the number one responsibility, but you almost feel that as [00:14:00] a cloud service provider, and this is not mean dishing on AWS, but it’s trying to again, get a sense of.

Considering you’re the community hero as well as the APN ambassador where people like you and I get to talk to people from AWS quite closely is the, but it, should we be asking them to be more responsible for this as well in terms of making it super easy? Because every time I spoken to someone aboutIAM and in AWS, it’s not like, oh my God, I just want to like, so people will try and make sometimes 25 $30.

Or sometimes they try and go. We only want five. IAM roles. I don’t care about. What else do you need? If those five, IAM role to define everything. I’m sure you mix up, you see a mix of that as well, but do you find the complexity can be reduced quite drastically by AWS themselves? They actually kind of focused on that.

I don’t want to blame the AWS IAM team, but I’m just curious your thoughts on this.

Ian McKay: Yeah, I think that’s evolved at a time. I know AWS have really struggled in thinking. The services, team’s thinking in the way that engineer’s thing versus thinking about how a customer thinks. And a lot of the times they don’t [00:15:00] really match up.

So you’ll see implementations that are very , engineering specific, but when it actually comes to how it actually works in the real world, it’s not intended, it’s not really what people expect. And so you can still sort of get this mismatch and it’s not the engineer’s fault. They’re just doing kind of, what is the scope that they’re trying to do?

Requirements and implement them literally. Whereas when it comes to the UI and the testing of that, sometimes it just falls short. And a lot of the times that’s actually because, the AWS need to secure that. AWS wants to make sure that things aren’t linked early and the use of testing pools are probably fairly low.

And they’re obviously have internal testing as well. That’s the sort of cost benefit trade-off that they would have, and , it’s a hard problem to solve.

Ashish Rajan: So they’re moving towards more customer rather than , engineering based approach. It’s

Ian McKay: something that they’ve tried to evolve on over time. They haven’t traditionally done this super well in the past, but they’ve started to really understand and take on the customer feedback. So even though they had all of the controls that could secure [00:16:00] buckets in the past, I have a time that introduced , more layers and more layers.

And I’m using the system, the easy example, quite a few times. So they just have to implement , these extra ways to really drill into the customer that now you’re what you’re doing is a huge risk. Please, please don’t do this. But they have to kick the features there because they don’t deprecate features, especially in AWS.

And sometimes it’s legitimate reasons to have public public facing objects. Sorry. It’s all very complicated.

Ashish Rajan: I’m just curious now for people who are watching on a scale of one to 10 with one being not novice and 10 being expert, how people rate themselves in terms of that IAM knowledge or even the complexity that they have, cause I normally find that. It gets complex really quickly, based on the scale of number of people. Number of roles, number of teams, checkpoint is starting off with us in a startup with like, I don’t know, like less than 10 people, everyone can hire an IAM user and , you swing around like, oh, that’s Ian, oh, that’s Bella .

Or that or someone else, but in a world where scale is obviously quite hot, What are you [00:17:00] finding as some of the best practices for IAM in AWS? Especially as people kind of scale from say I was just using,IAM using the beginning now. I know I have legit use cases. Are, do you see people’s scale?

Ian McKay: Yeah. So I think , there’s a few good tips in this.

Some of this is from AWS and some of this is advice that wouldn’t take from anywhere. So things like starting your boundaries. System early. One of the best ways to ask you to do this is to use a service control policies in most organizations. The reason I say that and not something like permission boundaries is that permission boundaries kind of get in the way you have to kind of work in a bit of a different way.

When you’re managing your roles, when you talk about things like permission boundaries, the SEP is a really simple there. This is the things that I’m not allowed in your environment full stop. And so if you want to do something simple like ban a region, because we never want to deploy into Ohio for example, then we can do that very easily.

And so. Getting those boundaries in early means that you won’t interrupt your developers . And when they do eventually hit those things [00:18:00] there, that’s one of those things I’m not allowed to do. And so it’s really easy way to to get started. Obviously there’s the basics like, enforcing MFA on your user accounts, whatever the identity system is.

So you can start an,IAM users if you don’t have anything, but I highly recommend using NMS. SSO actually makes things a lot easier. And one of the weird ones is to set up a billing alarm. Like that is the number one thing that everyone should do in AWS. And that’s not just for your cost controllers, but it’s also a subtle indicator that something’s going wrong in your account.

If suddenly your bill goes up to something sky high, , you’ve been compromised, , you need to get in there and stop things, stop damage before it becomes. Have a think about least privilege, but don’t go crazy all at the beginning. Feel free to use the managed policies at the beginning, and then start to produce that back into more customized discrete policies as you grow.

But you can start off with a managed policies. That’s okay. Have a think about things like lateral movement. So if X to Y and Y can talk to Z, then technically you’ve got a [00:19:00] path from X to Z. And so you should really think about. How that works and what kind of boundaries you want to put in place to stop that flow of data and reduce the blast radius.

. And there’s also a lot of things that AWS say that aren’t really recommendations. And this is where it’s going to get kind of controversial for some people. So everybody traditionally said to use IAM groups to sort permissions between a number of users . You can do this pretty well in AWS SSO, but the,IAM version of groups.

I wouldn’t recommend. The reason I don’t recommend this is that it works poorly for deny actions. And so deny actions don’t really work effectively against IO groups because groups is kind of a second class citizen in terms of the identity space. And so I wouldn’t recommend using that. I would, you can apply that to the certain roles that you’re assigned to users, but not to the iron group specifically.

So I’d avoid that. And one of the things that. People use this sort of get out of jail free card in terms of trying to secure, a lot of [00:20:00] resources is a back or tag based access control. And I really wouldn’t advise that that’s one of those foot guns that can really easily hurt you. If you don’t know what you’re doing.

Cause tagging when it came out was traditionally not a. Secured core. It was generally thought of as, oh, this is good for management and observability and billing and things like that. But now that we’re starting to use it for privilege and who can access what it turns into this really easy way for compromise to happen.

And I’ve done some research into some various exploits in the tagging space that really show , how brutal this is. And so I wouldn’t advise going down that tag based access control route would really think about that traditional a role-based access control or specifying discreet resources in the cloud.

Ashish Rajan: So you recommend a role-based permission, I guess, leading with role-based permission rather than the tag-based permission.

Ian McKay: Yeah, absolutely. Yeah. I think , this is pushed that some people are going [00:21:00] towards a little heavier now, but in my experience, it’s really good way to get compromised unintentionally.

So you might have the best of intentions and try to reduce who can tack what and things like that. But even services themselves can arbitrarily tag resources. And you might not even know that that is the case, especially using privileges that you don’t even know. So a lot of service activation, calls can actually tag resources as they go through that.

Or a lot of the creation calls can add tags without having the underlying taking permission. And so it’s really hard to control who can access what in that space. And so I really don’t advise going down that.

Ashish Rajan: Yeah, so you can see the surprise. And a lot of people are thought to just sort of conference drama as well.

Interesting view on tagging. And just to take that knowledge a bit more deeper. Cause how AWS kind of always tells you, Hey man tag everything, everything you can find, that’s how you identify. To your point. It was used as a measure for estimating costs or business unit is responsible.

Like a lot of security folks were even saying that, Hey, you should use [00:22:00] a tagging as a way to identify if there is an event or an incident that you need to investigate how do i quickly find out although, well, tagging as a best practice has not really been effective for a long time. It in itself, that’s a whole different problem.

But cause I remember there was east part, I said, come out for a help. We will help you find resources that are not tagged. So you can tag them. Like there was like even products for that. What’s your opinion on the whole I guess incident response with where you’re going to we’re relying on tagging.

So what do you see people do with that?

Ian McKay: Yeah. So I still think tagging has its space for the organizational management of resources or identifying things like compromised resources and using that as a billing engine or a management engine, a gripping resources for specific actions that that’s still valid in this.

But I think even when you have those things actually lends itself more to the potential for compromise because so much automation and things like that have the ability to tag. And when you have that ability to tag, you can also have that ability to [00:23:00] use a permission-based tags, because there is no differentiation between what tag is being used for permissions and what tag is being used for management and cost and things like that.

And so. That’s why I say that this is a problem in the tagging space. Right,

Ashish Rajan: right. And what about these other tools that they’re coming up with? That there’s a whole access advisor plus. Yes. Yeah. So access analyzer, trusted advisor has now changed. It’s like a few more tools that are coming to the space to help you identify kind of like what we were talking about earlier, where instead of starting off with least privilege, there is encouragement from AWS as well togo down the path of Hey , we’ve assessed the services that are being used.

And I think access analyze it as this. Like what’s your opinion on some of the other IAM tools that they’ve added?

Ian McKay: Yeah. So they

Ashish Rajan: are

Ian McKay: trying to play a bit of catch up with the open-source community. To be honest, we’ve had CloudTrail based analysis for quite some time in the open source community, with multiple different products doing this sort of space and a few SAAS providers doing the same thing.

And. I think I mostly just trying [00:24:00] to get ahead of that game and trying to bring that more back into the ecosystem. Some of this is kind of going against their own recommendations as well, but I can see why it’d be native for someone who is not at that level of understanding exactly what least privilege is because it’s still hard, even for the most experienced of us.

So they’re bringing in these sorts of try and bridge the gap of. They’re doing some really good jobs with things like using the policy analyzer to give you warnings about invalid policies, the policies that might not be effective and things like that. And so these are really good quality of life improvements that they’re making.

Especially within the console experience. We there’s nothing here that changes anything about how IAM worked or. About how that kind of implementation happens, but it’s more advisory. It’s more understanding what your policies are doing and checking if there’s something that you might not expect.

Ashish Rajan: Right. So maybe that’s a good segue into my next question then, I guess, from a scaling perspective, we kind of spoke about, yep. We can do this, but lot of [00:25:00] talk about the use of CIC for this as well. And for least privilege. And so I can go into the whole supply chain side of things as well. But with the CICD and least privilege in terms of, IAM what’s like in that context, what’s your perspective on that?

Has that, should they be CICD services? Let’s just start with, I should, they, should we use them to createIAM , and then maybe you can go from a perspective of,IAM . What’s your thoughts on CICD systems and least priviledge.

Ian McKay: Yeah, least privilege. And in the context of CICD for me is one of those opinions that’s changed over time.

I used to think that CICD service should attempt to be least privilege and only have the ability to do, the very bare minimum of what they needed to do. But the concept of the very bare minimum of what they need to do is actually everything in a time. Right. So, when you’re. Scope expands and you need to do more things in CICD .

It’s actually a bigger business risk in my opinion, to slow down developers in the way that they can. And can’t deploy these actions by trying to [00:26:00] least privilege the CICD roles, in my opinion, CICD and the service built around it, should form part of a trusted environment just the same as source control repository do, if your source control, is compromised, you’re basically done.

That’s pretty much just a fact of life and a similar thing happens , in CICD. And so you should still attempt to reduce the privilege that users have and what actions they can perform, but in what they can perform in your environment, I tend to err on the side. More available than less available and just know those really, high sensitivity resources and actions, so protected service roles and things like that, that you can still put deny actions on, but everything else is fair game, in terms of what should actually go through CICD , , I aggressively think it should be everything, to the point where it’s, it’s kind of, yeah.

We have these arguments about if there’s a one-off action, these arguments are internally to the consultancy I work with. If there’s an action that you perform once, should it be automated? And, , we have this argument about yes or no, because generally you can [00:27:00] just document these things and if they ever need to happen again, then the documentation will show what you need to do.

But , when you’re trying to. Redeploy adopter, what is really strictly going to be a disaster at this point, if you’re trying to go through this entire thing again, you’re really going to want to have everything at your disposal. And that’s why automate everything within your environment is a huge step.

Oh,

Ashish Rajan: actually, that’s a good point. Cause if you have a lot of manual steps in between the automated sets, you clearly in a scenario for disaster recovery, just going through everything, Hey, something stopped working on because there’s this, document that’s there for a manual step that we had to do because one step that was, yeah, I can imagine that.

So, and maybe that’s a good segway into the whole, if the CICD pipeline is supposed to be all the similar privilege to like, I guess similar importance as a source code . Do you find that because there was multiple patterns for the CICD world as well, where one CICD that deploys into all different environments.

Then there was like this whole Baton of once the parent environment, the source control. And I mean, it’s a conversation of privilege data as well for [00:28:00] CICD pipeline. Where do you stand on that? I’m curious.

Ian McKay: Yeah, I totally stay on the side of, again, the CIC D is a trust environment and. Trusted access into your development environments, your production environments, and everything in between.

Some of this is actually going to depend on your, promotion lifecycle. So a lot of people have different ways of doing it. I tend to go on the side of immutable out of that. Where an artifact should be the same on dev on staging, on prod, everywhere that it goes. And just those environmental configurations, the only things that change.

And so that way you can ensure that we’ve tested on the X, the exact same thing is happening. Why? Other people tend to go on that side of, okay, now that we’ve done our testing in a dev wrench, we can now merge that into the production branch and then just see if everything kind of works together. But.

I’ve seen that go kind of wrong sometimes where unexpected things happen when two or more features come together and then they clash and on the spectrum of ways. I tend to go, I tend to err on the side of immutability where it’s possible, but everyone has their own opinions. [00:29:00] We could spend another hour talking about all the various ways that it kind of impacts, but, yeah, I, I did go down that path and

Ashish Rajan: I think that’s a great intro and so quickly switch gears to some of the question that came in,Ive got a question here from Tom. Are there any resources that visualize, IAM like a good map of an ERN, but mission and people as they relate to each other. Good question, Tom.

Ian McKay: Yeah. So that’s a really good tool out there from the Duo labs team from, Duo labs and Scott Piper called cloud mapper .

That’s a really good way to visualize things in the IAM context about who can talk to what, and that trip versatile kind of a way of doing things. So that’s a great open-source tool by that tool or that group, a lot of SAAS providers do this very well as well. This is one of those things that I do concentrate on in terms of visualization from an entire environment perspective.

And you can also do this. Tools like former to where it look at your resources and find those correlations themselves as well. Doing that map is a really good exercise internally, especially if you try and attempt to do that yourself before you use the automated tool and figuring out how that kind of changes , your perspective.

Sorry, not [00:30:00] fun challenge. Cool.

Ashish Rajan: All right. Thanks. Hopefully that answered your question, Tom, feel free to ask a follow-up. So I think that’s a good segway also into the fact we spoke about using CD on scaling. We kind of started the conversation with a lot of patterns are shifting towards having more Federation, more people going towards a part of, Hey, I don’t want to manage up individually.

IAM users. I want to have some kind of Federation to it. What’s like the maturity scale for these kinds of things in a AWS context. Cause. People who are listening to this already have a service roles is what what’s CICD as well. What’s like a maturity scale that you think for people to at least start here.

Like if you don’t, if you haven’t done anything with IAM start here. And this is kind of like the next level of God level, I guess, for lack of a better word

Ian McKay: Focus on those things that are immediate threats to your business strategy. And when you’re at a start up generally, what that’s going to be is external attackers, trying to compromise your system.

And then you use lateral movement to basically take you down. So. Focus on things like backups, trying to make sure that you have those copies of your data because you’re [00:31:00] busy without backups. If you’re compromised, your business is wiped out. So have those backups have those backups tested, make sure.

And that’s a really hard thing because there’s a lot of effort that goes into testing these backups, even if that turns into a once a quarter or once annually sort of deal still makes sure that that kind of works and that you understand the process of doing that. So backups number one, Don’t focus too much on least privilege for your own users in a startup phase that grows over time.

You don’t have to really focus on that, but , there’s a whole lot of different considerations in this space. So when you’re growing, you’re going to think about least privilege, DAAS , SAAS your dependency, scanning your secrets management, your incident management, even to the point of chaos engineering, all those other fancy things that we have now.

But you don’t have to consider all of these shirt away. These are very, advanced sort of, things that you really need to focus on as you scale, not as you start up anybody that’s going to protect you. And most of the other cloud providers will actually protect you by default from the start.

They just relying on you not [00:32:00] to make insecure configurations out of the box, which is kind of hard to do. As long as you follow the guidance. And most services will have the best practice. In that space. So the guidance on IAM security, best practices is really good place to start to go, to get those basics.

And looking at things like the edible well-architected reviews is a really good way to think about what your application is doing and what things you have in place in your organization. You don’t have to solve all the challenges. So that’s something like a well-architected review. Has you just have to identify that these are risks.

We accept these risks and we’ll address them eventually.

Ashish Rajan: Interesting. So, and maybe a sprinkle, a bit of a CPO on top, as well as you were saying in the beginning. So speaking of, if

Ian McKay: you can get ahead of the game, , it’s very helpful. So putting that your SCPS in, making sure your developer roles and not overly privileged, like if you can get away with.

She had plastic

Ashish Rajan: on as well. Right. Cause I think the least privilege would be pointless for that Cloud trail as well. I imagined so CloudTrail have definitely have that one as well.

Ian McKay: Yeah. So there’s, there’s a few things that you should have on [00:33:00] a butterfly and the AWS guns will give you that information as well.

Things like cloud trialing in your environment just apply it once in north Virginia, and have a multi-region. It included management events. , that’s the quote configuration that you really need. And if you can use an STP to protect that cloud trial and the destination, which is probably an S3 bucket, at all cost.

So you basically just deny everything from touching that, in that way, you need to log into over an account to manage it and do anything else to it. When you don’t don’t ever use an already account, unless you have to. Really account is for creating your account, making your user identity, and then getting the hell out of there, put MFA before you get out of there.

But get out of there immediately to not use your real account for anything else. Because that’s, that’s one of those things where a lot of things , and do a lot of bad practices in there. So make sure you try and avoid that.

Ashish Rajan: So just curious, why north virginia for Cloud Trail why not.

Ian McKay: So in a west north Virginia is a special sniff. I courageous where, when we talk about things like global services is technically homes [00:34:00] for most of the global services in north Virginia. And so things like CloudTrail and management events now, are exposed for the global services in north Virginia.

And that’s why we say to put that things there, you just still have your applications and things like that in the other region, that’s closest to you. So in our case, that’s a Sydney region, but in your case, that might be Melbourne region later this year. But for those management events and things like that, you’re going to see that north Virginia is a special snowflake that which you have to consider, and Things like cloud trail should probably be home there.

Things like you should consider maybe putting SSO there because of the various implications that that has as well.

Ashish Rajan: The reason I’m asking this question is also because we’ve got already information for the UK, Israel all over Europe as well. All those people may be listening to this and going wait.

So does that mean. Data sovereignty kind of, cause the cloud trail is pretty much ordered log of every identity that’s out there right. In, in AWS. Cause I mean that’s out of the window.

Ian McKay: So, so when people generally talk about data sovereignty, they’re only talking about the [00:35:00] data that is relevant for their customers.

So that’s your PII, that’s your customer data and things like that. This is general knowledge that a lot of AWS is distributed system. So things like , your customer data in S3 will most likely stay within that region and your databases will stay in that region and things like that. But although you should consider, your backup plan to have a similar home sister region, if you can help it.

Sydney was traditionally Singapore, but it might be Melbourne north or New Zealand in the future. But within the management events, that’s generally a global action. So things like DNS in route 53, that’s a global entity. If you’re accessing DNS from the UK, you’re going to hit one of the funding regions, DNS service, or the CloudFront props that are close to that.

Your location over there. So those management events will come in through those regions and you need to be, thinking about how that works from a global scale. And that’s why that kind of takes effect.

Ashish Rajan: And I’m so glad I have you talk about IAM as well , many of my go-to person [00:36:00] for it. So probably one last question where can one find out about IAM

cause I feel like just relying on AWS docs. Probably not. It’s not just in. That’s hence the reason you’ve kind of created open source tools and not have other people have kind of gone down the even Scott Piper and everyone. So where do you normally ask people to start to understand? I am, because there are companies where IAM are whole departments and I’m sure they would want to go super deep into it as well.

So what’s your recommendation for that?

Ian McKay: Yeah. So docs are definitely the sort of place to start, but there’s a lot of really good resources online, the reinvent and the reinforce talks from AWS as well are really good to dive deep into certain topics. IAM as one of them, but you can go deeper into the mission boundaries or SCPS or access analyzer and things like that.

When it’s, when you move outside of community resources out there, there’s some great talks from. Both conferences and just directly from education providers. So, people like Andrew Brown, putting out content all the time to give you an understanding about what it is, what are the things you should [00:37:00] be looking at?

Cloud security podcasts is a great example of sort of resources that you can learn from that. Look up, you user groups, so your meet ups, there’s physical. In-person. Eventually, meet ups that’ll talk sometimes about these topics and things like Reddit and the slack groups as well. There’s a cloud security forums, slack group.

If you look that up, out there, that’s, that’s really good and contains a lot of us, sort of a more experts talking about cloud and identity and the things that are impacting us on things like that. Okay, great. I’ll look that up as well.

Ashish Rajan: Awesome. And I think Tom made a really great comment. Progress over perfection is a great idea in one term I a hundred percent agree with that.

So, where , can people find you connect with you on IAM , and talk about AWS community, as well as the whole ambassador program as well, we get people.

Ian McKay: Yeah, I’m on Twitter at, at I doubled in double 0 3, 6. I’m on get hub as well under that same alias, LinkedIn on the same way, how he is come find me.

If you want to talk, shop for free to DM me we can talk about whatever you want and. Yeah, we can start some more arguments

Ashish Rajan: Thanks so much for coming in, man. And for [00:38:00] everyone else who’s tuning in appreciate you guys hanging out and we have one more episode for this month before we close off the IAM month, which is going to be next weekend, but I will see you then, and thanks so much for joining and I will see you the next episode.

Thanks again. Alright. Thanks everyone. Bye.

‍