Version策略语言版本，永远写 "2012-10-17"。它不是你随便挑的日期，是开启策略变量和现代语法的开关。
⚠ 坑: 不写 Version 会回退到老的 "2008-10-17"，会悄悄禁用 ${aws:username} 这类策略变量。
例子
"Version": "2012-10-17"
搜索 IAM 策略字段、ARN、条件、托管策略、信任策略,并在浏览器本地检查 policy JSON。
- 本地处理
- 分类 开发运维
- 适合 格式化、校验、压缩或检查和代码相关的文本。
Policy JSON 检查器
粘贴 policy JSON 后,会在本地检查 IAM 风险信号。
Statement
0
通配符
0/0
Allow
0
Deny
0
发现
-
还没有粘贴 IAM policy JSON。粘贴后会在本地检查 Statement、通配符、PassRole 和 S3 ARN。
可搜索 IAM 速查
87 条
Statement装一条或多条权限声明的数组（也可单个对象）。其它字段都在它里面。
例子
"Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "*" } ]Effect声明的判定，只能是 "Allow" 或 "Deny"。Deny 永远压过任何命中同一请求的 Allow。
例子
"Effect": "Allow"
"Effect": "Deny"
Action声明覆盖的 API 操作列表，格式 service:Operation。支持通配符。
⚠ 坑: Action 匹配不区分大小写，但还是按文档写法（s3:GetObject），策略才方便 grep。
例子
"Action": "s3:GetObject"
"Action": ["s3:GetObject", "s3:PutObject"]
"Action": "s3:Get*"
NotAction匹配除列出之外的所有动作。很强也很危险——配 Effect Allow 等于放开其余全部。
⚠ 坑: 经典翻车写法：Effect Allow + NotAction iam:* + Resource "*"，看着收紧其实接近管理员。
例子
"Effect": "Deny", "NotAction": "s3:*", "Resource": "*"
Resource声明作用的资源 ARN。身份策略里必填；"*" 表示该动作的所有资源。
例子
"Resource": "arn:aws:s3:::my-bucket/*"
"Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"]
NotResource匹配除列出 ARN 之外的所有资源。和 NotAction 一样要小心爆炸半径。
例子
"Effect": "Deny", "Action": "s3:DeleteObject", "NotResource": "arn:aws:s3:::archive/*"
Principal声明针对的主体。只能用在资源策略和信任策略里，身份策略里写了无效。
⚠ 坑: 把 Principal 写进挂在 user/role 上的策略是静默无效，IAM 直接忽略。要用资源策略。
例子
"Principal": { "AWS": "arn:aws:iam::123456789012:root" }"Principal": { "Service": "lambda.amazonaws.com" }"Principal": "*"
Condition可选的条件块，键/操作符/值的测试全部通过，声明才生效。
例子
"Condition": { "StringEquals": { "aws:PrincipalTag/team": "data" } }Sid可选的声明标识（标签）。纯粹为了你自己读得懂、做 diff 时好定位某条声明。
⚠ 坑: Sid 在一个策略内要唯一。在资源策略里它还是 API 调用引用某条声明的方式。
例子
"Sid": "AllowReadOnlyBucketAccess"
Action wildcards动作里用 * 和 ?：s3:*（所有 S3）、s3:Get*（所有读）、ec2:Describe*（所有 describe）。上线前先收范围。
例子
"Action": "s3:*"
"Action": "ec2:Describe*"
"Action": "*"
Resource ARN wildcardsARN 里也能用通配符：arn:aws:s3:::logs-*/* 命中所有 logs- 前缀桶里的所有对象。
例子
"Resource": "arn:aws:s3:::logs-*/*"
"Resource": "arn:aws:dynamodb:*:123456789012:table/app-*"
ARN general formatarn:partition:service:region:account-id:resource。全球服务（IAM、S3）region 留空；account-id 是你的 12 位数字。
⚠ 坑: partition 商业区是 aws、中国区是 aws-cn、GovCloud 是 aws-us-gov。把 us-east-1 的 ARN 抄到中国区会静默失败。
例子
arn:aws:service:region:account-id:resource-type/resource-id
IAM user ARN标识一个 IAM 用户。region 为空因为 IAM 是全球的；路径（这里是 /）是 ARN 的一部分。
例子
arn:aws:iam::123456789012:user/lilei
arn:aws:iam::123456789012:user/eng/backend/lilei
IAM role ARN标识一个 IAM 角色——信任策略或 assume-role 调用里引用的就是它。
例子
arn:aws:iam::123456789012:role/MyAppRole
arn:aws:iam::123456789012:role/aws-service-role/...
Assumed-role session ARNassume-role 之后你的身份是 sts assumed-role 的 ARN，不是 role 的 ARN——格式不同，写 Condition 时常踩坑。
⚠ 坑: 在 Condition 里匹配一个会话要用 ArnLike + arn:aws:sts::账号:assumed-role/角色名/*，不能用 iam role 的 ARN。
例子
arn:aws:sts::123456789012:assumed-role/MyAppRole/session-name
S3 bucket vs object ARN桶和桶里的对象是两个不同 ARN。桶级操作（ListBucket）用桶 ARN；对象操作用带 /* 的 ARN。
⚠ 坑: S3 策略第一大 bug：给 arn:aws:s3:::bucket（没有 /*）授 s3:GetObject，什么都匹配不到。
例子
arn:aws:s3:::my-bucket
arn:aws:s3:::my-bucket/*
arn:aws:s3:::my-bucket/logs/2026/*
Lambda function ARN标识一个 Lambda 函数；后缀 :版本 或 :别名 可钉住特定部署目标。
例子
arn:aws:lambda:us-east-1:123456789012:function:my-fn
arn:aws:lambda:us-east-1:123456789012:function:my-fn:prod
Account root ARNarn:aws:iam::账号:root 表示"整个账号"。信任策略里用它把信任委托给账号，让账号里的 IAM 管理员去授权。
⚠ 坑: Principal 里的 root 不是指 root 用户，而是"该账号里任何同时被 IAM 策略授权的主体"。
例子
"Principal": { "AWS": "arn:aws:iam::123456789012:root" }Service principalAWS 服务通过 ec2.amazonaws.com 这类服务主体行动——信任策略里用它让服务能 assume 角色。
例子
"Principal": { "Service": "ec2.amazonaws.com" }"Principal": { "Service": "lambda.amazonaws.com" }Wildcard / partial ARN matching用 ArnLike 或通配符匹配一族 ARN，例如某前缀下的所有函数、或某账号里的所有角色。
例子
arn:aws:lambda:*:123456789012:function:billing-*
arn:aws:iam::123456789012:role/ci-*
StringEquals / StringNotEquals对条件键做精确、区分大小写的字符串相等（或取反）匹配。tag 和取值校验最常用的操作符。
例子
"StringEquals": { "aws:PrincipalTag/team": "data" }"StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }StringLike / StringNotLike允许 * 和 ? 通配符的字符串匹配——值里含通配符时用它，不要用 StringEquals。
⚠ 坑: StringEquals 不展开通配符。"StringEquals: prefix*" 只匹配字面量 "prefix*"，基本一定失败。
例子
"StringLike": { "s3:prefix": "home/${aws:username}/*" }ArnLike / ArnEquals把条件键和 ARN 模式比较。ArnLike 允许通配符；aws:SourceArn 校验优先用它。
例子
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::my-bucket" }"ArnLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/ci-*" }Bool真/假测试。经典用法是强制 MFA、或强制请求走 TLS。
例子
"Bool": { "aws:MultiFactorAuthPresent": "true" }"Bool": { "aws:SecureTransport": "false" }IpAddress / NotIpAddress用 aws:SourceIp 键按源 CIDR 限制。只对不走 VPC endpoint 的请求有意义。
⚠ 坑: aws:SourceIp 是公网 IP。VPC 内经网关/接口端点发出的请求没有公网 IP，这个条件会把它拒掉。
例子
"IpAddress": { "aws:SourceIp": ["203.0.113.0/24", "198.51.100.42/32"] }DateGreaterThan / DateLessThan用 ISO-8601 UTC 时间戳配 aws:CurrentTime 给声明加时间窗——临时外包访问很好用。
例子
"DateLessThan": { "aws:CurrentTime": "2026-12-31T23:59:59Z" }NumericEquals / NumericLessThan数值比较，比如限制 S3 分段上传大小、或 STS 会话时长上限。
例子
"NumericLessThanEquals": { "s3:max-keys": "100" }Null测试某个键在请求里是否存在（false=存在，true=不存在）。用来强制必须带上某个 tag。
例子
"Null": { "aws:RequestTag/project": "false" }aws:PrincipalTag / aws:ResourceTag基于属性的访问控制（ABAC）：调用方 tag 和资源 tag 匹配才放行——不用为每个资源写策略也能扩展。
例子
"StringEquals": { "aws:ResourceTag/team": "${aws:PrincipalTag/team}" }aws:RequestTag / aws:TagKeys控制打 tag 本身：限制创建时能设哪些 tag 键、允许哪些值。
例子
"StringEquals": { "aws:RequestTag/env": ["dev", "staging", "prod"] }"ForAllValues:StringEquals": { "aws:TagKeys": ["env", "owner"] }aws:PrincipalOrgID把资源策略限制在你 AWS Organization 内的主体——比一个个枚举账号 ID 安全得多。
例子
"StringEquals": { "aws:PrincipalOrgID": "o-abc123xyz" }ForAllValues / ForAnyValue多值键的集合操作符。ForAllValues：请求里每个值都在你的列表内。ForAnyValue：至少有一个在。
⚠ 坑: ForAllValues 在键缺失时也算通过——如果必须存在，要再配一个 Null 检查。
例子
"ForAllValues:StringEquals": { "dynamodb:Attributes": ["id", "name"] }IfExists operator suffix加 IfExists 后缀，条件只在键存在于请求时生效，不存在就跳过。
例子
"Bool": { "aws:MultiFactorAuthPresentIfExists": "true" }"StringEqualsIfExists": { "ec2:InstanceType": "t3.micro" }aws sts get-caller-identity打印当前凭证的账号、ARN、user ID。IAM 版 whoami——做任何危险操作前先跑一遍。
例子
aws sts get-caller-identity
aws sts get-caller-identity --query Arn --output text
aws iam get-user返回当前 IAM 用户（或指定用户）的详情：ARN、user ID、路径、创建时间。
⚠ 坑: 如果你是以角色（role）而非用户身份登录会失败——assumed-role 会话没有 IAM user。改用 get-caller-identity。
例子
aws iam get-user
aws iam get-user --user-name lilei
aws iam list-users列出账号下所有 IAM 用户，含 ARN 和创建时间。
例子
aws iam list-users
aws iam list-users --query "Users[].UserName" --output text
aws iam create-role建一个带信任策略的角色（信任策略 JSON 规定谁能 assume 它）。信任策略必填。
⚠ 坑: trust.json 里 principal ARN 写错或漏了条件，是"assume 角色时 AccessDenied"最常见的根因。
例子
aws iam create-role --role-name MyAppRole --assume-role-policy-document file://trust.json
aws iam attach-role-policy给角色挂一个托管策略（AWS 自带或自建）。托管策略可复用、有版本。
例子
aws iam attach-role-policy --role-name MyAppRole --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
aws iam list-attached-role-policies --role-name MyAppRole
aws iam put-role-policy把一个内联策略直接嵌到角色上。内联策略和角色生命周期 1:1——角色删了它也没了。
⚠ 坑: 内联策略不出现在 list-attached-role-policies 里，要用 list-role-policies 才能找到。
例子
aws iam put-role-policy --role-name MyAppRole --policy-name s3-inline --policy-document file://inline.json
aws iam create-policy从 JSON 文档建一个可复用的客户托管策略，同一套权限能挂到多个主体。
⚠ 坑: 每个托管策略最多 5 个版本。超过后 create-policy-version 会失败——删个旧的或 --set-as-default。
例子
aws iam create-policy --policy-name S3ReadMyBucket --policy-document file://policy.json
aws iam simulate-principal-policy模拟某 user/role 对某资源能否执行某操作，不真跑。IAM 调试神器。
例子
aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123456789012:role/MyAppRole --action-names s3:GetObject --resource-arns arn:aws:s3:::my-bucket/key
aws iam list-attached-role-policies列某角色挂的托管策略。配合 list-role-policies 看内联策略。
例子
aws iam list-attached-role-policies --role-name MyAppRole
aws iam list-role-policies --role-name MyAppRole
aws iam create-access-key为 IAM 用户生成一把新的长效 access key（AKID + secret）。secret 只显示一次，当下不存就没了。
⚠ 坑: 能用 SSO 或 assume-role 就别用长效 key。非用不可就每 90 天轮换、旧的立刻删。
例子
aws iam create-access-key --user-name lilei
aws iam delete-access-key --user-name lilei --access-key-id AKIA...
aws iam list-access-keys列某用户的 access key（ID、状态、创建时间）——只有元数据，没有 secret。
⚠ 坑: 一个用户最多两把 key。这个上限就是为了轮换：建新、部署、删旧。
例子
aws iam list-access-keys --user-name lilei
aws iam update-access-key把某 access key 设为 Active/Inactive 而不删除——轮换或排查泄漏时安全的第一步。
例子
aws iam update-access-key --user-name lilei --access-key-id AKIA... --status Inactive
aws iam get-access-key-last-used查某 key 最后一次使用的时间、region、服务。删之前判断"这把 key 还活着吗"。
例子
aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE
aws iam generate-credential-report生成（再 get-credential-report）一份 CSV，列出每个用户的 key 年龄、MFA 状态、最后使用情况。审计利器。
⚠ 坑: 生成是异步的：先 generate、等 COMPLETE、再 get 读 base64 的 CSV。报告缓存 4 小时。
例子
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 --decode
aws iam get-account-authorization-details一次性导出整个 IAM 模型：所有用户、组、角色、策略、绑定关系，供离线审计。
⚠ 坑: 真实账号上输出巨大。导到文件用 jq 分析，别在终端里翻。
例子
aws iam get-account-authorization-details > iam-dump.json
aws iam get-account-authorization-details --filter Role
aws iam put-role-permissions-boundary给角色挂权限边界——一个上限，无论挂了什么策略，有效权限都不会超过它。
例子
aws iam put-role-permissions-boundary --role-name DevRole --permissions-boundary arn:aws:iam::aws:policy/PowerUserAccess
aws iam tag-role / tag-user给角色或用户打 tag——ABAC 和成本/归属追踪的基础。
例子
aws iam tag-role --role-name MyAppRole --tags Key=team,Value=data
aws iam tag-user --user-name lilei --tags Key=owner,Value=lilei
aws iam list-roles列账号下所有角色；用 --path-prefix 过掉嘈杂的 service-linked 角色。
例子
aws iam list-roles --query "Roles[].RoleName" --output text
aws iam list-roles --path-prefix /aws-service-role/
aws iam get-policy-version读托管策略的实际 JSON 文档。要先 get-policy 拿到 DefaultVersionId。
例子
aws iam get-policy --policy-arn arn:aws:iam::123:policy/S3ReadMyBucket
aws iam get-policy-version --policy-arn arn:aws:iam::123:policy/S3ReadMyBucket --version-id v3
AdministratorAccess对所有服务、所有动作的完全访问（Allow "*" on "*"）。整个账号的钥匙，几乎不要给任何人。
⚠ 坑: 即便管理员，也应 MFA 后 assume 一个管理员角色，而不是把 AdministratorAccess 长期挂在日常账号上。
例子
arn:aws:iam::aws:policy/AdministratorAccess
PowerUserAccess除 IAM 和 Organizations 外的完全访问。给"不该管用户/角色"的开发者的常见授权。
例子
arn:aws:iam::aws:policy/PowerUserAccess
ReadOnlyAccess几乎所有服务的读/列/describe。审计员和看板的好默认值——但它能读 secret 和对象数据。
⚠ 坑: ReadOnlyAccess 含 s3:GetObject 和 secretsmanager:GetSecretValue。只看元数据请用 ViewOnlyAccess。
例子
arn:aws:iam::aws:policy/ReadOnlyAccess
ViewOnlyAccess只列举和 describe 资源元数据——不含 GetObject、不读 secret。做大范围可见性比 ReadOnlyAccess 安全。
例子
arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
SecurityAudit跨服务的配置元数据只读访问——审计员和 Prowler/ScoutSuite 这类工具期望的策略。
例子
arn:aws:iam::aws:policy/SecurityAudit
IAMFullAccess / IAMReadOnlyAccess管理（或只读）IAM 用户、角色、策略。IAMFullAccess 实际等于可提权——按管理员对待。
例子
arn:aws:iam::aws:policy/IAMFullAccess
arn:aws:iam::aws:policy/IAMReadOnlyAccess
AmazonS3ReadOnlyAccess / AmazonS3FullAccess按服务收口的 S3 访问。FullAccess 很宽（所有桶）；优先自建策略钉死到具体桶 ARN。
例子
arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
arn:aws:iam::aws:policy/AmazonS3FullAccess
AmazonEC2FullAccess完整的 EC2，外加运行实例真正需要的 VPC、ELB、CloudWatch、Auto Scaling 等相关动作。
例子
arn:aws:iam::aws:policy/AmazonEC2FullAccess
AWSLambda_FullAccess管理 Lambda 函数，外加配套的 CloudWatch Logs、S3、事件源动作。
例子
arn:aws:iam::aws:policy/AWSLambda_FullAccess
Billing / job-function policiesAWS 在 arn:aws:iam::aws:policy/job-function/ 下提供按岗位对齐的托管策略——Billing、NetworkAdministrator、DatabaseAdministrator 等。
例子
arn:aws:iam::aws:policy/job-function/Billing
arn:aws:iam::aws:policy/job-function/NetworkAdministrator
Trust policy basics角色的信任策略是一份资源策略，Action 为 sts:AssumeRole，Principal 写明谁能 assume。
例子
{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:root" }, "Action": "sts:AssumeRole" }EC2 service trust通过信任 ec2.amazonaws.com，让 EC2 实例经实例配置文件 assume 该角色。
例子
{ "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" }Lambda service trust每个 Lambda 都需要的执行角色——信任 lambda.amazonaws.com，服务才能跑你的函数。
例子
{ "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" }Cross-account trust信任另一个账号的 root（或具体角色），让对方的主体能 assume 这个角色——跨账号访问的标准做法。
⚠ 坑: 两边都要：这边的信任策略 + 调用方那边的 sts:AssumeRole 授权。
例子
{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::999988887777:role/CiDeployer" }, "Action": "sts:AssumeRole" }ExternalId (confused deputy fix)给第三方（SaaS）跨账号角色加 sts:ExternalId 条件，防止厂商被诱导去访问错误客户的资源（confused deputy）。
例子
"Condition": { "StringEquals": { "sts:ExternalId": "unique-customer-token-abc123" } }OIDC web identity (GitHub Actions)不用长效 key 联邦 CI：信任一个 OIDC 提供方，用 AssumeRoleWithWebIdentity，并用 token 的 sub claim 按仓库/分支收口。
例子
"Condition": { "StringLike": { "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main" } }Require MFA to assume在信任策略里加 aws:MultiFactorAuthPresent 的 Bool 条件，角色只能被通过 MFA 的会话 assume。
例子
"Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }aws sts assume-role从 CLI 换取角色的临时凭证。返回 AKID、secret，还有 session token——三个都要 export。
⚠ 坑: 忘了 AWS_SESSION_TOKEN 是 assume-role 第一大失败原因。默认会话 1 小时；角色链最长 1 小时，--duration-seconds 设再大也无效。
例子
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/MyAppRole --role-session-name lilei
Default deny每个请求一开始都是隐式拒绝。要放行，必须在适用策略里某处有明确的 Allow。
例子
No matching Allow → implicit deny → AccessDenied
Explicit deny always wins任何适用策略里只要有一条明确 Deny，就压过所有 Allow。护栏就是靠这个生效的。
例子
Allow s3:* + Deny s3:DeleteObject → DeleteObject denied, rest allowed
Service Control Policies (SCP)组织级护栏。SCP 只能"收紧"，从不"授予"。SCP 不允许的，任何 IAM 策略都救不回来。
⚠ 坑: SCP 不作用于管理账号，也不作用于 service-linked 角色——"我的 SCP 怎么没生效"常因为这个。
例子
SCP denies region eu-west-1 → every account in the OU is blocked there
Permissions boundary设在 user/role 上的上限托管策略。有效权限是身份策略和边界的交集。
例子
Identity allows s3:* + ec2:*; boundary allows s3:* → only s3:* is effective
Identity vs resource policy union在同一账号内，身份策略或资源策略任一允许（且无 Deny）即可放行。任一侧都能授权。
例子
No identity Allow, but bucket policy allows the user → access granted
Cross-account needs both sides跨账号时，目标账号的资源策略（或信任）和调用方账号的 IAM 策略都必须允许，缺一不可。
⚠ 坑: 这个和同账号"并集"不同的非对称性，是跨账号 AccessDenied 最常见原因。
例子
Bucket policy allows acct B, but B’s IAM has no Allow → denied
iam:PassRole is the silent escalation用某角色启动 EC2/Lambda/ECS 任务需要对该角色有 iam:PassRole。把 PassRole 授到 "*"，用户就能把管理员角色挂到自己控制的算力上——彻底接管。
⚠ 坑: PassRole 一定钉到具体角色 ARN，并加 iam:PassedToService 条件。
例子
"Action": "iam:PassRole", "Resource": "arn:aws:iam::123:role/app-task-role", "Condition": { "StringEquals": { "iam:PassedToService": "ecs-tasks.amazonaws.com" } }Action:* + Resource:* is admin in disguiseAllow + Action "*" + Resource "*" 不管起什么名字都等于 AdministratorAccess。通配符把爆炸半径藏起来了。
例子
"Effect": "Allow", "Action": "*", "Resource": "*"
Inline vs managed policies托管策略可复用、有版本，用 list-attached-* 能看到。内联策略和主体 1:1，不出现在那里，容易被忽略。
⚠ 坑: 找不到的"权限缺失"常藏在内联策略里。查 list-role-policies / list-user-policies。
例子
aws iam list-role-policies --role-name MyAppRole
Policy size limits托管策略文档 ≤ 6144 字符；内联策略按 user/role/group 类型不同 ≤ 2048/10240 字符。空白也算。
⚠ 坑: 撞上限就拆成多个托管策略（每个主体最多挂 10 个）或压掉空白。
例子
Managed policy max: 6144 characters
IAM changes are eventually consistent新建 key、角色或改策略，全局传播可能要几秒。"建完马上用"的脚本可能短暂 403。
⚠ 坑: create-role 之后、assume-role 之前加退避重试，别假设改动即时生效。
例子
create-role → (wait/retry) → assume-role
Access key leaked to gitAKID 一旦 commit，几分钟内就被扫描机器人抓走，在各 region 起挖矿。先删 key，光重写 git 历史没用。
⚠ 坑: 立刻 iam delete-access-key，查近 24h 的 CloudTrail，再把该账号所有 secret 轮换一遍。
例子
aws iam update-access-key --access-key-id AKIA... --status Inactive --user-name lilei
aws iam delete-access-key --access-key-id AKIA... --user-name lilei
NotAction with Allow over-grantsAllow + NotAction 会放开你"没列出"的一切。本想"只拦一件事"，结果把其余全开了。
⚠ 坑: 要拦特定动作用明确的 Deny + Action，绝不要 Allow + NotAction。
例子
BAD: "Effect": "Allow", "NotAction": "s3:DeleteObject", "Resource": "*"
StringEquals does not expand wildcards条件值里含 * 或 ? 必须用 StringLike。StringEquals 把它们当字面字符，条件会静默永不命中。
例子
WRONG: "StringEquals": { "s3:prefix": "home/*" } → RIGHT: "StringLike"Role session vs role ARN in conditionsassumed 角色的 aws:userid 和调用方 ARN 与 role ARN 不同。匹配会话用 ArnLike + assumed-role 的 ARN，不是 iam role 的 ARN。
例子
"ArnLike": { "aws:PrincipalArn": "arn:aws:sts::123:assumed-role/MyAppRole/*" }Last accessed data, not guesswork用 IAM Access Analyzer 的"last accessed" / generate-service-last-accessed-details，按真实用量收紧策略，而不是靠猜。
例子
aws iam generate-service-last-accessed-details --arn arn:aws:iam::123:role/MyAppRole
这个工具能做什么
面向云工程师、SRE 和开发者的浏览器本地 AWS IAM 速查工具,适合日常 写策略、排 AccessDenied、审权限时快速查找。可以搜索 policy JSON 字段、 ARN 形状、条件操作符、IAM CLI 命令、AWS 托管策略 ARN、信任策略写法、 权限评估顺序,以及 iam:PassRole 提权、Allow 搭 NotAction、S3 桶和对象 ARN 写错、assumed-role 会话 ARN 匹配、AK SK 泄漏、IAM 最终一致性等 高频坑。把 IAM policy JSON 粘进本地检查器,会统计 Statement、Allow / Deny、通配 Action、通配 Resource、PassRole 暴露、S3 对象 ARN 错误、 Principal 用法和 malformed JSON。内容不上传,长策略文本也不会写进 URL。
工具细节
- 输入
- 文本
- 页面会根据工具类型展示文本框、数值控件、文件选择或结构化输入。
- 输出
- 即时结果 + 复制
- 结果区优先给出可操作结果，支持项会显示复制、下载或可视化预览。
- 隐私
- 浏览器本地处理
- 主工具逻辑未发现外部 API 调用，输入通常留在当前标签页内处理。
- 保存 / 分享
- 可分享链接状态
- 关键设置会进入 URL，复制链接后别人能复现同一组参数。
- 性能预算
- 首屏 JS ≤ 32 KB
- 没有声明 WASM 依赖，适合快速打开和移动端使用。
- 适用场景
- 开发运维 · 程序员
- 分类和职业标签用于推荐相关工具、组织内链，并帮助用户快速判断是否适合当前任务。
怎么用
-
1. 输入
把内容粘贴或拖入工具面板。
-
2. 处理
点击按钮,在浏览器内本地处理,文件不上传。
-
3. 复制 / 下载
一键复制结果或下载到本地。
AWS IAM 速查表 适合怎么用
适合穿插在写代码、查问题、做 Review、上线前的小任务里。
适合开发场景
- 格式化、校验、压缩或检查和代码相关的文本。
- 把片段整理好再放进文档、工单、提交或交接材料。
- 不切换工具,快速检查一个小 payload。
开发检查项
- 压缩、混淆这类不可逆处理,先对副本操作。
- 除非确认工具本地处理,不要粘贴密钥和敏感片段。
- 转换后的代码上线前,仍要跑自己的测试或 lint。
下一步可以接着做
这些入口会把当前任务接到更完整的工具链里。
真实使用场景
排查 AccessDenied 工单
搜索报错里出现的 condition key、ARN 格式或评估概念,再粘贴策略先抓 明显结构问题,不要一上来就把权限放宽。这样排查会围绕真实 action / resource 组合展开,而不是用 AdministratorAccess 临时糊过去。
部署前审一个角色
把准备上线的 policy 粘进去,快速看通配 Action、通配 Resource、 PassRole 范围、Allow 搭 NotAction、S3 对象 ARN 这几类高风险点。 复制出的报告足够短,可以直接放进 PR 或变更记录。
更快写信任策略
筛到 trust 和 assume-role 分类,对比服务主体、跨账号信任、ExternalId、 MFA 条件和 OIDC CI 写法。例子可以直接复制,但每条也写了导致 AssumeRole 失败的常见坑。
常见踩坑
把 `iam:PassRole` 授到 `*`,等于让部署者可能把管理员角色交给自己控制的算力。
给 `s3:GetObject` 这类对象动作只写桶 ARN;对象动作需要带 `/*` 的 ARN。
把 Principal 里的 `arn:aws:iam::account:root` 理解成只信任 root 用户,而不是信任整个账号的委托。
隐私说明
搜索词和分类筛选会写进 URL,方便分享当前视图。粘贴的 IAM policy 只保留在 当前标签页的 React state 中,不会写入 URL、localStorage,也不会发给外部服务。
常见问题
类似工具组合
做你这行的人, 还会一起用这些。