Closed 1oglop1 closed 11 months ago
@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.
"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.
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"
}
]
}
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
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
@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?
This is a follow-up on https://github.com/aws-actions/configure-aws-credentials/issues/419#issuecomment-1782481069
Hello @djonser, I managed to set everything up and tested both actions. They work as expected.
Limitations I ran into with this setup:
${aws:principalTag/<value>}
in theResource: "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.
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 thesvc1
. As a workaround, I thought of using anaudience
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.