Closed bviswanathan-exelixis closed 11 months ago
Thank you for your proposal.
If there are no conditions or the condition is too permissive, it could allow unintended repositories to assume the role.
This is AWS IAM Role's settings settings of cloud providers such as AWS, not GitHub Actions.
So this is out of scope of ghalint.
For example, in case of AWS, IAM Role's trust policy should be configured properly.
e.g.
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:ref:refs/heads/octo-branch"
}
}
This is the setting of AWS, not GitHub Actions.
If you have any ideas of new lint rules, could you tell us examples?
e.g. https://github.com/suzuki-shunsuke/ghalint#job_permissions
@suzuki-shunsuke I don't have good idea on linting rules but if we can create rules for checking as written in this blog around github security best practices - https://engineering.salesforce.com/github-actions-security-best-practices-b8f9df5c75f5/ then that can be run as part of ghalint tool.
Something like this one - https://github.com/turbot/steampipe-mod-github-sherlock
I read the blog post https://engineering.salesforce.com/github-actions-security-best-practices-b8f9df5c75f5/ and created some issues.
I close this issue because the problem and action are not clear. We need to clarify the issue and action in the scope of ghalint (GitHub Actions Linter).
I already created some issues based on some best practices and handled some of them.
Ensure IAM policies to integrate with GitHub's OIDC provider validate the subject claim to limit the context in which the role can be assumed. If there are no conditions or the condition is too permissive, it could allow unintended repositories to assume the role.
Doc reference - https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect