Support App Mesh Across Multiple Accounts

[dastbe]

Define and implement at least one experience for supporting App Mesh across multiple accounts.

[janaka]

Does this mean cross-account doesn't work right now? or is this about creating a streamlined experience/first-class support?

[dastbe]

Hey @janaka

So right now we don't make this easy :(. While it's technically possible, there's a lot of limitations, such as

• It's not possible to reference non-App-Mesh resources such as CloudMap services from different accounts in our API
• We don't make it easy to have an Envoy connect as a Virtual Node in a different account
• It's not obvious how multiple accounts would be able to visualize (their parts of) the mesh

The end result is a lot of toil for customers to setup and maintain a mesh that spans accounts, and its something we want to streamline

[Vittoriusly]

It would be great if there will be something organization-aware.
My use-case is hosting a private DNS zone in a shared-dedicated account, while I deploy projects in dedicated accounts. These projects should use the same cloudmap and app-mesh. I rely on accounts because managing permissions for different partners became a nightmare.
V.

[dastbe]

Hey @Vittoriusly

Our current plan is make this work via Resource Access Manager. Through RAM, customers will be able to share their mesh with accounts/org units such that it's "as-if" it's just another mesh in their account.

There will be some caveats: as we don't orchestrate the underlying network or DNS, that will still fall to the Mesh/VPC owner. However, there exists support for sharing VPC subnets throughout your organization, which also allows one to associate cross-account hosted zones with the shared VPC.

Additionally, we're advocating our customer use cases around cloud map, tls certificates, and more to the respective teams so that we can create a rock solid experience around an org-level service mesh that "just works".

[dastbe]

also

I rely on accounts because managing permissions for different partners became a nightmare

agreed 100%. We wanna make sure that resources are properly silo'd so customers don't have to reason about complex IAM policies, while making sure the connecty bits are shared between everyone.

[dastbe]

Hey all! We've just merged to the preview model for access a mesh shared via Resource Access Manager. Resource Access Manager allows you to centralize configuration for shared resources, whether they're with a single account or your entire organization.

Given you've created a mesh in preview (I'll go with shared-mesh), you can create a resource share with another account

aws ram create-resource-share
    --region us-west-2
    --name my-shared-mesh
    --resource-arns arn:aws:appmesh:us-west-2:111122223333:mesh/shared-mesh
    --principals 444455556666

and when you list your resource shares

aws ram list-resources --resource-owner SELF

you will see that a appmesh-preview:Mesh has been shared

{
    "resources": [
        {
            "arn": "arn:aws:appmesh:us-west-2:111122223333:mesh/mesh-a",
            "type": "appmesh-preview:Mesh",
            "resourceShareArn": "arn:aws:ram:us-west-2:111122223333:resource-share/00000000-1111-2222-3333-444444444444",
            "creationTime": 1579218298.995,
            "lastUpdatedTime": 1579218300.035
        }
    ]
}

You can additionally list invitations

aws ram --region us-west-2 get-resource-share-invitations
{
    "resourceShareInvitations": [
        {
            "resourceShareInvitationArn": "arn:aws:ram:us-west-2:111122223333:resource-share-invitation/00000000-1111-2222-3333-444444444444",
            "resourceShareName": "test-preview-mesh",
            "resourceShareArn": "arn:aws:ram:us-west-2:111122223333:resource-share/00000000-1111-2222-3333-444444444444",
            "senderAccountId": "111122223333",
            "receiverAccountId": "444455556666",
            "invitationTimestamp": 1579145083.23,
            "status": "ACCEPTED"
        }
    ]
}

Once the receiver accepts the invitation from the console or cli via

aws ram accept-resource-share-invitation --resource-share-invitation-arn arn:aws:ram:us-west-2:111122223333:resource-share-invitation/00000000-1111-2222-3333-444444444444

The receiver will be able to see the shared mesh as part of their list-meshes response. For example

aws appmesh-preview list-meshes
{
    "meshes": [
        {
            "arn": "arn:aws:appmesh-preview:us-west-2:444455556666:mesh/my-mesh",
            "meshName": "my-mesh",
            "meshOwner": "444455556666",
            "resourceOwner": "444455556666"
        },
        {
            "arn": "arn:aws:appmesh-preview:us-west-2:111122223333:mesh/shared-mesh",
            "meshName": "shared-mesh",
            "meshOwner": "111122223333",
            "resourceOwner": "111122223333"
        }
    ]
}

You can interact with this mesh just like any other mesh by leveraging the the new meshOwner field available on all of our APIs, with some caveats.

• You can only modify resources that you own. We do allow the mesh owner to delete any resource as an escape hatch, however.
• Currently, permissions allow all users to list/describe all other users resources.
• When you unshare a mesh with an account, their resources still exist in our API until the mesh owner deletes them. However, to ensure security and safety we will remove all configuration related to their resources from materialized Envoy configuration, and disallow them from retrieving configuration for their Virtual Nodes.

We'll be getting the remaining documentation and walkthroughs onto our website and examples repository.

Happy Meshings!

[Y0Username]

Here's the walkthrough for the Cross Account Mesh support in Preview channel: https://github.com/aws/aws-app-mesh-examples/tree/master/walkthroughs/howto-cross-account

[dastbe]

This has launched! You can find out how to share your mesh with other accounts here: https://docs.aws.amazon.com/app-mesh/latest/userguide/sharing.html