Should moto honor the AWS Account ID send in every request?

[MSSputnik]

The AWS Account ID must be send in every request that is done using the quicksight API.
On moto side, there are some possibilities and I don't know what is the best option:

1. Ignore the value. Every resource is created / accessed using the backend account_id set during initialization.
2. Use the account_id. So the moto backend init account_id is ignored and the user can create resources in different accounts.
3. The moto server checks the account_id against the id configured, when the backend is initialized and raises an exception when they do not match. In real life you get a security exception that you do not have access to the quicksight instance in the other account.

Option 3 is the option closest to the real world but the two others are valid as well depending on the use case.
I found no other implemented service with a similar AWS API implementation but I might have overlooked it.

Thanks for your advice.

[bblommers]

The current implementation uses option 1, as far as I can tell, but we do persist/return the user-supplied account ID.

In AWS, I imagine it is possible to have access to quicksight instances in other accounts, assuming you have the appropriate IAM permissions.
Moto allows everything by design, so users don't have to bother with IAM permissions, so we could have a mix between option 2 and 3:

4. The moto server checks the account_id and raises an exception if there's an IAM policy that explicitly denies access to this AccountID. Otherwise it will use the account_id, and the user can create resources in the different account (option 2)

That behaviour is most similar to AWS, and keeps Moto easy to use.

However, I would suggest we keep our current implementation, so option 1. If/when users explicitly need cross-account access we can always revisit this, but I'm generally in favour of keeping things as simple as possible.

[MSSputnik]

HI,

in quicksight the current implementation is a mixture of option 1 and option 2. That's why I'm asking.

When a new user account is created, the ARN of this user contains the global account ID but the internal storage ID uses the sent account ID from the user request. So, to retrieve the user account you need to provide the same account ID you provided while creating but the ARN of the user contains the global account ID which is inconsitent.

The current implementation is close to option 2 - use the account ID sent by the user. So I will fix the inconsitency in this direction.
It is simple to use and it is what I as user would expect when no IAM permissions are in place.