Iam on ferkakta.dev

Stop copying AWS managed policies — deny what you don't want instead

Fri, 27 Feb 2026 00:00:00 +0000

I needed to give a developer full CloudWatch read access — metrics, alarms, dashboards, log groups — but deny access to three categories of log groups containing security-sensitive data: WorkSpaces OS event logs, VPC flow logs, and WAF request logs.

The reflex is to copy CloudWatchReadOnlyAccess into a custom policy and delete the parts you don’t want. I’ve seen this in every organization I’ve worked in. It produces a policy with 50+ actions that you now own. Every time AWS ships a new CloudWatch feature, your policy is stale. You won’t update it. It’ll rot.

The IAM policy controls access — the document controls how people feel about it

Fri, 27 Feb 2026 00:00:00 +0000

I tightened a teammate’s AWS permissions last night. Added an inline deny policy to block three categories of CloudWatch log groups — WorkSpaces OS logs, VPC flow logs, WAF request data. Five minutes of IAM work. Then I spent twenty minutes writing a document explaining every boundary, what’s accessible, what’s denied, what’s coming next, and what I haven’t designed yet.

The document mattered more than the policy.

The default is silence

Most companies handle access control the same way. Someone asks for access. An admin creates a policy. The requester gets a login link. Nobody explains what they can and can’t do, or why.

IAM trust policies silently accept wildcards in principals — and silently deny everything

Thu, 26 Feb 2026 10:00:00 -0600

I needed a cross-account IAM role in a management account that workloads in a separate devops account could assume to send email via SES. Two types of callers: one shared service with a stable role name, and N dynamically-created per-tenant roles following a naming convention like myapp-apiserver-*.

The shared service was straightforward — exact ARN in the trust policy principal. For the per-tenant roles, I wrote what looked correct:

"Principal": { "AWS": "arn:aws:iam::111111111111:role/myapp-apiserver-*" }

terraform apply succeeded. The role was created. Every assume-role call was denied.

IAM eventual consistency is 4 seconds — if your policy still doesn't work, you have a bug

Thu, 26 Feb 2026 09:00:00 -0600

I changed an IAM inline policy on a role — added an sts:AssumeRole statement so a pod could assume a cross-account SES role. Ran terraform apply. Checked the policy with get-role-policy. The old policy came back. No new statement.

I said “propagation delay” and moved on to other work.

Twenty minutes later I checked again. Same old policy. That’s not propagation.

What eventual consistency actually means

AWS IAM uses a distributed computing model. Changes to policies, roles, and credentials take time to replicate across endpoints. AWS documents this explicitly and recommends not including IAM changes in critical code paths.

The Over-Mighty Subject: why your site repos have too much power

Thu, 26 Feb 2026 00:00:00 +0000

Josh Marshall borrows a phrase from medieval history to describe a modern political problem: the Over-Mighty Subject. A feudal lord whose personal wealth, private army, and territorial control grew so large that he rivaled the crown itself. Not a rebel — still nominally a subject — but operating with enough independent power that the sovereign’s authority became theoretical.

I had three of them in my infrastructure. They were Terraform roots for static sites.