devopscodepro
Language
Productized services
Infrastructure AuditRisks, costs and quick wins — mapped in two weeks.Cloud Migration & IaCTerraform, CI/CD and a zero-downtime cutover.Monitoring-as-a-ServiceAlerting, on-call and incident response.Fractional DevOpsA senior engineer in your team, part-time.
Not sure where to start? The audit answers that.Request a quote →
server-assisted · every other tool runs in your browserAll 41 tools →
Infrastructure AuditCloud Migration & IaCMonitoring-as-a-ServiceFractional DevOps
ContactLog in
Request a quote
Theme
Language
Runs entirely in your browser — nothing leaves this page.

IAM / RBAC analyzer

Paste an AWS IAM policy, Kubernetes RBAC manifest or GCP binding and see the dangerous grants highlighted: wildcards, PassRole, secrets access, public principals.

Paste a policy above — the format is detected automatically, nothing is uploaded.
These tools show symptoms. A full infrastructure audit finds the causes — risks, cost leaks and single points of failure, mapped in two weeks.
Request a quote →

Reading policies the way an attacker does

Paste an AWS IAM policy, a Kubernetes Role/RoleBinding manifest or a GCP IAM binding list — the format is detected automatically — and the grants that actually cause incidents get highlighted: wildcard actions and resources, iam:PassRole on *, IAM self-escalation calls, secrets access, escalation verbs, cluster-admin bindings, allUsers members.

The rules encode the known privilege-escalation paths, not style preferences. A policy can be perfectly valid JSON and still hand out the account: Action s3:* plus Resource * reads as "S3 access" in review and as "delete every bucket" in an incident.

Everything is analyzed in your browser. Your policies describe your infrastructure's trust boundaries — they are exactly the kind of document that shouldn't be pasted into someone's backend.

Why is iam:PassRole such a big deal?

PassRole on * lets a principal attach any existing role to a service it controls — spin up an EC2 instance or Lambda with an admin role, and the escalation is complete. It is the single most common step in real AWS privilege-escalation chains, which is why it should always be scoped to specific role ARNs.

What's wrong with reading Secrets in Kubernetes?

Nothing — until you notice the scope. get on a named secret is a workload doing its job; list on all secrets in a namespace (or cluster) is every credential in one API call. RBAC has no partial-read: if the grant covers secrets broadly, it covers all of them.

The analyzer found nothing. Is the policy safe?

It has none of the known dangerous patterns, which is not the same as least-privilege. The rules catch wildcards and escalation paths; they cannot know that your workload needs only three of the ten actions listed. Treat a clean result as a floor, not a certificate.

Does it understand SCPs, permission boundaries or conditions?

Conditions are recognized to the point of softening a finding (a public principal with conditions is a review item, not an automatic fail), but the tool doesn't evaluate them, and organization-level controls are out of scope. It reads one document at a time — the way most reviews actually happen.

Related tools: K8s manifest validator, Secret scanner and Kubernetes CVEs.