Security 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.

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.

Expression injection in GitHub Actions repository_dispatch — and the one-line fix

Fri, 20 Feb 2026 10:00:00 -0600

I was hardening a cross-repo deploy pipeline built on repository_dispatch when I found a textbook expression injection sitting in plain sight. The trigger workflow accepted a client_payload JSON object from the caller and dropped its fields straight into a run: block.

How repository_dispatch works

When you call the repository_dispatch API, you send a JSON body with an event_type and an optional client_payload — an arbitrary JSON object the caller defines. Your workflow reads it via github.event.client_payload.*.

Your CI/CD dispatch token can rewrite your infrastructure code

Fri, 20 Feb 2026 09:00:00 -0600

I built a cross-repo auto-deploy pipeline this week. Three app repos push Docker images to ECR, then dispatch a deploy event to the infra repo’s orchestrator workflow via repository_dispatch. Standard pattern.

The gotcha: fine-grained PATs need contents:write to call the repository_dispatch API. Not actions:write — contents:write. The permission that also lets you push code, create branches, and delete files.

My service token that should only be able to say “hey, deploy this” can also rewrite the deployment workflow it’s triggering. That’s not least privilege. That’s a door that’s three sizes too wide.

What building infrastructure for a startup actually looks like

Wed, 11 Feb 2026 09:00:00 -0600

I spent a day doing the unglamorous infrastructure work that keeps a startup alive. Here’s everything that happened.

Morning: security audit

Audited two EKS clusters for a K8s privilege escalation vulnerability. Found 9 service accounts with cluster-admin that didn’t need it. Deleted two dead deployments — ArgoCD and Velero, both mine, both abandoned months ago. The rest are kubeflow components we can’t touch until 1.36 ships the fix in April.

Your ACM certificate request is a beacon — scanners are watching Certificate Transparency logs

Mon, 09 Feb 2026 09:00:00 -0600

I accidentally exposed production secrets on a public endpoint. Here’s what happened and what I learned about Certificate Transparency.

The setup

We’re building a multi-tenant SaaS platform on EKS. During development, our Terraform module defaulted to ealen/echo-server for three microservices — a lightweight HTTP server that echoes back request info. Seemed harmless.

What I missed: echo-server echoes EVERYTHING. Every environment variable in the container, including ones injected from AWS SSM via External Secrets Operator. Database connection strings. Redis auth tokens. OAuth client secrets. Signing keys. A single unauthenticated GET / returns it all as JSON.