Front matter

A Note About Security

Security examples in this book intentionally favor secure defaults.

That does not mean every example represents the maximum control set appropriate to every regulated production environment.

It means insecure convenience is not treated as the neutral starting point.

Least privilege is the default §

Users, groups, service accounts, workloads, pipelines, and automation should receive the permissions they require rather than the permissions that are easiest to assign.

Broad roles are useful during initial investigation.

They are dangerous as permanent architecture.

If a service needs three permissions, giving it the equivalent of administrative ownership because "it works" is not troubleshooting. It is abandoning the access-control design.

Permanent credentials are avoided where practical §

Long-lived service account keys are not the preferred authentication method.

Where GCP supports a short-lived or federated identity model, the examples favor it.

That includes patterns such as:

  • Workload Identity Federation;
  • GKE workload identity;
  • service account impersonation;
  • identity federation from CI/CD systems;
  • metadata-based workload credentials.

A credential that does not exist cannot be accidentally committed to Git.

Public exposure must be intentional §

Resources should not become public simply because public access is the fastest way to make an example work.

Internet-facing services are exposed because the architecture requires them to be internet-facing.

Databases, administrative interfaces, build systems, internal APIs, storage, and management services should remain private unless there is a specific reason not to.

Network location is not identity §

A packet arriving from the "right" network is not proof that the caller should be trusted.

Network controls are one layer.

Authentication and authorization are another.

Good architecture uses both where appropriate.

Secrets are not configuration §

Passwords, API keys, tokens, private keys, database credentials, and other secrets should not be committed beside normal application configuration.

Secret Manager and workload identity are preferred over embedding credentials in:

  • source code;
  • container images;
  • Terraform variables stored in Git;
  • startup scripts;
  • CI files;
  • shell history.

Logs are security data §

Logs are not only for debugging.

Audit logs, authentication events, firewall decisions, application logs, infrastructure changes, and security findings form the evidence needed to answer what happened.

Security architecture therefore includes:

  • log generation;
  • centralization;
  • access control;
  • retention;
  • alerting;
  • export;
  • preservation.

Production may require stricter controls §

A book example must remain understandable.

A regulated or highly sensitive environment may additionally require:

  • formal privileged access workflows;
  • separate administrative identities;
  • hardware-backed keys;
  • customer-managed encryption;
  • external key management;
  • service perimeters;
  • centralized network inspection;
  • stronger retention;
  • mandatory approvals;
  • change tickets;
  • multi-party controls;
  • dedicated projects;
  • stronger tenant isolation;
  • compliance-specific evidence.

The absence of every possible control from a small example does not mean the control is unnecessary in your environment.

Security is a system property §

No single GCP product makes an architecture secure.

Security comes from the interaction of:

  • identity;
  • authorization;
  • networking;
  • encryption;
  • secrets;
  • software supply chain;
  • configuration;
  • logging;
  • monitoring;
  • deployment;
  • recovery;
  • operational process.

A beautifully hardened GKE cluster connected to an unrestricted deployment identity is still a bad system.

A private database with credentials pasted into a CI variable that everybody can read is still a bad system.

A backup encrypted with a key nobody can recover during an incident is still a bad system.

The book therefore keeps returning to the same question:

What is trusted here, why is it trusted, and what happens when that assumption fails?