InspectOwnPrincipal allowed iam:GetRole and iam:SimulatePrincipalPolicy on
role/*, letting any workspace user enumerate and simulate every role. IAM
refuses ${aws:PrincipalArn} as a Resource and has no role-name variable, so
the role part is now SSO permission-set roles
(role/aws-reserved/sso.amazonaws.com/*) and triple-c-* roles; IAM users stay
limited to themselves. Callers on other roles are probed and reported
Insufficient; the README says how an admin can add their sign-in roles.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Real IAM contradicted the policies in five places, now fixed:
- IAM refuses ${aws:PrincipalArn} as a Resource, so neither tier policy
could be attached. Self-inspection is user/${aws:username} for IAM users
and role/* for role sessions (no role-name variable exists).
- ecs:ExecuteCommand is authorized against the cluster as well as the task;
added an unconditioned cluster statement (the owner rule stays on the task).
- Secrets Manager needs kms:Decrypt with GenerateDataKey on a customer key.
- elasticfilesystem:CreateFileSystem has no resource type (Resource "*").
- ssmmessages:OpenDataChannel on the caller's own sessions (AWS docs).
The permission check now uses adaptive retries for IAM (SimulatePrincipalPolicy
throttled a full check), and the UI no longer says the simulator ignores
permission boundaries (it applies the principal's own; verified).
aws::live_tests (ignored, env-gated) repeats the verification with throwaway
triple-c-e2e-* roles, secrets and keys. New drift tests: every Resource is an
ARN or *, and every policy fits a 6,144-character managed policy.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
check_permissions now returns Result: credential errors from any call,
and non-denied failures resolving the principal, are errors rather than
a report. Other per-check failures (throttling, network) make the row
Unverified with a note, and a noted row blocks its tier. A probed run
never claims EnvironmentAdmin (R15), and the own-principal check whose
denial forced probing is reported Denied.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
check_permissions simulates every check of both tiers against the
caller's resolved principal (bounded to 4 in flight), rendering resources
and literal context values, sending OwnerId and aws:userid as the
caller's user id, and grouping repeated context keys into one StringList
entry. An unsimulatable principal, a denied iam:GetRole or a denied first
simulation falls back to four read-only probes. Results are one row per
action (worst verdict wins).
The trait returns Send futures so the check is Send for Tauri commands.
The module-wide dead_code/unused_imports allow is replaced by allows on
the Task 6 entry points and the re-exports.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The AWS-managed aws/secretsmanager key (or a customer key whose key policy
grants account principals) needs no identity-policy Allow, so the tagged-key
Allow alone did not keep user secrets on environment keys. An explicit Deny
on kms:Encrypt / kms:GenerateDataKey* via secretsmanager when the key lacks
triple-c:component does. README claim corrected; verify-live entry added.
Check.context doc now states the StringList rule as a requirement on the
simulation builder.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- CreateOwnSecrets requires secretsmanager:KmsKeyId to be a key ARN, and a
workspace user's kms:Encrypt/GenerateDataKey (via Secrets Manager) only
works on component-tagged keys, so secrets can't land on the default
aws/secretsmanager key that the boundary can't decrypt.
- Every workspace statement that sets the owner tag limits aws:TagKeys to
triple-c:owner/project/environment (ForAllValues:StringEquals), so a user
can never set triple-c:component.
- Evaluator: multi-valued context keys and ForAllValues (vacuous when
absent); Check documents repeated keys as one StringList entry.
- README: environment-key invariant and new verify-live entries.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- workspace-user: TagOwnSecrets refuses component-tagged secrets, plus an
explicit Deny on Tag/Untag/Put/Delete of component-tagged secrets;
CreateAccessPoint only on the component-tagged file system.
- environment-admin: Deny PutRolePermissionsBoundary on triple-c-* roles to
anything but the triple-c boundary; Deny Create/UpdateStack and
CreateChangeSet on triple-c-* stacks with a service role.
- permissions boundary: kms:Decrypt and EFS client access only on
component-tagged keys and file systems; ClientRootAccess dropped (access
points fix the POSIX user).
- README: invariants for phase 4 templates, the actions that are on *, the
phase-6 access-point root note, and the list to verify live.
- Tests: negated operators in the evaluator, both tiers evaluated together,
secret claiming, service-role and boundary-reach cases.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Ship aws/policies/permissions-boundary.json (triple-c-permissions-boundary):
the most any Triple-C role may hold, nothing in IAM.
- environment-admin: role writes require iam:PermissionsBoundary = the
boundary; explicit Denies keep the boundary on roles and the boundary
policy unchanged. Security groups, EFS file systems and KMS keys need
triple-c:component on create and to be modified or destroyed; tagging only
at create or on already-tagged resources.
- workspace-user: RunTask needs an owner-tagged task definition; EFS access
points create/delete by owner tag.
- Both tiers: iam:GetRole and iam:SimulatePrincipalPolicy on the caller's own
${aws:PrincipalArn} only, so SSO callers can be simulated.
- Checks carry the matching context; render() gains {principal}. The test
evaluator resolves policy variables and applies explicit Denies.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
aws/policies/{workspace-user,environment-admin}.json are the IAM policies
for the two tiers; aws::policies embeds them and holds one representative
simulator check per action. Tests keep table and JSON in lock-step and run
each check through a small IAM-style evaluator, including the isolation
rule: owner-scoped actions are denied for someone else's resource.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
