tyates author setup & IAM policy simulator blog

[timkins666]

Please add a direct link to your post here:

https://timkins666.github.io/blog/2025/04/03/automated-iam-policy-simulator-testing.html

Have you (please tick each box to show completion):

• Added your blog post to a single category?
• Added a brief summary for your post? Summaries should be roughly two sentences in length and give potential readers a good idea of the contents of your post.
• Checked that the build passes?
• Checked your spelling (you can use npm install followed by npx mdspell "**/{FILE_NAME}.md" --en-gb -a -n -x -t if that's your thing)
• Ensured that your author profile contains a profile image, and a brief description of yourself? (make it more interesting than just your job title!)
• Optimised any images in your post? They should be less than 100KBytes as a general guide.

Posts are reviewed / approved by your Regional Tech Lead.

[mgriffin-scottlogic]

Fine to leave these as h3 headers if you prefer it stylistically, though we would normally start with h2.

[mgriffin-scottlogic]

Suggested change

In the majority of cases where I've used the policy simulator console UI, I've been troubleshooting a role's access (or denial of access) to S3 objects at specific paths, which requires evaluating the result using both the role's policies and the S3 bucket policy. Adding a set of context values, test actions and S3 object ARNs (Amazon Resource Names, specify a resource unambiguously across all of AWS) is fine for a one off, but it's not something you want to repeat often and isn't feasible for ongoing verification.

In the majority of cases where I've used the policy simulator console UI, I've been troubleshooting a role's access (or denial of access) to S3 objects at specific paths, which requires evaluating the result using both the role's policies and the S3 bucket policy. Adding a set of context values, test actions and S3 object ARNs (Amazon Resource Names, which specify a resource unambiguously across all of AWS) is fine for a one off, but it's not something you want to repeat often and isn't feasible for ongoing verification.

[mgriffin-scottlogic]

Suggested change

As a little up-front disclaimer: this solution requires resource policies to identify applicable principals using conditions in statements (e.g. checking the role matches the `aws:PrincipalArn` context key) rather than declaring explicit roles in the `Principals` block itself. The reason for this is that our dummy user ARN needs to match the principal(s) that the permissions apply to, so if you're using something like `AWS: *` or `AWS: <your-account-id>` then that will match the dummy user, and the nitty-gritty bits in conditions will evaluate against our test role specified in `aws:PrincipalArn`. It might well be possible to adapt policies to specify the dummy user as a principal before including in the API request, but I haven't tried.

As a little up-front disclaimer: this solution requires resource policies to identify applicable principals using conditions in statements (e.g. checking the role matches the `aws:PrincipalArn` context key), rather than declaring explicit roles in the `Principals` block itself. The reason for this is that our dummy user ARN needs to match the principal(s) that the permissions apply to, so if you're using something like `AWS: *` or `AWS: <your-account-id>` then that will match the dummy user, and the nitty-gritty bits in conditions will evaluate against our test role specified in `aws:PrincipalArn`. It might well be possible to adapt policies to specify the dummy user as a principal before including in the API request, but I haven't tried.

[mgriffin-scottlogic]

Suggested change

	- pull all inline (a policy directly tied to this role only) and managed (a policy entity that can be attached to multiple users or roles) policies for the role - these are the principal policies
	- Pull all Inline (a policy directly tied to this role only) and Managed (a policy entity that can be attached to multiple users or roles) policies for the role - these are the principal policies.

I think these should be capitalised to make it clear these are used as descriptions. I would also capitalise the first word of each bullet point and use full stops at the end.