Restricting Data Services, Secret Manager and Instance Metadata

What it is

Data loss often happens through ordinary access paths: a bucket made public, a table shared too widely, a database open to the internet, or a password in a startup script. This page covers the controls on each data service, Secret Manager for credentials, and the metadata server every VM can query.

How it works

BigQuery

CREATE ROW ACCESS POLICY emea_only
ON sales.orders
GRANT TO ('group:emea-analysts@example.com')
FILTER USING (region = 'EMEA');

Cloud Storage

• Uniform bucket-level access so only IAM applies, with IAM conditions on object name prefixes when needed.
• Public access prevention on buckets, or enforced with the storage.publicAccessPrevention organization policy.
• Signed URLs for time-limited access by someone without a Google identity.
• Retention policies, object holds and soft delete to protect against deletion.

Cloud SQL

For every data service, a VPC Service Controls perimeter stops data being copied out even by users with valid credentials.

Secret Manager

Secret Manager stores API keys, passwords and certificates as secrets, each with numbered versions.

gcloud secrets create db-password \
  --replication-policy=user-managed --locations=europe-west1,europe-west4

printf 's3cr3t-value' | gcloud secrets versions add db-password --data-file=-

gcloud secrets add-iam-policy-binding db-password \
  --member="serviceAccount:app-backend@prod-app.iam.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"

Grant Secret Accessor on the individual secret to the workload's service account. Cloud Run and GKE can mount secrets directly, so code never stores them.

Protecting compute instance metadata

Every VM can query the metadata server at metadata.google.internal (169.254.169.254) with the header Metadata-Flavor: Google. It returns instance details, startup scripts, custom metadata and access tokens for the attached service account.

OS Login ties SSH access to IAM roles (OS Login and OS Admin Login) and supports 2-Step Verification, so leavers lose access when their account is suspended.

A worked example

A review finds a database password in a VM startup script, project-wide SSH keys, and a Cloud SQL instance with a public IP. The engineer moves the password into Secret Manager with Secret Accessor for the VM's service account only, and the startup script reads it at boot.

OS Login is enforced by organization policy, and project-wide SSH keys are removed. The Cloud SQL instance moves to private IP, and sql.restrictPublicIp prevents a repeat.

How the exam asks about this

• "Analysts in each country may see only rows for their country in one shared table." BigQuery row-level access policies.
• "Only the HR group may see salary values; others may query the table but see the column masked." Policy tags with dynamic data masking.
• "Developers must not be able to add their own SSH keys to production VMs." Enforce OS Login and control access with IAM roles instead of metadata keys.