AWS emr documentation change
Summary
Minor editorial changes including replacing 'see' with 'refer to' in documentation links and rephrasing example instructions.
Security assessment
Changes are editorial improvements without introducing new security concepts. The existing content about denying tagging actions to prevent privilege escalation remains unchanged in substance.
Diff
diff --git a/emr/latest/EMR-Serverless-UserGuide/security-iam-TBAC.md b/emr/latest/EMR-Serverless-UserGuide/security-iam-TBAC.md index 238c106fb..2c14277e2 100644 --- a//emr/latest/EMR-Serverless-UserGuide/security-iam-TBAC.md +++ b//emr/latest/EMR-Serverless-UserGuide/security-iam-TBAC.md @@ -11 +11 @@ You can use conditions in your identity-based policy to control access to applic -The following examples demonstrate different scenarios and ways to use condition operators with EMR Serverless condition keys. These IAM policy statements are intended for demonstration purposes only and should not be used in production environments. There are multiple ways to combine policy statements to grant and deny permissions according to your requirements. For more information about planning and testing IAM policies, see the [IAM user Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/). +The following examples demonstrate different scenarios and ways to use condition operators with EMR Serverless condition keys. These IAM policy statements are intended for demonstration purposes only and should not be used in production environments. There are multiple ways to combine policy statements to grant and deny permissions according to your requirements. For more information about planning and testing IAM policies, refer to the [IAM user Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/). @@ -15 +15 @@ The following examples demonstrate different scenarios and ways to use condition -Explicitly denying permission for tagging actions is an important consideration. This prevents users from tagging a resource and thereby granting themselves permissions that you did not intend to grant. If tagging actions for a resource are not denied, a user can modify tags and circumvent the intention of the tag-based policies. For an example of a policy that denies tagging actions, see Deny access to add and remove tags. +Explicitly denying permission for tagging actions is an important consideration. This prevents users from tagging a resource and thereby granting themselves permissions that you did not intend to grant. If tagging actions for a resource are not denied, a user can modify tags and circumvent the intention of the tag-based policies. For an example of a policy that denies tagging actions, refer to Deny access to add and remove tags. @@ -52 +52 @@ JSON -You can also specify multiple tag values using a condition operator. For example, to allow actions on applications where the `department` tag contains the value `dev` or `test`, you could replace the condition block in the earlier example with the following. +You can also specify multiple tag values using a condition operator. For example, to allow actions on applications where the `department` tag contains the value `dev` or `test`, replace the condition block in the earlier example with the following.