AWS app-mesh: App Mesh guidance on scoping permissions and SLR indirect access
Summary
Adds a new 'Scope App Mesh permissions to segment workloads' section explaining that App Mesh calls downstream services with its service-linked role (so principal deny policies are not evaluated), and recommending scoping appmesh resource actions and Envoy proxy authorization per virtual node.
Security assessment
The text explicitly documents a privilege-escalation/confused-deputy weakness: principals granted App Mesh API access inherit the service-linked role's reach into downstream services (e.g., Cloud Map service discovery) and cannot be blocked by downstream deny policies, with concrete mitigations (scoping appmesh:* to owned ARNs, per-proxy StreamAggregatedResources authorization).
Evidence
+Because of this, if you grant a principal permission to call App Mesh APIs, you also give that principal indirect access to any resource that the service-linked role can reach. IAM doesn't evaluate policies that deny the principal access to the downstream service, such as `servicediscovery`, for these calls.
Diff
diff --git a/app-mesh/latest/userguide/security_iam_id-based-policy-examples.md b/app-mesh/latest/userguide/security_iam_id-based-policy-examples.md index e334ad7..99e7a6f 100644 --- a//app-mesh/latest/userguide/security_iam_id-based-policy-examples.md +++ b//app-mesh/latest/userguide/security_iam_id-based-policy-examples.md @@ -7 +7 @@ -Policy best practicesUsing the consoleAllow users to view their own permissionsCreate a meshList and describe all meshesCreating App Mesh meshes with restricted tags +Policy best practicesScope App Mesh permissions to segment workloadsUsing the consoleAllow users to view their own permissionsCreate a meshList and describe all meshesCreating App Mesh meshes with restricted tags @@ -22,0 +23,2 @@ To learn how to create an IAM identity-based policy using these example JSON pol + * Scope App Mesh permissions to segment workloads + @@ -54,0 +57,19 @@ For more information about best practices in IAM, see [Security best practices i +## Scope App Mesh permissions to segment workloads + +This topic explains how App Mesh uses a service-linked role to access other AWS services on your behalf, and describes practices you can use to scope permissions and segment workloads that share an account or a mesh. + +App Mesh acts on your behalf when it resolves the resources that your mesh refers to. It uses its service-linked role, `AWSServiceRoleForAppMesh`, to call other AWS services. It doesn't use the credentials of the principal that created the mesh resource. For example, when a virtual node uses AWS Cloud Map service discovery, App Mesh discovers the instances in the namespace with the service-linked role. + +Because of this, if you grant a principal permission to call App Mesh APIs, you also give that principal indirect access to any resource that the service-linked role can reach. IAM doesn't evaluate policies that deny the principal access to the downstream service, such as `servicediscovery`, for these calls. For more information about this behavior, see [Indirect permissions with service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#create-service-linked-role-permissions-transfer) in the _IAM User Guide_. + +To segment workloads that share an account or a mesh, control access at the App Mesh layer with the following practices. + + * **Scope resource management permissions to the resources a principal owns** – Don't grant `appmesh:*` to deployment roles, developer roles, or the service account of the App Mesh controller for Kubernetes. Instead, scope actions such as `appmesh:CreateVirtualNode` and `appmesh:UpdateVirtualNode` to the resource ARNs that the principal owns. For example, allow a team to manage only virtual nodes whose names start with that team's prefix. This prevents a principal from creating a virtual node that refers to another team's namespace or service. For more information about resource ARNs, see [Resources](./security_iam_service-with-iam.html#security_iam_service-with-iam-id-based-policies-resources). + + * **Scope Envoy proxy authorization to each proxy's own virtual node** – Enable proxy authorization for all virtual nodes and virtual gateways. Grant `appmesh:StreamAggregatedResources` to each workload's IAM role only for the ARN of the virtual node or virtual gateway that the workload runs. An Envoy proxy can then read only its own configuration, including the endpoints that App Mesh discovered for it. For more information about proxy authorization, see [Envoy Proxy authorization](./proxy-authorization.html). + + * **Don't rely on denying downstream service permissions** – Even if you deny a principal `servicediscovery` or other downstream actions, you can't restrict what App Mesh resolves for that principal. App Mesh makes those calls with its service-linked role. Use the App Mesh permissions described in the previous practices instead. + + + +