Add check for unnecessary GCP permissions

[ace-n]

We should add a recommender-based check to the project to identify over-provisioned permissions.

Unresolved questions

Should this be a CI check, or a periodic test?

CI checks are generally used for checking errors caused by the code itself. Unless these permissions are created via Terraform, they are likely configured within the GCP Console.

If those permissions are created by Terraform, then a CI check makes sense. Otherwise, we may consider implementing this as a nightly check rather than as a presubmit.

Related User Journeys: #45

[ace-n]

Possible gcloud command:

gcloud recommender recommendations list --project <PROJECT> --location global --recommender google.iam.policy.Recommender

[ace-n]

WIP bash script (uses the jq package):

RECOMMENDATIONS=$(gcloud recommender recommendations list \
    --project nodejs-docs-samples \
    --location global \
    --recommender google.iam.policy.Recommender \
    --format json)

echo "$RECOMMENDATIONS" | \
    jq '"\(.[].content.overview.member): \(.[].content.overview.removedRole)"' | \
    sort | uniq

I'm not sure how quickly the results auto-update, though.

[grayside]

Maybe this should be a nightly or weekly screening that opens an issue if we haven't configured a recommender.ignore for a particular rule?

[ace-n]

Per offline conversation with @grayside:

---

PR #155 contains scripts that will generate the appropriate recommendations.

However, we need to figure out how best to report those recommendations.

GitHub issues seems to be the current favorite, since this doesn't really change on a per-commit basis. Email notifications and/or Cloud Error Reporting might be options too, if we want to keep this repo isolated from specific instances of Emblem.

[grayside]

How we handle reporting relates to what we're hoping to gain from the recommendations.

I think what's important about this is work in our backlog to investigate specific recommendations, especially as recommendations change. While this starts with IAM, if we can sort this out we may want to expand. I also expect that if we do this right, we should approach this as a separate project we deploy for Emblem, rather than part of Emblem.

So for the backlog, I'd want to see an issue that let's us know we should evaluate the recommendation and re-evaluate our IAM needs, and take one of the following steps:

• Configure something so the particular recommendation is ignored, perhaps with an explanation why we're ignoring it
• Modify terraform/deploy scripts to apply the recommendation.

Because this goes to development process rather than "troubleshooting", I do think our project management tooling (GitHub) makes more sense than Ops tooling (Error Reporting). However, if we start automating work, other challenges emerge, such as not creating duplicate issues when we don't get around to following up on a recommendation review before the next check.

I think this needs a more design-driven approach to make sure all the considerations are explored, and probably expert review from the folks in the GitHub Automation team.

[grayside]

This is a future improvement, we want to complete #614 and come back to this in the future if we establish that we're accidentally over-privileging future identities.