Hi @michaelbrizic, thanks for posting! Unfortunately organization-level imports aren’t currently supported in Lucidscale, although this is something we are hoping to support in future. This means that you would need to create a new cross-account role for each account you want to import. You may want to use our pre-populated CloudFormation stack template when setting up the cross-account role to speed things up. 

Hopefully this clarifies, but feel free to follow up with any questions!

Thanks for the response.

However, it seems that since we login, authenticate via a parent, main account and then switch roles in order to access the subaccount, running the CloudFormation stack template after I have switched doesn’t seem to create the necessary role properly for Lucidcharts because in order to get to that account a role switch, i.e. AssumeRole, is needed.

Am I doing something wrong or does that limitation make sense, and if the latter is true, what might be a workaround?

Hi @michaelbrizic, thanks for following up. Just to confirm,  are you seeing an issue only when you try to use our CloudFormation stack template to create the role? Are you able to successfully create the role manually for a sub-account, as described in these instructions? Please note you can initiate the ‘“Create Role” process in AWS and manually populate the details (such as external ID) provided in the Lucidscale import window. 

I manually populate the details but when I enter them into Lucid app the error returned states: We could not verify your credentials. Try again.
As I said, I think it has to do with the fact that I log into one account, then switch to another account via AssumeRole. It seems Lucid continues to think it is in the first account, because that is the one that I login with. 

Fwiw, we don’t use Organizations, simply multiple accounts with AssumeRole.

Thanks for confirming that Michael. Just to confirm, is the import method you’re currently trying to use the Cross-Account Role method? And do you see the error you mentioned after inputting the Role ARN and Role Name into the section of the  "Add the Cross-Account Role” import window in Lucidscale (as shown below)? 

Yes, that is correct for both questions

Thanks Michael! I have flagged this with our engineers. Just to make sure we’re all on the same page here, could you confirm if the following summary of the issue is correct? 

• You sign into a parent AWS account (‘account A’), then assume a role to access account B (child/sub-account). You’ve been able to successfully create a cross-account role for Lucidscale access in account A. The issue occurs when you try to create another new cross account role for Lucidcale in account B (which you’re accessing through an assumed role).

Additionally, could you confirm: 

• When you try to create the new cross-account role for Lucidscale imports in account B, are you doing this through the AWS management console with the step-by-step ‘create role’ wizard?
• After signing into the parent account, which exact method do you use to assume the role to access the child/sub-accounts

I log into parent account A and have no problem creating the cross-account role for Lucidscale. I’ve used automatic and manual approaches as documented. However, we have no services deployed in account A. So I switch to account B from A, using AssumeRole. The cross-account role that was created in account A has no permissions to do anything in account B. So, I again create a cross-account role in account B. Note, Lucidscale tries to re-create the cross-account role in account A while I have switched into account B using the AssumeRole. I believe this is because I am technically logged into account A. But, using the manual cross-account role creation process, I update the fields to be account B and then enter the external ID, and create the role. Then, I come back to Lucidscale and enter the role name and ARN and I get the error I mentioned. 

NOTE: I’ve also done it where I don’t modify the account number (as mentioned above) and then the cross-account role creation is again attempted in account A, which already exists.

Let me know if there are any other questions to answer. 

Thanks for helping out and escalating.

Hi @michaelbrizic, apologies for the delay getting back to you about this. Thank you for the detail, that’s very helpful.

Our engineers have suggested this may be due to an IAM policy limitation on your account which prevents these roles from being assumed externally, and instead only allows internal roles from the parent account to assume them. If you are still seeing this error, I suggest checking for any such limitation as the next step. Please let me know if you’ve already ruled this out and the error persists.