SECURITY PROBLEM
A cloud project needs more than enabled APIs and administrator access.
The security problem is to make identity, network and telemetry boundaries explicit while avoiding long-lived credentials, unnecessary public exposure and weak evidence handling. The project therefore treats authentication, segmentation, logging, encryption and validation as one engineering system.
KEYLESS IAM
Separate identity creation from privilege, and avoid private service-account keys by default.
The baseline creates dedicated application, data and Terraform deployment service accounts without creating user-managed private keys. Workload Identity Federation is available as an opt-in path so GitHub Actions can eventually obtain short-lived Google Cloud credentials through OIDC rather than storing a service-account JSON key.
Application and data tiers use separate service accounts instead of a shared runtime identity.
Workload Identity Federation is the target deployment authentication model.
Creating a service account does not automatically grant broad project permissions.
Validation will confirm whether federated deployment activity is attributable in Cloud Audit Logs.
NETWORK SECURITY
Build intentional paths and make them observable.
The custom-mode VPC contains separate web, application and data subnets. Private Google Access is enabled, VPC Flow Logs are configured on all three subnets, firewall logging is enabled, web-to-app and app-to-data paths are explicit, and internet-origin SSH/RDP is denied by policy.
The base project does not create VMs, public IP addresses, Cloud NAT or load balancers simply to make the diagram look more complex.
AUDIT & EVIDENCE SECURITY
Security telemetry should survive long enough to support investigation and assurance.
Cloud Audit Logs, VPC Flow Logs and firewall telemetry are routed through a Cloud Logging sink into a dedicated Cloud Storage archive. The archive uses uniform bucket-level access, public-access prevention, versioning, retention and a customer-managed Cloud KMS key with rotation.
Data Access audit logging is deliberately opt-in because useful security telemetry also has volume, privacy and cost consequences.
AUTOMATED ASSURANCE
Let CI challenge the architecture before a cloud deployment does.
The GitHub Actions quality workflow runs Terraform formatting, provider initialisation and `terraform validate`, then executes repository-specific security guardrails that reject service-account key resources, legacy public bucket ACL patterns and missing baseline controls.
The first CI run caught an incorrect Google provider resource declaration for the Cloud Storage service account. The implementation was corrected to use the provider data source, and the second full quality run passed. That history is retained as engineering evidence rather than hidden.
VALIDATION PROGRAMME
Use one GCP lab to strengthen infrastructure evidence and detection engineering together.
The backlog covers cost-safe deployment, network segmentation, VPC Flow Logs, Cloud Audit Log archiving, KMS and storage protection, keyless IAM, GitHub Workload Identity Federation, Data Access audit logs, Security Command Center assessment, protected Terraform state and controlled teardown.
A dedicated cross-repository validation issue will also generate authorised Google Cloud IAM telemetry for the `GCP-001` and `GCP-002` rules in the Detection as Code repository. This creates a stronger evidence chain than treating each project as an isolated demo.