-
Notifications
You must be signed in to change notification settings - Fork 588
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhancement proposal for ARN linting #238
Comments
I have debated this a few times. There is also this article from AWS that has all the valid ARN syntaxes. I think there are some other tricky areas like IAM that doesn't have a region etc that would be helpful to help people to syntax. Other areas of possibilities.
I think the possibilities of getting this setup well could be awesome but we should probably start small. Some part of me wants to relate this to #50 but instead of allowed values using a Regex. @cmmeyer thoughts? |
@kddejong any new thoughts/ideas on this that we could perhaps contribute to? |
@SanderKnape we are starting to cover this with Regex checking. An Iam Role Arn has to match the following pattern. We still have work to build out all those AllowedPatternRegex values but this capability now exists. |
I like the idea of a non-Error level rule that could flag ARNs with hardcoded partitions, regions, accounts, or resources |
@kddejong Given all progress since this issue was created, does it make sense to keep it open still? |
We have made a lot of progress in this space. We can add new issues as needed. |
Given that the ARN format always starts with
arn:aws:
and for each product has a clear defined syntax it seems like an ideal candidate to add to the linter (and the roadmap agrees).My naive thinking currently says: check normal ARNs via something like regular expressions, keeping in mind that there's a fair amount that are essentially variable length. Could be a simple switch logic based on product and test for presence of fields/number of colons and test fields whether they comply to expected syntax.
Substitute syntax will be an interesting case to lint, like
!Sub "arn:aws:iam::${SomeAccountId}:user
.What do you think, @cmmeyer and @kddejong? See any potential hurdles with the above?
There's time within our company to pick this up and work on it.
The text was updated successfully, but these errors were encountered: