BYTE the Cloud

Kelly 0:00
Welcome to the deep dive. Today, we're unlocking the secrets to one of the most critical services in AWS identity and access management or IAM. Think of it as the ultimate bouncer and gatekeeper for your entire cloud kingdom. We're talking about the service that dictates who can do what, when and where across all your AWS resources, precisely and for

Chris 0:21
any cloud professional, whether you're just starting out or you're a seasoned architect, really getting IAM isn't just about passing an exam, it's about building fundamentally secure, resilient and compliant cloud architectures. So our mission today is to cut through the complexity, distil the core concepts, explore some advanced scenarios, and really arm you with the specific insights you'll need for your next challenge, be that a project or yellow certification exams.

Kelly 0:45
All right, let's unpack this then, at its heart, what exactly is AWS IAM, and why is it considered so foundational?

Chris 0:52
Well, it's fascinating because IAM is quite simply, the bedrock of security in AWS. It's the service providing that granular control over access to, well, everything in your account. Without it, it would just be a free for all. It ensures the confidentiality, the integrity of your data by controlling who can perform actions, preventing unauthorised access, protecting your valuable info, whether it's sitting in storage or flying across the network. It's not just a feature. It's really the security model itself. So

Kelly 1:22
it's not just about managing users, but truly managing permissions. Okay, what are the key building blocks we need to grasp first to make sense of this whole security architecture?

Chris 1:31
Exactly. Yeah, when we talk about IAM, we're primarily looking at four key components that sort of work together. And what are those? Okay, first up, we have IAM users. These are identities for individual people or applications, sometimes even services that need to interact directly with. AWS, think individual accounts. Then there are IAM groups. These are, well, just collections of users. The real power of groups comes in simplifying management. You apply a policy to the group and boom, all its members inherit those permissions, much more efficient than doing it user by user.

Kelly 2:05
That makes perfect sense for keeping things organised. But the real power I often find lies in something a bit more dynamic, right? I'm thinking of IAM

Chris 2:13
roles. Absolutely. Roles are where things get really interesting and powerful, unlike users who have their own long term credentials. Roles are created and then assumed by trusted entities. Now those entities could be IAM users, they could be other AWS services, even external identities. The key thing is that when a role is assumed, it provides temporary security credentials, and that is a game changer. It totally eliminates the need to distribute or embed static long term credentials anywhere those things are a major security risk if they get

Kelly 2:42
compromised, right? So no more hard coding passwords or access keys into application config files. Phew. Can you give us a concrete example of how that works in

Chris 2:51
practice? Yeah, classic example is an EC2 instance role. Imagine you have a virtual server, an easy to instance, and it needs to read data from an S3 bucket, maybe write logs to CloudWatch instead of, you know, manually putting security credentials directly on that server, which is a huge security No, no, really, you assign an IAM role to the EC2 instance, the instance then automatically assumes this role, gets temporary permissions and can perform actions on your behalf, like accessing that as three bucket. Similarly, an AWS Lambda function which runs your code in response to events, can assume a role to get just the permissions it needs to talk to other AWS services like a DynamoDB table to process data.

Kelly 3:27
That is such a huge win for security. Just removing those static credentials and tying into that idea of temporary credentials, this is where the AWS Security Token Service STS comes in, right?

Chris 3:38
Precisely. STS is kind of the unsung hero working behind the scenes. It's the actual service responsible for issuing those temporary, short lived security credentials that roles obtain. This allows for incredibly fine grained access control because, well, credentials aren't permanent. When STS gives out those tokens, it automatically expires access after a set time, drastically cutting down the window of opportunity for attackers. If a credential ever gets exposed, you'll see STS underpinning several crucial use cases, especially for like enterprise level security

Kelly 4:09
setups. Okay, so what are some of those key STS use cases beyond just EC2 instances talking to S3 Well,

Chris 4:15
think about cross account roles. This is fundamental for any multi account strategy, letting an entity in one AWS account securely and temporarily access resources in another account, very common. Then there's federated access. This connects your say on premises identity system, like Active Directory, to AWS users log in with their normal corporate credentials, and STS helps bridge that trust, granting them temporary AWS access and for mobile and web apps, FTS provides those temporary credentials to your app users, removing the risk of embedding long term secrets right into your application code. It's also invaluable for granting maybe third party vendors or contractors temporary time limited access to specific AWS resources with very defined limitations.

Kelly 4:59
That's a. Incredibly powerful. Okay, so we've got users, groups and roles for who can access things and STS handling the temporary access mechanism, but what actually dictates what those identities can and cannot do. That brings us to IAM policies. I assume

