AWS systems-manager: Rework Parameter Store IAM condition key and authorization docs
Summary
Restructures the policy conditions page: removes the ssm:Recursive condition key section and example, adds a 'Condition keys specific to Parameter Store' section documenting ssm:Overwrite and ssm:Policies, and adds guidance to review how Parameter Store authorizes retrieval and how to restrict parameter access and SecureString decryption.
Security assessment
The change documents IAM authorization behavior for Parameter Store, including condition keys (ssm:Overwrite, ssm:Policies) and links to restricting parameter access and SecureString decryption. It clarifies that retrieval is authorized per-action, which is security-relevant access-control guidance, but it does not reference a specific vulnerability or CVE.
Evidence
+Before you write a policy that denies access to particular parameters, review [How Parameter Store authorizes parameter retrieval](./ps-retrieval-authorization.html). Parameter Store authorizes each retrieval operation independently, so a policy that denies only one action might not produce the result you intend.
Diff
diff --git a/systems-manager/latest/userguide/parameter-store-policy-conditions.md b/systems-manager/latest/userguide/parameter-store-policy-conditions.md index f7cf82840..c17d54f7f 100644 --- a//systems-manager/latest/userguide/parameter-store-policy-conditions.md +++ b//systems-manager/latest/userguide/parameter-store-policy-conditions.md @@ -7 +7 @@ -Preventing changes to existing parameters using ssm:OverwritePreventing creation or updates to parameters that use a parameter policy using ssm:PoliciesPreventing access to levels in a hierarchical parameter using ssm:Recursive +Condition keys specific to Parameter StorePreventing changes to existing parameters using ssm:OverwritePreventing creation or updates to parameters that use a parameter policy using ssm:Policies @@ -13 +13 @@ Using service-specific _[conditions](https://docs.aws.amazon.com/IAM/latest/User -Systems Manager currently supports three conditions that are specific to Parameter Store. +Before you write a policy that denies access to particular parameters, review [How Parameter Store authorizes parameter retrieval](./ps-retrieval-authorization.html). Parameter Store authorizes each retrieval operation independently, so a policy that denies only one action might not produce the result you intend. @@ -16,0 +17,8 @@ Systems Manager currently supports three conditions that are specific to Paramet + * [How Parameter Store authorizes parameter retrieval](./ps-retrieval-authorization.html) + + * [Restricting access to specific parameters and paths](./ps-restrict-parameter-access.html) + + * [Restricting decryption of SecureString parameter values](./ps-restrict-decryption.html) + + * Condition keys specific to Parameter Store + @@ -21 +28,0 @@ Systems Manager currently supports three conditions that are specific to Paramet - * Preventing access to levels in a hierarchical parameter using ssm:Recursive @@ -24,0 +32,15 @@ Systems Manager currently supports three conditions that are specific to Paramet +## Condition keys specific to Parameter Store + +Systems Manager supports two condition keys that are specific to Parameter Store. Both apply to the `PutParameter` operation and control how parameters can be created and updated. + +`ssm:Overwrite` + + +Controls whether a principal can update an existing parameter. See Preventing changes to existing parameters using ssm:Overwrite. + +`ssm:Policies` + + +Controls whether a principal can create or update a parameter that includes a parameter policy. See Preventing creation or updates to parameters that use a parameter policy using ssm:Policies. + +To restrict which parameters a principal can _read_ , use resource-level and action-level controls as described in [Restricting access to specific parameters and paths](./ps-restrict-parameter-access.html) rather than condition keys. @@ -110,47 +131,0 @@ JSON -## Preventing access to levels in a hierarchical parameter using `ssm:Recursive` - -Use the `ssm:Recursive` condition to control whether IAM Entities can view or reference levels in a hierarchical parameter. You can provide or restrict access to all parameters beyond a specific level of a hierarchy. - -In the following example policy, the `"Allow"` statement provides access to Parameter Store operations on all parameters in the path `/Code/Departments/Finance/*` for the AWS account 123456789012 in the US East (Ohio) Region (us-east-2). - -After this, the `"Deny"` statement prevents IAM Entities from viewing or retrieving parameter data at or below the level of `/Code/Departments/*`. Entities can still, however, still create or update parameters in that path. The example has been constructed to illustrate that recursively denying access below a certain level in a parameter hierarchy takes precedence over more permissive access in the same policy. - -JSON - - -**** - - - - { - "Version":"2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": [ - "ssm:*" - ], - "Resource": "arn:aws:ssm:us-east-1:111122223333:parameter/*" - }, - { - "Effect": "Deny", - "Action": [ - "ssm:GetParametersByPath" - ], - "Condition": { - "StringEquals": { - "ssm:Recursive": [ - "true" - ] - } - }, - "Resource": "arn:aws:ssm:us-east-1:111122223333:parameter/Code/Departments/*" - } - ] - } - - -###### Important - -If a user has access to a path, then the user can access all levels of that path. For example, if a user has permission to access path `/a`, then the user can also access `/a/b`. This is true unless the user has explicitly been denied access in IAM for parameter `/b`, as illustrated above. - @@ -165 +140 @@ Working with parameter hierarchies -Working with parameter labels +How parameter retrieval is authorized