You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running the create-change-set fails after upgrading from 1.0.15 to 1.0.16.
Steps to reproduce
Our setup has an masterAccountId in the .org-formation.rc that equals our management account and moreover has a custom DefaultBuildAccessRoleName that exists in the management account. Running "org-formation create-change-set" used to work, but now fails with: ERROR: unable to put object to s3 (bucket: organization-formation-<account_1>, key: change-sets/xxxx) User: arn:aws:sts::<account_1>:assumed-role/<account_1_role> is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::<account_1>:role/<account_2_role> (use option --print-stack to print stack)
Expected behaviour
Patch should not break existing functionality.
Actual behaviour
The command used to upload state and change-sets to account1, and that role <account_1_role> has rights to do so. Now it suddenly looks like it wants to assume the build role in the management account to upload things to s3 in the management account instead of <account_1>. This already seems strange to me, because this seems to suggest it wants to store the state-file in the management account all of a sudden.
Moreover, the error wants to assume the build-access-role in account 1 instead of in the management account, which also wouldn't make sense.
The text was updated successfully, but these errors were encountered:
Subject of the issue
Running the create-change-set fails after upgrading from 1.0.15 to 1.0.16.
Steps to reproduce
Our setup has an masterAccountId in the .org-formation.rc that equals our management account and moreover has a custom DefaultBuildAccessRoleName that exists in the management account. Running "org-formation create-change-set" used to work, but now fails with:
ERROR: unable to put object to s3 (bucket: organization-formation-<account_1>, key: change-sets/xxxx) User: arn:aws:sts::<account_1>:assumed-role/<account_1_role> is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::<account_1>:role/<account_2_role> (use option --print-stack to print stack)
Expected behaviour
Patch should not break existing functionality.
Actual behaviour
The command used to upload state and change-sets to account1, and that role <account_1_role> has rights to do so. Now it suddenly looks like it wants to assume the build role in the management account to upload things to s3 in the management account instead of <account_1>. This already seems strange to me, because this seems to suggest it wants to store the state-file in the management account all of a sudden.
Moreover, the error wants to assume the build-access-role in account 1 instead of in the management account, which also wouldn't make sense.
The text was updated successfully, but these errors were encountered: