Google Cloud Security: Identity, Secrets, Policy, and Evidence

Cloud Security Model

Google protects the underlying cloud infrastructure; customers configure identities, policies, networks, data controls, workloads, and monitoring. A secure design limits each path and preserves evidence when a control blocks or permits an action.

Project structure, group-based access, dedicated service accounts, managed secrets, organization constraints, encryption choices, audit coverage, and incident response work together. No single product replaces that operating model.

Privilege and Credentials

Grant workforce access through managed groups, separate administration from normal development, and use temporary elevation for rare privileged work. Review high-level organization and folder bindings because their inheritance reaches many projects.

Workloads should obtain short-lived tokens from attached identities or federation. Detect and remove unused service account keys; rotating a downloaded secret does not solve the distribution problem that created it.

Secret and Key Ownership

Secret Manager stores versioned secret values and evaluates IAM at access time. Applications should fetch only the named secrets they require and tolerate a staged rotation where old and new credentials overlap briefly.

Google-managed encryption is sufficient for many workloads. Customer-managed keys add control and separation duties, but disabling, destroying, or denying a key can make dependent data unavailable. Key lifecycle and recovery therefore need strict procedures.

Create a secret without exposing its value in an argument

read -s DB_PASSWORD
printf %s "$DB_PASSWORD" | gcloud secrets create db-password \
  --project=tl-cloud-lab \
  --replication-policy=automatic \
  --data-file=-
unset DB_PASSWORD

gcloud secrets versions list db-password --project=tl-cloud-lab

A shell variable still exists in process memory; use an approved secret injection path for production automation.
Grant access to the runtime identity at the secret resource.

Policy Guardrails

Organization Policy can constrain allowed configurations such as resource locations or key creation. Test constraints in a lower environment and understand inherited behavior before enforcing them broadly.

Admin Activity audit logs record many administrative actions, while Data Access logging has service-specific defaults and potential volume. Route critical evidence to protected storage with appropriate retention and restricted deletion rights.

Threat and Trust Boundaries

Begin with assets, actors, entry points, data flows, trust boundaries, privileged operations, and plausible misuse. For each path, identify authentication, authorization, network exposure, data protection, validation, logging, and recovery. Shared responsibility means Google secures the underlying cloud according to the service, while the customer still owns identities, configuration, code, data classification, and many workload controls.

Separate workforce identity, workload identity, customer identity, and service-agent behavior. A user who may deploy code should not automatically read production data; a workload that reads one bucket should not administer IAM; a security analyst may need logs without resource mutation. Use projects, folders, groups, service accounts, VPC controls, encryption keys, and data boundaries to express these duties.

Model compromise rather than only mistakes. Ask what an attacker can do with a developer session, CI identity, runtime service account, leaked signed URL, exposed API key, malicious container, or organization administrator. Limit lateral movement, detect unusual use, and preserve a recovery path outside the compromised boundary.

Record assets and abuse cases before selecting controls.
Separate deployment, runtime, data, network, and audit privileges.
Test controls from an unauthorized principal and network path.
Update the threat model after architecture or data changes.

Secrets and Encryption Keys

Secret Manager stores versioned secret values and supports IAM, replication choices, rotation workflows, and audit logging. Grant the runtime access to only the required secrets, while a different administrative identity creates or rotates versions. Reference a pinned version when a controlled rollout matters or `latest` when consumers are designed and tested for immediate rotation.

Cloud KMS manages cryptographic keys, and customer-managed encryption keys add customer control to supported service encryption. That control also creates availability and deletion risk: disabling, destroying, or denying a key can make protected data unavailable. Separate key administration from key use, protect key projects, set rotation based on threat and compliance, and test service behavior during key permission failure.

Rotation is complete only after producers issue new material, every consumer reloads it, old use stops, and the previous version is disabled or destroyed according to policy. Inventory consumers before rotation, monitor version access, and keep an emergency rollback window when safe. Never log secret values or place them in image layers, source, build arguments, or plain deployment output.

Use separate identities for secret administration and access.
Alert on unusual secret reads and key-policy changes.
Rehearse rotation without restarting every service blindly.
Document the impact of key disablement before enabling CMEK.

Policy and Data Perimeters

