Follow on issue from configure-aws-credentials

[1oglop1]

This is a follow-up on aws-actions/configure-aws-credentials#419 (comment)

Hello @djonser,
I managed to set everything up and tested both actions. They work as expected.

Limitations I ran into with this setup:

• AWS IAM policy language only allows ${aws:principalTag/<value>} in the Resource: "arn:aws:ssm:eu-central-1:1234567890:parameter/1-${aws:requestTag/workflow}/myservice

As a consequence of this limitation, I wasn't able to map any claim from the GitHub token to the resource which do not support Tags or access by a tag.

In my case we have a mono-repo with multiple services. And each service has 3 deploy workflows, one for each environment.
Then workflow names have these combinations.

svc1-dev, svc1-int, svc1-prod
svc2-dev, svc2-int, svc2-prod
svc3-dev, svc3-int, svc3-prod

And github environment is set to one of dev, int, prod.
So I could not use therepository claim either, because it maps to multiple services.

However, some resources have a service name as part of the name eg: target-group-svc1 and none of the claims can map directly to the svc1.
As a workaround, I thought of using an audience claim, but there is AWS Limit of 100 audiences per IAM OIDC provider.

Thank you for your blog post and provided idea for implementation.

PS. this is not really an issue, feel free to close it.

[djonser]

@1oglop1

I checked AWS Documentation and I can see that it does not list aws:principalTag as a condition key in this list. Not sure why this is as I have used aws:PrincipalTag with Parameter Store many times myself. Systems Manager have more features than Parameter Store so maybe its not supported by all those features.

Parameter Name Limitations

"Only a mix of letters, numbers and the following 3 symbols .-_ are allowed" in parameter names according to the AWS Console. So if your claim workflow contain anything other than that it would fail to create the parameter.

Policy

Make sure you use principalTag and not requestTag.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "ssm:PutParameter",
      "Resource": "arn:aws:ssm:eu-west-1:111111111111:parameter/1-${aws:principalTag/environment}/myservice"
    }
  ]
}

Usage in GitHub Actions

Assigning the policy above to the AWS IAM Role you use with Cognito Identity should allow you to test a workflow like below that it works.

name: SSM Test
on:
  workflow_dispatch:
    inputs:
      environment:
        type: string
        required: true
        description: Environment
jobs:
  test:
    runs-on: ubuntu-latest
    environment: ${{ inputs.environment }}
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: catnekaise/cognito-idpool-auth@alpha
        with:
          cognito-identity-pool-id: "eu-west-1:11111111-example"
          aws-account-id: "111111111111"
          aws-region: "eu-west-1"
          audience: "cognito-identity.amazonaws.com"
          set-in-environment: true

      - name: Create Parameter
        run: |
          aws ssm put-parameter --name /1-${{ inputs.environment }}/myservice \
          --value my_value --type String --overwrite

[1oglop1]

btw it looks like I found a bug https://github.com/catnekaise/cognito-idpool-auth/blob/alpha/action.yml#L170
- has to be the first or the last character otherwise grep returns invalid range

[djonser]

@1oglop1 you are right. Thanks for noticing this. Will update both this action and the basic-auth action as they most have the same regex validation.

Did you manage to solve the permission issue you described in the beginning?