Chris 5:13
you've got it. IAM policies are the real core here. They're the actual documents written in JSON format that define permissions. They specify what actions are allowed or denied and on which specific resources. A crucial point to remember here and is a foundational AWS security principle, all permissions are implicitly denied by default. Nothing is allowed unless you explicitly say it is. And if you have multiple policies with conflicting statements, maybe an allow here and deny there. The most restrictive policy is always applied and explicit deny trumps everything

Kelly 5:47
that deny by default. Principle is huge. It really forces you to be deliberate.

Chris 5:51
It does this. Deny by default approach isn't just a rule, it's AWS core philosophy for security. It means you must explicitly grant every single piece of access needed. This makes accidental over privileging much harder, but it's also why troubleshooting IAM permissions can sometimes feel like detective work. You're almost always looking for a missing allow, not an explicit deny. It forces a proactive security mindset from the get go,

Kelly 6:14
right? You're building up permissions, not taking them away. Okay? Now that we've covered the core concepts, let's dive a bit deeper into the nuances of policies and maybe more complex scenarios that help manage permissions at scale. We talked about identity based policies attached to users, groups or roles. But there are other types, aren't there? Yes,

Chris 6:33
absolutely. There are other crucial policy types to know beyond identity based policies, which are your standard permission documents attached to an identity. We also have resource based policies now, unlike identity based policies, these are attached directly to a resource itself, like an S3 bucket policy or an SQS queue policy. They define who, which principal, maybe from another account can access that specific resource. It gives the resource owner direct control. Okay,

Kelly 6:59
resource policies live on the resource itself, and building on policies, there's another powerful concept for setting guardrails, especially in larger organisations or when you're delegating permissions, permissions boundaries. What's the deal with those?

Chris 7:11
Ah, permissions boundaries. These are really interesting. They don't actually grant permissions themselves. Instead, they define the maximum permissions that an identity based policy attached to a user or role can ever grant so like a ceiling, exactly think of it as a safety net or a permission ceiling, even if you accidentally attach a super powerful identity policy like administrator access to a user or role, if their permissions boundary is restrictive, they can only ever perform actions that are allowed by both the identity policy and the permissions boundary. It's a crucial tool for centralised governance, making sure no individual or team can accidentally or, you know, intentionally escalate privileges beyond a set organisational standard. It's like your ultimate insurance policy against mistakes or even insider threats, because it minimises the blast radius if something goes

Kelly 8:01
wrong. That sounds like a powerful tool for large orgs. And speaking of organisational scale, how do you manage permissions effectively when you have dozens, maybe hundreds, of AWS accounts? That's where service control policies or SCPs within AWS organisations come in. Right

Chris 8:16
spot on. This is where enterprise level governance really kicks in. AWS organisations lets you group many AWS accounts into, well, an organisation, you get a single, consolidated bill, centralised management, governance across all those accounts. SCPs are JSON policies that allow you to control the maximum permissions available in an account or an organisational unit. Oh, you which is a group of accounts, or even the entire organisation. By default, there's an SCP that allows everything, but you can get much more granular. You can effectively whitelist or blacklist entire services or specific actions at the OU or account level. This helps enforce compliance and security standards from the very top down. It's a top level guardrail.

Kelly 8:56
Okay, so SCPs define what can be done at the account level, like a boundary for the whole account, while permissions boundaries restrict what can be granted to a specific IAM user or role within that account, powerful combination. What about user authentication beyond just individual IAM users within a single account? That brings us back to federated access.

Chris 9:14
Right. Federated access is essential for scale. It involves setting up a trust relationship between AWS and an external identity provider or IDP that could be your corporate active directory using SAML 2.0 or maybe social providers like Google, Facebook, Apple, using OpenID Connect, the external IDP handles the actual authentication, proving who you are, and then AWS, using STS and roles, grants the user appropriate temporary IAM privileges. This approach really improves scalability for large user bases, because AWS IAM itself isn't managing 1000s of individual user accounts directly

Kelly 9:48
and often, when we talk about federated access, particularly for consumer facing applications, Cognito pops up, doesn't it? It kind of acts as an identity

Chris 9:55
broker. It's exactly Cognito is very commonly used in mobile and web apps to. Manage user identities and provide that federated access layer that has two main parts. You should know Cognito user pools, which are essentially your user directories. They handle user sign up, sign in, password resets, and can integrate with those social identity providers we mentioned. Then there are Cognito identity pools. These are used to actually obtain those temporary, limited privilege AWS credentials from STS for your users, allowing them to access other AWS services directly by assuming a specific IAM role. Cognito essentially acts as that identity broker between your chosen IDP, which could be user pool or Facebook, et cetera, and AWS STS. That's

Kelly 10:36
a lot of tools for managing access Now switching gears slightly when it comes to managing sensitive information within your applications, things like database credentials or API keys. Where should you store those securely? That's

Chris 10:47
a critical question, and the clear answer is, AWS, CCAs manager. It's purpose built for storing and crucially managing database credentials, API keys for third party services of tokens, SSha keys, you name it. What really sets it apart is its ability to handle frequent automatic rotation of these credentials, which is a vital security practice. Now. You might also hear about AWS Systems Manager, parameter store. It can store secrets and offers encryption, but Secrets Manager is specifically designed for those highly sensitive credentials that require frequent rotation and have complex management needs. It's built in rotation capabilities, integrations with services like RDS and more robust audit trails. We get the go to for true secret management. Parameter store is often better suited for more general configuration parameters, maybe some less sensitive secrets that don't need rotation. Okay,

Kelly 11:36
good distinction. So we've covered the what and how of IAM in quite some detail, what are the overarching best practices, the things you should always keep in mind, almost like a security checklist, when working with IAM?

Chris 11:48
Yeah, there are definitely a few non negotiables for a strong security posture, first, and maybe most importantly, lock away your root user access keys. Seriously, the root account has full unrestricted permissions. Only use it for tasks that absolutely require a root, like changing your support plan or closing the account for everything else. Use IAM. Second, create individual IAM users never, ever share credentials between people or applications. Third, once you have individual users, use IAM groups, assign permissions to groups, then put users in those groups, vastly simplifies managing permissions as teams change. Fourth, and this is paramount, the golden rule, Grant least privilege. Always provide only the minimum permissions necessary for users or services to perform their specific tasks. No more. Never grant that unless absolutely unavoidable and you understand the risk. Fifth, for your applications running on EC2 Lambda ECS, etc, use IAM roles do not embed access keys directly in your code or config files use instance profiles or task roles. It's much more secure and manageable. Sixth, regularly rotate credentials that do need to be long lived, like IAM user access keys if you must use them or secrets in Secrets Manager and seventh, enable multi factor authentication MFA, especially, especially for your root account and any privileged IAM users like administrators, it adds such a critical layer of security for very little

Kelly 13:07
effort. MFA is such a simple yet incredibly effective step. And there's a specific example of MFA that can literally save your bacon with data, right? MFA delete for S3

Chris 13:17
Absolutely. That's a great one. For an S3 bucket containing critical data. You can enable MFA Delete. This requires an additional authentication code from an MFA device to change the versioning state of a bucket or to permanently delete an object version remember time, actually a client almost accidentally deleted their entire production S3 bucket during a cleanup script that went wrong. Luckily, we had insisted on enabling MFA delete, that extra step requiring the MFA code gave them that crucial moment of pause, wait. Why is it asking for MFA? And it saved them from a potential disaster that would have absolutely crippled their operations for days, maybe longer. Just remember, though, it requires versioning to be enabled on the bucket first MFA delete protects object versions. So you need versions to exist.

Kelly 14:02
Wow, that's a fantastic real world example of how these best practices really pay off. And finally, what about keeping an eye on all this activity? You've set up users, roles, policies. How do you know what's happening?

Chris 14:12
Right? You absolutely must monitor activity use services like AWS, CloudTrail, CloudTrail logs nearly all API calls made in your account, providing an essential audit trail, who did what, when, from where it's crucial for security analysis and troubleshooting, and then to aggregate and make sense of all those logs and other security findings you have AWS Security Hub. It offers a centralised view, pulling information from various AWS security services like GuardDuty inspector Macy and even third party tools. It helps with automated compliance checks against standards like the CIS AWS foundations benchmark, and lets you set up custom alerts. It's really a key part of your detective controls, giving you that comprehensive overview of your security posture across potentially many accounts. And just a quick note for those preparing for certification exams, remember the exams aren't. Always about the nitty gritty configuration steps like clicking through the console. They're primarily about understanding what the technology is, how it works, and, crucially, why you would choose one service or configuration over another in a given scenario, most questions are multiple choice. You need solid understanding of core AWS services, basic security best practices, and especially IAM inside and out. Always, always think least privilege in every im scenario you encounter, focus on the why behind the services, not just the How to clicks.

Kelly 15:27
Okay, that's great advice to really cement our understanding. Now let's walk through how this plays out in some common scenarios, maybe even some of those tricky questions you might encounter on an exam or in real life. All right. Scenario 1e, c2, instance access to S3 this is a classic. You'll often see a problem where an application on an E, c2, instance needs to read, write to S3 a common wrong answer or mistake is suggesting storing AWS credentials directly on the instance in a file. What's the correct approach?

Chris 15:56
Yeah, that credential file is a huge anti pattern. The recommended most secure solution, as we have discussed, as always, create an IAM role with the necessary S3 permissions, least privilege, of course, and then assign this role to the EC2 instances. Instance profile. The instance can then automatically, seamlessly assume this role and get temporary credentials via STS, no hard coded keys, no storing long term credentials anywhere vulnerable. This is fundamental.

Kelly 16:18
Got it scenario, two granular policy permissions. Let's say you're looking at an IAM policy allowing dynamod actions on resource that

Chris 16:27
feels overly broad, right? Way too broad. If the scenario specifies access to a particular DynamoDB table, maybe the customer's table only, then your policy must reflect that granularity. Instead of resource play, it should specify the full Amazon resource name, the Arn of that specific table, like Arn, dot, aos, dot, dynabode, me.us dash east, 1.12345679012, dot table customers. This strictly aligns with the principle of least privilege. Exams love to test if you'll take the easy wild card route or apply proper

Kelly 16:57
granularity, right, always scope down the resource, Arn, if possible. Okay. Scenario three, protecting against accidental deletion in S3 a company wants to prevent accidental deletion of critical data. We touched on this, but what are the two key steps

Chris 17:09
again? Yep, two crucial steps working together. First, you absolutely must enable versioning on the S3 bucket. This keeps multiple variants of an object, so if you delete something, you're really just deleting the current version marker and the previous versions are still recoverable. Second enable MFA delete on that versioning enabled bucket. This adds that extra multi factor authentication requirement for actions like permanently deleting an object version or changing the buckets versioning state itself. You really need both for comprehensive protection,

Kelly 17:36
perfect scenario, four temporary access for web mobile apps. A mobile app needs temporary, fine grained access to AWS resources, say, uploading pictures to an S3 bucket, or querying a DynamoDB table, but you absolutely cannot store static credentials in the app. What's the recommended AWS approach? The

Chris 17:55
correct solution here is definitely leveraging AWS Security Token Service, STS via an IAM role, and very likely using Cognito identity pools as the broker. The mobile app authenticates the user first, maybe using a Cognito user pool or a social login like Google Sign In, then the app exchanges that authentication token for temporary AWS credentials from STS by assuming an IAM role specifically crafted with the limited permissions needed. Ek only put object to a specific S3 prefix keeps the app secure scales. Well,

Kelly 18:25
makes sense. Okay, here's maybe a trickier one scenario, five, explicit deny versus implicit deny. You have an IAM user who is a member of two groups. Group A has a policy explicitly allowing S3 dot object on bucket A, group B has a policy explicitly denying S3 dot object on the same bucket a, what access does the user actually have to get objects from bucket a? Ah, the

Chris 18:46
classic policy evaluation logic question. This tests a fundamental rule in AWS. I am an explicit deny always overrides any explicit Allow Always. So even though Group A allows access because Group B explicitly denies it for that same action on that same resource, the user's request will be denied. The explicit deny wins. It's the most powerful statement in IAM policies

Kelly 19:07
that is a crucial rule to remember. Explicit deny trumps all. Okay, one last scenario. Let's tie together those organisational guardrails we discussed scenario six, SCPs versus permissions, boundaries. An organisation uses AWS organisations, they want to ensure that no developer in their development ou can ever launch an EC2 instance type larger than, say, m5 dot large, even if an individual IAM policy accidentally grants that permission additionally within a specific production account, they want to set a maximum permission limit for all new IAM roles created via automation to prevent Potential privilege escalation if a role is compromised, which AWS IAM concept should they use for each requirement?

Chris 19:45
Okay, good scenario covering both levels. For the first requirement, restricting EC2 instance types across an entire ou, you'd absolutely use an AWS service control policy SCP applied to that development ou within AWS organisations, the SEP would contain a state. Explicitly denying the EC2 run instances action if the requested instance type is larger than m5, dot large. This acts as a top down guardrail for all accounts in the OU for the second requirement, setting a maximum permission limit for new I and M roles within a specific account. You would use permissions boundaries when those new roles are created, maybe by CICD, you attach a specific permissions boundary policy to them, this bounded policy defines the absolute maximum permissions the role can ever have, regardless of what identity based policies are later attached to it. So SCPs set the guardrails at the organisation account level and permissions boundaries refine those limits at the individual IMR role or user level.

Kelly 20:36
Excellent breakdown. What a deep dive IAM is truly, as you said, the backbone of security in the AWS cloud, it gives you incredibly precise control over who can do what. It's complex, for sure, but mastering it seems absolutely non

Chris 20:48
negotiable, absolutely mastering IAM really understanding those policy types evaluation logic and embracing best practices like least privilege and MFA. It's not just about ticking compliance boxes. It's fundamentally about building resilient, secure and future proof cloud architectures that can actually withstand real world threats and mistakes. It's really the difference between building a sand castle on the beach and building a secure fortress.

Kelly 21:14
So a final thought for everyone listening as you build your next cloud architecture or even review your existing ones, how will you ensure that least privilege isn't just a slogan you repeat, but a foundational pillar that's actively enforced, not just for individual users, but maybe using SCPs and permissions boundaries across your entire organisation? Keep exploring, keep learning, and we'll see you on the next deep dive.