Policy template instance-secure-parameter-role-policy.json is invalid

[ryancausey]

Describe the bug

The statement:

{
    "Action": [
        "ssm:GetParameters"
    ],
    "Effect": "Allow",
    "Resource": "arn:aws:ssm:*"
}

Is not a valid policy statement due to the Resource argument using an invalid ARN wildcard. The statement "arn:aws:ssm:*" is disallowed by the IAM policy editor within the AWS console. It also has, albeit inconsistently, failed to apply when running terraform apply.

To Reproduce

Steps to reproduce the behavior:

1. Instantiate a SSM parameter to store the runner access token.
2. Instantiate the gitlab runner module by passing the above SSM parameter name to the access_token_secure_parameter_store_name argument of the runner_gitlab configuration block.
3. See error

module.runner.aws_iam_policy.ssm: Creating...
╷
│ Error: creating IAM Policy (nonprod300520813-ssm): MalformedPolicyDocument: Invalid policy
│ 	status code: 400, request id: f69871f2-4b16-4e1d-a43c-d533fb416a6f
│ 
│   with module.runner.aws_iam_policy.ssm,
│   on .terraform/modules/runner/main.tf line 593, in resource "aws_iam_policy" "ssm":
│  593: resource "aws_iam_policy" "ssm" {
│ 
╵

Expected behavior

The policy generated from the template should be a valid IAM policy that can apply.

Additional context

I'm not sure why this worked previously, as the IAM ARN docs under the "Using wildcards and paths in ARNs" heading states that:

You can use wildcards in the resource portion of the ARN

The strangest thing is that up until today, I never had issues with this policy being rejected. However, now it is on some of my jobs that deploy a runner, but not all of them. 🤷

A solution that keeps the same semantics of the existing policy would be:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:PutParameter",
                "ssm:GetParameter",
                "ssm:GetParameters"
            ],
            "Resource": "*"
        }
    ]
}

The wildcard will still apply to any parameter stored in SSM, as I believe the previous policy was attempting to do.

[przemyslawhaptas]

I found a bit more detailed wildcard solved the issue e.g.:

"Resource": "arn:${partition}:ssm:*”” -> "Resource": "arn:${partition}:ssm:*:*:*”

[ryancausey]

It appears that this was a behavior change AWS introduced:

Starting May 7, 2024, AWS Identity and Access Management (IAM) is updating how Amazon Resource Names (ARNs) in the Resource element of identity-based and resource-based policies are validated during policy creation and update.

Depending on the resource type, ARNs may omit the Region, the account ID, or both the Region and the account ID. An incompletely specified ARN omits more segments than the resource type allows. Prior to May 7, 2024, when the Resource element in a policy was incompletely specified, IAM evaluated the incomplete segments of the ARN as being populated with a wildcard.