Current state
The module's google_compute_instance.this has no service_account block — so VMs it creates have no identity and can't authenticate to any GCP API. (Earlier notes saying it uses the default Compute SA were wrong; verified in main.tf.)
Why / best practice
To let a consumer fetch secrets from GCP Secret Manager at boot (the Postiz Cloudflare-tunnel token in infra-environments-dev), the VM needs (1) a service account and (2) the cloud-platform OAuth scope (default scopes exclude Secret Manager). This also closes the standing 'VM has no SA' hardening gap.
Proposed
Add optional, backward-compatible per-instance fields to the instances object — omit ⇒ current no-SA behavior, set ⇒ emit a dynamic "service_account" block:
service_account_email (default "")service_account_scopes (default ["cloud-platform"])
Blocks
The GCP Secret Manager wiring in officialdad/infra-environments-dev (linked issue).
Current state
The module's
google_compute_instance.thishas noservice_accountblock — so VMs it creates have no identity and can't authenticate to any GCP API. (Earlier notes saying it uses the default Compute SA were wrong; verified inmain.tf.)Why / best practice
To let a consumer fetch secrets from GCP Secret Manager at boot (the Postiz Cloudflare-tunnel token in
infra-environments-dev), the VM needs (1) a service account and (2) thecloud-platformOAuth scope (default scopes exclude Secret Manager). This also closes the standing 'VM has no SA' hardening gap.Proposed
Add optional, backward-compatible per-instance fields to the
instancesobject — omit ⇒ current no-SA behavior, set ⇒ emit adynamic "service_account"block:service_account_email(default "")service_account_scopes(default["cloud-platform"])Blocks
The GCP Secret Manager wiring in
officialdad/infra-environments-dev(linked issue).