-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't return Suspended accounts when listing by OU #81
Don't return Suspended accounts when listing by OU #81
Conversation
Add documentation
I will take a look at this next week. It makes sense but I want to see if it makes sense to make the filtering configurable. |
+1 to this PR, I hit this issue recently. Is this something that can be added in, or is there another solution to this issue already implemented? |
Sorry for the delay; this looks mostly good. A couple of changes I'd like:
|
Thank you for the detailed review! I believe this addresses all the requested changes, and I've tested this again in our environment (though only an update operation). |
This looks good, one minor style change: you've got |
That all makes perfect sense to me, thank you! (and updated) |
The `lookup_accounts_for_ou` function yields accounts in two branches. Branch 1 handles uncached accounts and branch 2 handles cached accounts. PR benkehoe#81 added a check to exclude inactive accounts in branch 1 without adding the same check to branch 2. In that way it solved benkehoe#80 but only when the OU containing a suspended account doesn't repeat. This PR copies the check from branch 1 to branch 2 for consistent behavior in a template with many assgnment groups to the same target OU. The second assignment group no longer generates an assignment for a suspended account, which causes CloudFormation to fail with an error like this: ```text Resource handler returned message: "Error occurred during operation 'Request REDACTED failed due to: AWS SSO is unable to complete your request at this time. Obtaining permissions to manage your AWS account 'REDACTED' is taking longer than usual. ```
The `lookup_accounts_for_ou` function yields accounts in two branches. Branch 1 handles uncached accounts and branch 2 handles cached accounts. PR benkehoe#81 added a check to exclude inactive accounts in branch 1 without adding the same check to branch 2. In that way it solved benkehoe#80 but only when the OU containing a suspended account doesn't repeat. This PR copies the check from branch 1 to branch 2 for consistent behavior in a template with many assgnment groups to the same target OU. The second assignment group no longer generates an assignment for a suspended account, which causes CloudFormation to fail with an error like this: ```text Resource handler returned message: "Error occurred during operation 'Request REDACTED failed due to: AWS SSO is unable to complete your request at this time. Obtaining permissions to manage your AWS account 'REDACTED' is taking longer than usual. ``` Test the deployed macro with a template like this: ```yaml AWSTemplateFormatVersion: "2010-09-09" Transform: AWS-SSO-Util-2020-11-08 Resources: Test: Type: SSOUtil::SSO::AssignmentGroup Properties: Name: MacroTest Principal: - Type: GROUP Id: - 11111111-1111-1111-1111-111111111111 PermissionSet: - arn:aws:sso:::permissionSet/ssoins-2222222222222222/ps-3333333333333333 Target: - { Type: AWS_OU, Id: r-4444 } Test2: Type: SSOUtil::SSO::AssignmentGroup Properties: Name: MacroTest2 Principal: - Type: GROUP Id: - 55555555-5555-5555-5555-555555555555 PermissionSet: - arn:aws:sso:::permissionSet/ssoins-2222222222222222/ps-3333333333333333 Target: - { Type: AWS_OU, Id: r-4444 } ``` Consider an organization with active member accounts `111111111111` and `222222222222` and suspneded member account `333333333333`. Before this change, the CloudWatch logs group shows the following message for the first assignment group. It lists just active accounts as targets. ```text [DEBUG] 2023-10-17T13:13:49.592Z eeeeeeee-eeee-eeee-eeee-eeeeeeeeeeee Got targets: [ACCOUNT:111111111111[r-4444], ACCOUNT:222222222222[r-4444] ``` The group shows the following message for the second assignment group. It lists the active and suspended accounts as targets. This is incorrect behavior and later causes the CloudFormation error. ```text [DEBUG] 2023-10-17T13:13:49.593Z 334ac992-cf53-4af0-adac-7aa15704a573 Got targets: [ACCOUNT:111111111111[r-4444], ACCOUNT:222222222222[r-4444], ACCOUNT:333333333333[r-4444]] ``` After this change, each assignment group logs just the active accounts as targets.
The boto call list_accounts_for_parent includes accounts in with statuses
'ACTIVE'|'SUSPENDED'|'PENDING_CLOSURE'
However assignments cannot be deployed to accounts in the
SUSPENDED
state, trying to results in Cloudformation stalling and eventually returning an error when using the macro:Worth noting the same behavior occurs in the SSO web ui - you are permitted to begin creating the assignment, then it hangs on processing until eventually timing out
I'm not sure if there's a use case for deploying assignments to an account in
PENDING_CLOSURE
nor do I have an account to test that with, but it's easy enough to return those as well if you think it's worth allowing.I'm only using the macro, but I have tested against our accounts and this works as expected.
Resolves #80 hopefully 🤞