amadan
README: re-check mail users with operator credentials after IAM step 2
Astra round 2, P0. iam:CreateAccessKey cannot be conditioned on the boundary, so a holder of the console role could make an unbounded user between the check and step 2. Step 7: wait for propagation, re-run the inventory with operator credentials, delete or bound any stragglers.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 file changed,
+1
−0
README.md+1 −0
diff --git a/README.md b/README.md| index 497ee1b62..14c9947fa 100644 |
| --- a/README.md |
| +++ b/README.md |
| @@ -510,6 +510,7 @@ Roll it in this order: |
| 4. run the sweep, which also reaches users nothing will touch again. set `CARLOS_MAIL_BOUNDARY_SWEEP=1` on one console and restart it. it logs `set the boundary on <user>` for each user it fixes. its last line is either `all N mail users bounded` or the users that are not, with why. fix any failure and run it again. then remove the variable. |
| 5. check it yourself. for every user in `aws iam list-users --path-prefix /carlos-mail/`, `aws iam get-user --user-name <user>` must show `PermissionsBoundary` with the boundary ARN. |
| 6. apply IAM step 2. condition the role's `iam:CreateUser` and `iam:PutUserPolicy` on `iam:PermissionsBoundary` equal to the boundary ARN. do this only after every console runs this release, because an older console creates users without the boundary and step 2 refuses them. |
| +7. wait a few minutes for IAM to propagate, then run the check in step 5 again with your own operator credentials, not the console role. `iam:CreateAccessKey` cannot be conditioned on the boundary, so anyone holding the console role could have made an unbounded user between step 5 and step 2. delete any user without the boundary, or set the boundary on it. the gap is closed only when this second check is clean. |
| ## App config & secrets |