Organization Policy constraints limit resource configuration across the hierarchy, while IAM controls who may perform actions. Roll out constraints in dry-run or test folders where supported, inspect violations, document exceptions, and enforce progressively. An exception needs scope, owner, business reason, compensating control, evidence, expiration, and review trigger rather than a permanent undocumented exclusion.

VPC Service Controls create service perimeters that reduce data-exfiltration paths for supported Google services. A perimeter is not a firewall and does not replace IAM. Design ingress and egress rules from exact principals, projects, services, and access levels; test developer tools, CI, managed service agents, and cross-project data flows before enforcement. Monitor denied requests and distinguish attacks from missing architecture.

Sensitive Data Protection can discover and classify supported sensitive data patterns, but classification still needs business context and remediation ownership. Apply retention minimization, tokenization or masking, row or column controls, and controlled exports according to use. Encryption protects bytes, while authorization and output controls govern who can obtain plaintext.

Pilot hierarchy-wide constraints before broad enforcement.
Keep perimeter exceptions narrow and time-bound.
Classify exported and backup data as well as primary stores.
Review policy denials as both security and reliability signals.

Detection, Response, and Recovery

Security Command Center aggregates findings from Google Cloud services and integrated sources according to tier and configuration. A finding is an investigative lead, not proof of impact. Route high-confidence findings to an owned workflow, enrich them with asset, identity, exposure, data sensitivity, and recent changes, then prioritize by reachable business risk.

Centralize Admin Activity, required Data Access, Policy Denied, network, application, and identity evidence with protected retention. Alert on new service-account keys, broad IAM grants, disabled logging, public exposure, secret access anomalies, destructive operations, and defense changes. Tune with documented rationale; silently suppressing a noisy rule can remove the only signal of compromise.

An incident plan should isolate identities and workloads, preserve evidence, rotate credentials, remove persistence, restore trusted artifacts and data, verify controls, and communicate. Test recovery from a compromised project or administrator, not only an application crash. Maintain a break-glass path protected by strong authentication, limited eligibility, monitoring, and immediate review after use.

Assign severity from exploitability, asset value, and evidence.
Preserve logs outside ordinary workload administration.
Rebuild from trusted artifacts after compromise.
Exercise credential revocation and emergency access.

Exception and Control Evidence

Security exceptions should live in a governed record tied to the exact resource and control. Capture the risk, business reason, approving owner, affected data, threat path, compensating control, validation evidence, start date, expiration, and event that forces earlier review. A broad firewall rule or Policy exemption without this context becomes invisible permanent architecture.

Test the compensating control from the attacker's position. An alert is useful only if the action is logged, routed, investigated, and contained within the accepted risk window. A private endpoint mitigates only the paths it actually removes. Attach reproducible evidence rather than a screenshot with no principal, timestamp, or query.

Notify owners before expiration and choose remediation, retirement, or a newly reviewed exception. Do not auto-renew because the original project is still busy. Preserve expired records for audit and incident context, and verify that removal of the exception restores the intended policy.

Review exceptions as a portfolio to find repeated control friction. Many waivers for the same service or deployment path can indicate an impractical baseline, missing platform capability, or training gap. Fix the systemic cause without weakening unrelated workloads, and migrate existing exceptions through a measured plan rather than closing records administratively.

Give each exception one accountable owner.
Validate compensating controls against the named threat.
Require expiry and policy-restoration evidence.
Report recurring exceptions as architecture debt.
Escalate overdue exceptions to the accountable risk owner.
Verify exception closure from the formerly allowed path.
Preserve closure evidence with the original risk decision.
Notify detection owners when an exception ends.

Security Control Examples

Respond to a Leaked Service-Account Key

A repository scan finds a service-account key committed to source control.

Respond to a Leaked Service-Account Key

Constraints: Deleting the file does not revoke the key and evidence must be retained.
Decision: Disable and delete the key, inspect audit logs, rotate affected secrets, migrate the workload to federation, and purge repository history.
Verification: The old credential is rejected, the workload uses short-lived credentials, and the incident scope is documented.
Failure test: Attempt a harmless token exchange with the revoked key and confirm denial is logged.

Output

Expected evidence: The old credential is rejected, the workload uses short-lived credentials, and the incident scope is documented.

This is a worked engineering decision, so the result is operational evidence rather than terminal output.

Before you move on