Awsviz.dev simplifying AWS IAM policies
A new tool, awsviz.dev, aims to turn complex AWS IAM policies into simple visual graphs, helping developers understand permissions and spot security issues more easily. Commenters welcome the idea—especially the open-source, client-side design—but raise concerns about the product name, onboarding UX, and the broader reality that IAM remains difficult and time-consuming to use correctly. Many see value in better visualization and automated analysis, yet argue that AWS should provide clearer error messages, simpler abstractions for small teams, and improved ways to derive least-privilege policies from real-world usage.
Tool overview & reception
- Thread discusses a new tool, awsviz.dev, that visualizes AWS IAM policies as graphs to aid understanding and debugging.
- Several commenters find the idea useful, especially for teams that routinely produce incorrect or over‑permissive policies.
- Some ask how it differs from generic JSON visualizers; implication is that domain‑specific IAM analysis and “allowed actions” views are the value-add.
UX, features, and data handling
- Users initially find the UI confusing (where to paste JSON, what to upload); the author adds a JSON input and clarifies that zips of policy files are accepted.
- Feedback suggests surfacing “what the user is allowed to do” more prominently and making the policy details pane scrollable.
- Multiple commenters are wary of uploading sensitive IAM data; reassurance is given that processing is client‑side and the code is open source, but people want the GitHub link more visible.
- One commenter asks how security severity is rated and requests a documented list of checks and references to underlying guidance.
Product name concerns
- Several note the name visually and phonetically resembles “Auschwitz,” calling it a very bad choice.
- Suggestions include minor renames or hyphenation (e.g., “aws-viz”) to avoid the association.
IAM complexity and account design debates
- Long subthread on IAM being powerful but overly complex, especially for small teams and startups.
- Some argue IAM is conceptually simple (“who can do what on which resource”) and essential at AWS scale; others say its evolution (SCPs, resource policies, assumed roles, boundaries, conditions) makes real-world reasoning very hard.
- Debate on multi‑account strategies: one-account-per-env vs. more granular per-system or even per-component accounts, with discussion of VPC sharing, peering, Transit Gateway, and cost/complexity trade‑offs.
Developer pain, tools, and desired improvements
- Common complaints: hard-to-interpret permission errors, inconsistent condition key support, scattered documentation, nested API permission chains, poor IAM/UIs, and eventual consistency in policy updates.
- Many admit to resorting to overly broad/wildcard permissions or even root credentials to “get things working,” sometimes lingering in code for years.
- Suggested improvements: better simulators and recorders that infer needed permissions from actual API calls, “record mode” that logs minimal required access, clearer logs and error messages, easier “coarse-grained” starter roles, and simpler abstractions for small teams.
- Mention of other tools and data sets (e.g., IAM datasets, policy-checking tools, infrastructure-as-code choices) as complementary aids.