Expand GCP Auditors

[jonrau1]

Story

As the maintainer of ElectricEye, I want to add more GCP auditors so that I can have coverage parity with AWS, additionally I want to support GCP Organization-level Service Accounts so that I can assess multiple GCP Projects at once.

Definition of Done

Add to the existing GCP coverage and refactor the GCP target workflow to either support multiple Projects or an entire Organization via Service Accounts or otherwise. Multi-project coverage is a stretch goal.

• Adding the following GCP Services/Components to the Auditors
  • Firebase
  • AlloyDB
  • BigQuery
  • BigTable
  • DataFlow
  • Cloud Spanner
  • Cloud Functions
  • Cloud Run (?!)
  • GKE: Binary Auth, CPANs, NetPol, no use GKE default svc acct, PSP controller, Shield GKE, Release Channel K8s, Secure Boot, GCE legacy metadata api disabled, Legacy Auth disabled, IntegMon enabled
  • GCS
  • GAE (?!)
  • IAM (Service Accounts??)
• Updating Documentation for usage, checks, total checks, table

Nice to Have

• Multi-project / GCP Orgs Support: adding list of Projects into TOML or accepting a Comma-sep value input from click COMPLETE!
• Terraform for GCP multi-Project or some sort of script to speed up onboarding?
• More EASM checks

Additional Information

For GCP cross-Project / APIs info...all seems to be the same of creating one SA and then adding the SA email into all other Projects. Holy shit, there has to be a faster way...

• https://www.cloudquery.io/blog/creating-cross-project-service-accounts-in-gcp
• https://help.deepsecurity.trendmicro.com/20_0/on-premise/gcp-account-create.html
• https://docs.divvycloud.com/docs/projects-gcp

TOML Arrays (list)

• https://toml.io/en/v1.0.0#array
• https://realpython.com/python-toml/#arrays

[abaio-westhill]

Adding the following GCP Services/Components to the Auditors Firebase: do not use default firebase service account AlloyDB: do not use default alloy service account, ensure continuous backup & recovery is enabled, ensured automated backups are enabled BigQuery: do not use default bq service account, use policy tags for column level access BigTable: do not use default service account Cloud Spanner: do not use default service account Cloud Functions: do not use default service account, good to require auth depending on use case, require HTTPS, depending on use case only allow internal traffic so traffic is routed through VPC, place in a VPC network so egress traffic is routed through VPC, enable HTTP/2 and session affinity, enforce binary authorization for deployment Cloud Run - do not use default service account, best to force internal access so traffic has to flow through VPC depening on use case, require authentication depending on use case GKE (GKE Autopilot will enable a lot of these by default): Binary Auth, CPANs, NetPol, no use GKE default svc acct, PSP controller, Shield GKE, Release Channel K8s, Secure Boot, GCE legacy metadata api disabled, Legacy Auth disabled, IntegMon enabled GCS: enable bucket logging, depending on use case do not allow public access, enable versioning, enable retention policy, do not use default service account IAM Service Accounts: should be rotated on some recurring schedule, do not use primitive roles