Skip to content
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

Merged

Conversation

Anton0
Copy link
Contributor

@Anton0 Anton0 commented Nov 3, 2022

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:

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.

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 🤞

@benkehoe
Copy link
Owner

benkehoe commented Nov 4, 2022

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.

@stedrow
Copy link

stedrow commented Jan 10, 2023

+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?

@benkehoe
Copy link
Owner

Sorry for the delay; this looks mostly good. A couple of changes I'd like:

  • Add a parameter exclude_inactive_accts=False to the lookup_accounts_for_ou function, and add it to the status check if statement.
  • Move the check to after the caching line.
  • Add exclude_inactive_accts=True to the calls on line 233 of cli/src/aws_sso_util/cfn.py and line 105 of src/aws_sso_util/cfn_lib/macro.py.
  • Add yourself to CONTRIBUTORS.md (if you want).

@Anton0
Copy link
Contributor Author

Anton0 commented Jan 18, 2023

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).

@benkehoe
Copy link
Owner

This looks good, one minor style change: you've got if account["Status"] != "ACTIVE" and exclude_inactive_accts is True. As a rule, I'd put the exclusion check first, because often the thing you're disabling is expensive or may not work correctly (e.g., imagine if accounts didn't always have status or something). It doesn't matter here but I think it makes sense to always do it that way. And then I'd only use an is True check if I'm expecting that the value can be something other than True or False and I want specifically to check for True instead of truthy. Here's an example I have where the value can be boolean or string, so I check specifically for is True. Can you change it to if exclude_inactive_accts and account["Status"] != "ACTIVE"?

@Anton0
Copy link
Contributor Author

Anton0 commented Jan 19, 2023

That all makes perfect sense to me, thank you! (and updated)

@benkehoe benkehoe merged commit 34fe2ba into benkehoe:next Jan 27, 2023
iainelder added a commit to iainelder/aws-sso-util that referenced this pull request Oct 18, 2023
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.
```
iainelder added a commit to iainelder/aws-sso-util that referenced this pull request Oct 18, 2023
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants