Description
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. ThestatusMessage
fields that appear include:Initiating permission set CRUD logic
, thenResolved instanceArn as arn:aws:sso:::instance/ssoins-....
, thenDetermined permission set operation is of type update
, thenDetermined that permission set exists
, thencalculating delta for permissionSet update operation
, thenpermission Set update operation completed
with a"status": "Completed"
at the end. TherelatedData
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 correctpermissionSetName
. 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 statusMessage
s 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.