Noam Dahan

But wait! There is a perpetual!

I love that @anishgiri.bsky.social is clearly trolling (a certain world champion's love of) CAPS scores and Arturus is trying to turn it back into a conversation for normies

But wait! Ra5!!!

Thank you so much, I've registered on the waiting list for the Tata Steel 3-round, hopefully spots open up :)

Calling #ChessPunks in the Netherlands.
I'm interested in coming to my first ever OTB tournament. Any beginner-friendly recommendations?

1. No longer secretly
2. Odds reduced by me posting this

I am secretly hoping that no one starts a cloudsec feed until Saturday so that I get to do it

Really nice (are we writing answers in comments or no, what's the verdict #chesspunks?)

VS Code screenshot: { "Version": "2012-10-17", "Statement": [ { "Sid": "EnforceOrgIdentities", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": [ "arn:aws:s3:::AwesomeCats-af4v81b2", "arn:aws:s3:::AwesomeCats-af4v81b2/*" ], "Condition": { "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "<my-org-id>", "aws:PrincipalAccount": [ "<load-balancing-account-id>", "<fin-space-account-id>", "<third-party-account-a>", "<third-party-account-b>" ], "aws:ResourceTag/dp:exclude:identity": "true" }, "BoolIfExists": { "aws:PrincipalIsAWSService": "false" } } } ] }

RCPs apply to every request directed at a resource in the account. So we can implement the policy we wanted.

Not only that, we can set trust boundaries for IAM roles (e.g. only directly exempted accounts can AssumeRole into our org's identities). More here:
github.com/aws-samples/...

/fin

So identities coming from outside don't "see" an authorizer which is aware of the SCPs.
It follows, that SCPs can only be used to limit identities coming from within the org itself (and our cool kittens cannot be defended by them).

However- fear not - RCPs are here to save the day! 🦸‍♀️

YouTube video by AWS Events AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive (IAM301)

You can't because SCPs only affect principals in the organization itself, the reason has to do with the internal implementation of IAM, more about that: www.youtube.com/watch?v=YMj3...
Simplifying slightly, a request is authorized by the principal's account, and by the resource, so...

a picture of a cat with the words cool undercover cats on it Alt: a picture of a cat putting on sunglasses with the words cool undercover cats on it

So now, you might be thinking to yourself: I have an awesome idea for an SCP - I would like for only users from my organization to be able to access my bucket "AwesomeCats-af4v81b2" (Group #3 - this is where you can start paying attention :)). Well, unfortunately, you can't do that with an SCP. Why?

YouTube video by fwd:cloudsec A Year of NO building organizational IAM guardrail policies that work - Noam Dahan

For example: say I only want identities to be able to create resources in eu-north-1, I can use an SCP. It's an IAM policy that applies to every principal in the org, but can only limit permissions, never grant them.

A talk I gave about SCP strategy at fwd:cloudsec: www.youtube.com/watch?v=oomo...

Group 1, you got a high five :)
Group 2, Let's learn about RCPs! Group 3, we're going to get to that soon.
Before we understand RCPs, we have to understand SCPs (Service Control Policies) first. SCPs are the guardrails of IAM policies, they set up ground rule for what everyone can and can't do.

A complex flowchart diagram illustrating AWS Permission Evaluation with Resource Control Policies (RCPs). The chart is divided into several sections, each representing different stages of the permission evaluation process. The flowchart begins with "Deny evaluation" at the top, leading to a series of decision points represented by diamond shapes. These decision points evaluate various conditions, such as the presence of explicit Deny policies, organization resource control policies (RCP), and service control policies (SCP). The chart then branches into sections for "Resource-based policies" and "Identity-based policies". Each section contains multiple decision points and paths, leading to potential outcomes of "Allow" or "Deny (implicit deny)". The Resource-based policies section includes checks for session, role, and account permissions of the calling principal. The Identity-based policies section evaluates identity-based policies and permissions boundaries. At the bottom of the chart, there's a section for "Session policies" which includes checks for federated users and session policies.

RCPs (Resource Control Policies) launched in AWS, yay!
I imagine the reactions are generally divided into three:
1. This is awesome! We've been waiting for this for a long time! (yes you're very itk see you at fwd:cloudsec)
2. Cool! Love it! What are they?
3. Didn't SCPs already solve that? 🤔
🧵