Skip to content

Permission set doesn't update despite all good signs #110

Open
@allquixotic

Description

@allquixotic

We have many permission sets that are updating correctly, and one of them that for unknown reasons doesn't seem to get updated at all by SSO Extensions.

I can reproduce this both with v3.1.7 and with the latest PR of v3.1.8.

Here are steps to reproduce:

  • An old version of the permission set exists in AWS SSO and is provisioned to permission sets.
  • When we add permissions to the inline policy and upload it to the S3 bucket permission_sets folder, we do not get any error emails.
  • The permissionSetTopicProcessor Lambda function executes when we upload the new version to S3. The statusMessage fields that appear include: Initiating permission set CRUD logic, then Resolved instanceArn as arn:aws:sso:::instance/ssoins-...., then Determined permission set operation is of type update, then Determined that permission set exists, then calculating delta for permissionSet update operation, then permission Set update operation completed with a "status": "Completed" at the end. The relatedData references the correct permission set name the entire way.
  • In the DynamoDB table env-permisisonSetTable, the changes we made in the JSON file in S3 are present -- meaning, we added CMPs and modified the inline policy in the S3 JSON, and the data we modified does appear in the table under the correct permissionSetName. So whatever happens with the Lambda, it successfully updates Dynamo with the desired "new state".

After all the above, however, the updated permission set is NOT reflected in the AWS SSO console. So the only piece of the architecture that appears to not update correctly, is AWS SSO itself. It simply contains the "old" version of the permission set, with the new CMPs missing, and the new inline policy additions missing.

The strangest thing is that other permission sets can be updated successfully, and the log messages in the permissionSetTopicProcessor are different!

Here's what I saw in the statusMessages of the permissionSetTopicProcessor when a permission set is completely successfully updated, end-to-end:

Initiating permission set CRUD logic
Resolved instanceArn as arn:aws:sso:::instance/ssoins-...
Determined permission set operation ins of type update
Determined that permission set exists
calculating delta for permissionSet update operation
objectArn found, progressing with delta for permission Set update operation
Determining delta for switchKey inlinePolicyDocument-update as part of permissionSet update operation
created/updated inline policy document for permission Set update operation
triggered re-provisioning for permission Set update operation
Waiter invoked for permissionSetProvisioned Operation
Waiter Completed with result: {\"state\":\"SUCCESS\"}"
re-provisioning operation completed for permission Set update operation
permission Set update operation completed

So, even though all the steps of the statusMessages "look like good progress" in the failing case, it seems it skips quite a few steps.

And no, I do not see a prompt to "provision" the permission set in the AWS SSO UI. That makes sense to me, though, because there's no changes the permission set to be provisioned. I expected there to be changes, but when examining the CMPs and inline policy "live", none of the changes we made appear in SSO.

Note, I do not think this behavior is any different between v3.1.7 and v3.1.8. It's just something about this one permission set that is messed up and causes it to take a different, broken, code path in the env-permissionSetTopicProcessor lambda.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions