Invalid tag when assuming role

[LaurenceGA]

Hi 👋
I've just been trying to use the new role-assuming feature in master, but I've run into an issues with the session tagging.

I'm getting the following error:

##[error]1 validation error detected: Value 'dependabot-preview[bot]' at 'tags.5.member.value' failed to satisfy constraint: Member must satisfy regular expression pattern: [\p{L}\p{Z}\p{N}_.:/=+\-@]*
##[error]Node run failed with exit code 1

My theory is that this is caused by tagging the session with the GITHUB_ACTOR environment variable.
In this line, the session is tagged with GITHUB_ACTOR.

The actor of the run (and so GITHUB_ACTOR) was dependabot-preview[bot].
It seems that [ and ] are not valid characters in AWS session tags, and so this is crashing the program.

Seems like the tag must be removed or the variable sanitised.

[mattsb42-aws]

My preference would be sanitizing the username in some way. My intentions in including all of those tags is so that the owner of that role can define fine-grained IAM policies that limit what event triggers are allowed to assume the role and so that CloudTrail logs would have a clear and useful audit information.

We should also make sure that none of the other tags have this issue. I suspect that GITHUB_ACTION, GITHUB_WORKFLOW, and GITHUB_REPOSITORY at least probably also have this issue.

Another concern in doing any sanitization is that we need to make sure that we don't sanitize in a way that will conflict with another valid value (ex: dependabot-preview[bot] and dependabot-preview_bot_ are both valid GitHub usernames). Maybe just base64-encode anything that allows unsupported characters? That would make the IAM policies and CloudTrail entries less immediately clear, but it is deterministic and if we apply it to every instance of a particular value, then we do not need to worry about conflicts.

[LaurenceGA]

Yeah encoding would be easiest, but would definitely make the logs a lot less clear. It would also make the fine-grained IAM policies difficult to define and would remove and ability to use wildcards for it.

At least for GITHUB_ACTOR, I think that the range of permitted characters is quite small. All Github usernames' characters must be alphanumeric or a hyphen.
So actually dependabot-preview_bot_ is not a valid Github username.
As far as I can tell, dependabot-preview[bot] is a special case of some sort. It's not a real user and hence not a real username. I guess that's why the variable is the Github actor.

A Github Repository name is alphanumeric + _, ., or -. This is a subset of what's allowed for AWS tags, so GITHUB_REPOSITORY shouldn't need to be sanitised.

GITHUB_WORKFLOW - I think this one is the tricky one. It seems like this can be almost anything. It's just whatever you put in the YAML config (or the path to your workflow by default). I couldn't find anything about character restrictions here...
We would need to at least replace #, [, ], ', ", * etc. Probably a lot more. I dunno, seems like a lot...

GITHUB_ACTION - not 100% sure about this. I think this is generate by Github and is usually the repository name or something...

To summarise:
GITHUB_ACTOR -> [ and ] seem to be special cases we can explicitly handle
GITHUB_REPOSITORY -> Doesn't need sanitisation
GITHUB_ACTION -> Doesn't need sanitisation
GITHUB_WORKFLOW -> base64 encode this....? Or try to sanitise as much as we can?

[mattsb42-aws]

I can't seem to find actual docs on the character space for username/repo, so I'm using the website error messages as a stand-in:

GITHUB_ACTOR

Per the new-user creation page:

Username may only contain alphanumeric characters or single hyphens, and cannot begin or end with a hyphen.

Agreed, we appear to be safe with the one special case.

GITHUB_REPOSITORY

The repo creation page doesn't actually complain if you put "bad" characters in the name, but apparently it just turns anything it doesn't like into either a - or a _.

It also appears to truncate the name to 100 characters.

We'll want to apply the same sanitization as the username because this value is actually the username/repo-name.

Agreed, we appear to be safe here.

Others

• GITHUB_WORKFLOW : I suspect that GitHub does some sanitization here. I'm going to do some digging to see what I can find.
• GITHUB_ACTION : I'm pretty sure this is the job name. I'll do some testing to confirm.
• GITHUB_REF : branch name; this should be fine
• GITHUB_SHA : hex hash or git tag name; this should be fine

[mattsb42-aws]

For reference so I don't have to search for it again, the restrictions on tag values are here: https://docs.aws.amazon.com/STS/latest/APIReference/API_Tag.html

You can pass up to 50 session tags. The plain text session tag values can’t exceed 256 characters. For these and additional limits, see IAM and STS Character Limits in the IAM User Guide.

Length Constraints: Minimum length of 0. Maximum length of 256.

Pattern: [\p{L}\p{Z}\p{N}_.:/=+-@]*

[LaurenceGA]

GITHUB_ACTION : I'm pretty sure this is the job name. I'll do some testing to confirm.

Nah I don't think it's the job name. The docs say:

The unique identifier (id) of the action.

So it's actually the action itself that the current running step is using (I think). The reason I say I think it's generated from the repo name is from having used some terraform actions. You can see here it will comment out $GITHUB_ACTION in PRs.
It's from a private repo so I don't have link, but an example output is

Action: hashicorpterraform-github-actions3

As far as I can tell this is "org + repo + 3". I'm not exactly sure why it's "3"...
(Repo is https://github.com/hashicorp/terraform-github-actions)

I assume for a user it would be "user + repo + #" 🤷‍♂

Either way I reckon this means it won't require any sanitisation.

[mattsb42-aws]

Possibly, yeah. If that's the case then I think the only potential issue would be the length.

Looks like the max username length is 39 characters, and I assume the same is true for orgs, since they're [kindasorta] just fancy users. That gives us 139 possible characters for the username + repo, leaving 117 for whatever is added to the end. If that's just the action execution counter, that should be plenty.

[LaurenceGA]

Well, it looks like this is a legitimate workflow name...:
!"#$%&'()*+, -./:;<=>?@[]^_`{|}~

(I just used Python's string.punctuation)

[LaurenceGA]

Emojis are also valid... 🙂💥🍌

Doesn't seem to be much restriction here. I think it's just any valid UTF-8 string 🤷‍♂

[shortpoet]

Not sure if creating a new issue is the way to go... I recently experienced this error:

Error: Unable to validate tags

Run aws-actions/configure-aws-credentials@v1.7.0

Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
Error: Unable to validate tags

The strange thing is, I am using the exact same workflow in a different repo and it works. I have double-checked the credentials, so I don't think that's it.