Feature - Operate mocking multiple accounts

[rpattcorner]

We're implementing a cross-account configuration utility, and selecting a mocking framework. From what I can tell localstack implements a wide range of services, but the scope of the mocking is a single account. To test that hypothesis (using localstack-client I've implemented two sessions and added same-named roles to each. This should create a name collision failure, but instead creates a consistent set of same-named roles across both sessions.

[digression ... that's probably a defect and should throw a 'RoleExists' exception]

So it looks like all sessions are one, which pretty much prevents using localstack for cross account testing

:(

Is there a recommended approach for the use case:

• Create a user in account A
• Create a role in account B and allow user to assume it
• Create another role in account C and allow user to assume it

?

I see there are some partly hidden flags on creating sessions for each invocation like CREATE_NEW_SESSION_PER_BOTO3_CONNECTION and CUSTOM_BOTO3_SESSION, but not much documentation there, and given that session separation doesn't seem to exist, I'm not too hopeful -- they may just be sugar for what I did by hand?

Then there are nasty kludges like settling for just 2 accounts and trying to drive them to different regions. Could that work in a pinch?

Do we have any capability or experience/doc in dealing with multiple accounts in a test?

pytest_localstack does seem to have some separation for accounts, but sadly does not implement IAM, where the bulk of the work is!

┆Issue is synchronized with this Jira Bug by Unito

[borgoat]

Also interested in this! I'd also love to be able to use AWS Organizations API to create accounts, OUs, service control policies...

We're doing some work around the provisioning of new accounts in an organization with a template (deleting default internet gateway or default VPC, provisioning new VPCs and subnets, attaching transit gateways and creating default roles and IdP and so on) and it's particularly awful to do in AWS because for any account created for tests you have to reset the root password and delete it manually, and yet they still remain in the Organization cluttering it...

[whummer]

Thanks for reporting @rpattcorner @giorgioazzinnaro . Multi-account setups are currently not directly supported, but a possible workaround could be to:

• spin up two LocalStack instances
• use different port configurations for the services in the two instances
• configure TEST_AWS_ACCOUNT_ID to use different account IDs for the two instances (https://github.com/localstack/localstack/blob/master/localstack/constants.py#L44)
• optionally, configure DEFAULT_REGION to use different regions for the two instances

Would that work?

[borgoat]

Hey @whummer !

Thanks for the hint! I think for the work I'm doing this is only partially suitable however..

To better explain my requirement: I am working on a "Landing Zone"/"Account Vending Machine" implementation, and because of that, I actually need to be able to provision accounts via the API, then assume roles from other accounts and execute other actions there.

I'm wondering whether the actual implementation could be the logic you're suggesting? That we simply spin up new localstack instances when triggered via the Organizations API

[rpattcorner]

@whummer I've been working on your suggestion to start two stacks (and abandon pytest-localstack), as for unknown reasons the latest localstack that pytest_localstack pulls isn't the one with the fix for #2647 . However I'm working in Python and there seems to be no way to point a localstack session to a particular instance started in docker-compose. Do you have any thoughts on how to do so?

Basic code would be:

import localstack_client.session

session = localstack_client.session.Session()  #  Magic happens here to point to either localstack_identity or localstack_target below
iam = session.client('iam')

An outline of the docker compose would be:

version: '2.1'
services:
  localstack_identity:
    image: localstack/localstack:0.11.1
    environment:
      - EDGE_PORT=4566
      - TEST_AWS_ACCOUNT_ID="123456789012"
      - SERVICES=iam
      ...
    volumes:
      - "${TMPDIR:-/tmp/localstack}:/tmp/localstack_id"
      - "/var/run/docker.sock:/var/run/docker.sock_id"
  localstack_target:
    image: localstack/localstack:0.11.1
    environment:
      - EDGE_PORT=4567
      - TEST_AWS_ACCOUNT_ID="987654321098"
      - SERVICES=iam
...

[rpattcorner]

@whummer A suggestion:

More and more best practices are suggesting mapping a project+environment to an AWS account, e.g.:

• Account DogProject-Prod 123412341234
• Account DogProject-Dev 234523452345
• Account CatProject-Dev 345634563456

because

1. Accounts create a superior security boundary for a project/environment instead of having multiple projects in a DEV or PROD account, etc., and
2. The advent of Organizations makes it easy to create (but not delete!) accounts and constrain their security profile from above

I understand that a localtest stack effectively implements a single account (with a configurable account number) and am working on a crude implementation per your suggestion

I understand in general terms that implementing separate accounts within a stack is a significant difficulty

But ... this would open up localstack to mocking the multi-account scenarios that are becoming more and more common.

Perhaps multi-account-in-stack is the "worth paying for" feature that the Professional version is looking for. I'd certainly be interested!

[kjenney]

@rezafuru Is it currently possible to assume roles between two accounts with the Pro Edition?

[whummer]

Hi @kjenney @rpattcorner , this should technically be possible, yes - in Pro, you can spin up a multi-account LocalStack instance, and then assume a role in a different account.

Can you please share some more details about your exact requirements - do you require full IAM enforcement, i.e., should the API calls fail in case the permissions are missing or the assume role policy is not in place?

If you could share some more details about your use case (ideally a few snippets of your client code), we'll be happy to look into it. Please feel free to create a new issue on Github, or reach out to us via the Slack channel. Thanks!

[kjenney]

@whummer I'd like to be able to reproduce the act of account and organization creation for the purposes of testing infra-level operations. I'm using the first account as the master account for the organization. I'm then creating a second account that is used for networking components (i.e. transit gateway) and a third account that is used for centralized logging for the organization. I want to be able to mock this in it's entirety as an action/blocker on a pull request. This way if I need to change a critical component I can validate the change without touching anything in the real world.

[alexrashed]

Hi @kjenney! In the last few months we released a ton of features towards this direction.

• In December 2022, we release multi-account support in Community with version v1.3.0.
• This multi-accounts support has been improved with lots of contributions since then.
• With v2.0, we introduced cross-service IAM enforcement in LocalStack Pro.

Could you maybe revisit this issue and see if the features you requested are already implemented? Thanks!

[kjenney]

Thanks, @alexrashed! I forgot about this one. I'll take a look and verify, but don't let my request prevent this issue from being closed if multiple account mocking has been reached.

[alexrashed]

Awesome, thanks! Then I'll close this issue for now. Please let us know if you are still experiencing any issues with our multi-accounts support. :)