You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CKV_GCP_125 adds a check to the attribute_condition field of google_iam_workload_identity_pool_provider based on best practices of limiting the calling scope of the GitHub repo.
However the current implementation[1] assumes that such a check must be implemented based on the assertion.sub field which GitHub states [2] "Defines the subject claim that is to be validated by the cloud provider. This setting is essential for making sure that access tokens are only allocated in a predictable way."
However, Google makes a point that this is insufficient to protect against typosquatting or cyberquatting attacks, and recommends using immutable values such as repository_id and repository_owner_id as a protection against that[3].
The check, as currently implemented, does not allow for this.
In general, as the condition and verification are VERY likely to be tweaked in enterprise organizations, it would be helpful to split this into two checks - one checking basic sanity (the OIDC issuer, that attribute mapping for google.subject exists, that there is anattribute_condition) and the other can be the opinionated mappings. This way, it's safer to ignore one check where the IT admins are doing something that makes sense for their organization without losing the full benefit of the generic parts of the check.
Thank you!
Version (please complete the following information):
3.2.356
CKV_GCP_125 adds a check to the
attribute_condition
field ofgoogle_iam_workload_identity_pool_provider
based on best practices of limiting the calling scope of the GitHub repo.However the current implementation[1] assumes that such a check must be implemented based on the
assertion.sub
field which GitHub states [2] "Defines the subject claim that is to be validated by the cloud provider. This setting is essential for making sure that access tokens are only allocated in a predictable way."However, Google makes a point that this is insufficient to protect against typosquatting or cyberquatting attacks, and recommends using immutable values such as
repository_id
andrepository_owner_id
as a protection against that[3].The check, as currently implemented, does not allow for this.
In general, as the condition and verification are VERY likely to be tweaked in enterprise organizations, it would be helpful to split this into two checks - one checking basic sanity (the OIDC issuer, that attribute mapping for
google.subject
exists, that there is anattribute_condition
) and the other can be the opinionated mappings. This way, it's safer to ignore one check where the IT admins are doing something that makes sense for their organization without losing the full benefit of the generic parts of the check.Thank you!
Version (please complete the following information):
3.2.356
Additional context
[1]
checkov/checkov/terraform/checks/resource/gcp/GithubActionsOIDCTrustPolicy.py
Line 23 in f322a28
[2] https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token
[3] https://github.com/google-github-actions/auth/blob/main/docs/SECURITY_CONSIDERATIONS.md#use-githubs-numeric-immutable-values
The text was updated successfully, but these errors were encountered: