Designing Secure Applications on Google Cloud

Implementing data retention and organization policies means structuring Cloud Storage (opens in a new tab) so lifecycle and retention rules apply automatically at scale. Cloud Storage stores data as objects inside buckets, and every bucket belongs to a project that belongs to an organization. Policies set at a higher level flow down to resources below, so separating workloads into different projects and buckets prevents one broad rule from affecting unrelated data.

1.1Buckets and Namespaces as Policy Boundaries

A bucket is the primary boundary where location, storage class, access, and protection are decided for all objects inside it. Location controls where data is stored and how it replicates: regional buckets replicate synchronously across zones in one region, while dual-region and multi-region buckets replicate asynchronously across regions for higher availability. Access is controlled by public access prevention plus Identity and Access Management (IAM), which is recommended over access control lists. Choosing separate buckets, such as a photos bucket and a videos bucket, lets each workload have its own location, storage class, and retention rule.

Prefix-based naming and labels make policies selective inside and across buckets. An object named logs/2026/app-a.json sits under the logs/2026/ prefix, so lifecycle rules and transfer jobs can include or exclude that prefix without scanning every object. Bucket labels such as team: analytics group buckets for cost reporting and ownership without changing the data path. Folders simulate directories, while buckets with hierarchical namespace enabled provide a real file system where a folder can be renamed atomically, and Object Retention Lock (opens in a new tab) must be enabled at bucket creation.

1.2Object Lifecycle Management and Storage Classes

Cloud Storage Object Lifecycle Management is automation that moves or deletes objects when their metadata matches conditions defined on the bucket. Cloud Storage checks the age, creation date, and version state of each object, then runs the transition or deletion only when every condition in the rule is true. This design lets one bucket hold new data in Standard storage while older data flows automatically to cheaper tiers or expires.

1.3Versioning, Holds, and Bucket Lock Retention

Versioning, holds, soft delete, and retention controls decide whether a lifecycle deletion can actually remove data. Object Versioning preserves an overwritten or deleted live object as a noncurrent version that remains accessible until version limits or expiry remove it. Soft delete retains deleted objects for a configured period for recovery, while object holds place a metadata flag on a specific object that blocks deletion or overwrite while the flag is present.

Bucket-level retention enforces Write Once, Read Many protection based on each object's creation time. Any overwrite or delete before the period ends fails, and the bucket cannot be deleted until all objects have fulfilled retention and been removed.

Using security mechanisms that identify vulnerabilities and protect services means combining automated scanning with identity-aware and perimeter controls. Web Security Scanner automatically tests public web applications for flaws, while Identity-Aware Proxy (IAP), Chrome Enterprise Premium, VPC Service Controls, and Cloud Service Mesh control who can reach services. Findings flow from scanners to development teams, and access requests flow from users through IAP and perimeter checks to protected backends.

2.1Automated Scanning of Public Web Applications

Web Security Scanner is a vulnerability detection service for publicly facing applications on App Engine, Compute Engine, and Google Kubernetes Engine (GKE). The scanner sends test traffic from outside the application to its public URLs, so the trust boundary tested is the internet-facing surface. It looks for cross-site scripting (XSS), security misconfigurations, and vulnerable libraries and components.

Scans can be started on demand after a code change, scheduled for repeated coverage, or triggered automatically from a build pipeline through Security Scanner APIs. The order is fixed: code is built and deployed to a reachable test URL, the pipeline triggers the scanner against that URL, and only after the scan completes do findings flow back for triage. Fixed applications must be re-scanned to confirm closure, with high-risk internet-reachable issues fixed first.

2.2Zero-Trust Access with IAP and Context-Aware Controls

Identity-Aware Proxy (IAP) enforces a zero-trust model where no user is trusted by network location alone. Traffic flows from the user to IAP first, and IAP forwards traffic to the application or virtual machine (VM) only after authentication and authorization succeed. Web users must present a valid Google credential and hold the IAP-Secured Web App User role, while SSH users need tunnel permission such as IAP-secured Tunnel User and need no external IP on the VM.

For TCP forwarding, IAP checks authentication, Identity and Access Management (IAM) (opens in a new tab) authorization, optional context-aware access levels, and auditing of connections. Access Context Manager defines levels for network, geography, and device posture, applied either broadly through access bindings or per-resource through IAM conditions on specific VMs. Use access bindings when the same rule must apply uniformly, and use IAM conditions when different VM groups need different rules.

2.3Perimeters, Hardening, and Service Mesh Security

Chrome Enterprise Premium and VPC Service Controls provide complementary user-centric and resource-centric protection. Chrome Enterprise Premium evaluates request context such as IP or certificate for user identities in the organization, while VPC Service Controls defines service perimeters that block access to Google-managed services outside the perimeter for all user and service account identities. Together they reduce the impact of compromised credentials from outside the environment.

Hardening also requires replacing long-lived IAM service account keys with short-lived credentials, requiring OS Login with 2-Step Verification for SSH, and using Cloud Service Mesh mutual TLS (mTLS) so client and server verify each other with certificates. IAP can supply a short-lived RequestContextToken at the mesh edge to reduce token replay inside the mesh.

Responding to vulnerabilities means finding flaws in container images and cloud configurations, ranking them by risk, and blocking risky artifacts before deployment. Artifact Analysis (opens in a new tab) scans images in Artifact Registry, Security Command Center (SCC) centralizes findings across resources, and Binary Authorization blocks deploys that lack required approvals. Scan findings flow back to developers for rebuilds, while SCC findings flow to triage through exports and dashboards.

3.1Image Scanning with Notes and Occurrences

Automatic scanning in Artifact Registry scans a container image on push and continuously monitors its metadata for new vulnerabilities for up to 30 days. The scan extracts system package inventory and compares it against vulnerability sources, so an image clean at push can become flagged later without a new push. On-Demand Scanning instead checks a local image during build before it reaches the registry.

Scan results use notes and occurrences: a note describes a specific vulnerability, while an occurrence is created for each instance of that note on a particular image. Lock files provide the resolved dependency tree so scanners can match exact versions and suggest upgrades. Automatic scanning covers OS packages plus Maven packages in Docker containers, while On-Demand Scanning covers OS, Go, and Java vulnerabilities.

3.2Central Findings and Risk-Based Prioritization in SCC

Security Command Center collects misconfigurations, vulnerabilities, and threats across VMs, containers, and Cloud Run without OS agents. Enabling SCC at the organization level provides near real-time visibility, attack path simulations, posture management, and compliance monitoring. Sources include Security Health Analytics for misconfigurations, Event Threat Detection for log-based threats, Container and VM Threat Detection for runtime attacks, and Web Security Scanner for web issues.

Prioritization depends on the high-value resource set that the organization most needs to protect. Findings that expose those resources receive higher attack exposure scores, and attack paths show how minor issues chain from the internet to high-value compute or billing permissions. Toxic combinations detect grouped risks that together create a path, while chokepoints identify resources where multiple paths converge.

3.3Pipeline Enforcement and Rapid Response

Automated pipelines embed checks so risky artifacts are found early and blocked at deploy time. Cloud Build builds in isolated environments and records provenance, Artifact Analysis scans stored images, Cloud Deploy delivers in sequence with approvals and rollbacks, and Binary Authorization allows only images with required attestations to deploy to GKE and Cloud Run. The chain runs in order: build, scan, attest by a trusted authority, then enforce at deployment.

Tracking depends on exports: findings should be exported through a Pub/Sub topic for automatic triage, with Cloud Asset Inventory feeds for real-time resource changes and Cloud Logging alerts for service errors. After rebuilding with patched base images, updated lock files, or removed dependencies, the new image flows back to Artifact Registry for rescan, and only images that pass policy flow onward.

Storing and rotating secrets and keys means centralizing sensitive data, using short-lived credentials, and controlling encryption keys separately from data. Secret Manager (opens in a new tab) centrally stores certificates and credentials with versioning and API access, Workload Identity Federation replaces long-lived keys with federated tokens, and Cloud Key Management Service (Cloud KMS) holds customer-managed encryption keys. Changes in the central store must synchronize to dependent stores such as MQTT broker certificate stores.

4.1Keyless Authentication with Workload Identity Federation

Workload Identity Federation lets workloads outside Google Cloud call Google Cloud APIs without storing service account keys. The workload exchanges its ambient credential, such as an AWS temporary credential, Azure managed identity token, or GitHub OIDC token, for a short-lived Google token through Security Token Service (STS). Google verifies the outside credential on each exchange before issuing a token that expires quickly.

A workload identity pool provides a view of external identities for IAM, while a workload identity pool provider stores the issuer URL, verification keys, attribute mappings, and conditions for one external provider. Attribute mappings use Common Expression Language to derive google.subject, optional google.groups, and up to 50 custom attributes. Access is granted either directly to the federated principal or by letting the federated principal impersonate a service account that already has access.

1. Obtain external credential: Workload gets its ambient credential from its own platform.
2. Send credential to STS: Workload sends it with the pool provider identifier.
3. Verify and map identity: STS verifies signature and issuer, applies mappings, and checks conditions.
4. Receive federated token: STS returns a short-lived federated token on success.
5. Access Google Cloud: Workload uses the token directly or to impersonate a service account.

4.2Central Secrets and Rotation to Edge Devices

Central storage keeps root and client certificates and credentials in one managed store governed by access policies. Backend workloads retrieve secrets through the Secret Manager API, while devices can receive short-lived tokens for restricted temporary access. Every add, update, and delete in the central store must be reflected in the MQTT broker store, which may be MySQL, PostgresDB, or Java Key Store, through monitoring and synchronization processes.

Distribution uses a direct push during provisioning over encrypted channels and an indirect pull during rotation where devices download when idle. Rotation requires bidirectional connectivity and dedicated MQTT topics, and it completes in order: initialize, acknowledge, request a new certificate, distribute and synchronize to central and broker stores, store and reconnect with the new certificate, confirm completion, then invalidate the old certificate. The old certificate must be invalidated only after the device reconnects and confirms.

4.3Envelope Encryption and Key Lifecycle in Cloud KMS

Envelope encryption keeps the key encryption key (KEK) inside Cloud KMS while protected data lives in the integrated service. With customer-managed encryption keys (CMEK), you create the key ring and key in the same location as the data, grant the service's service account the CryptoKey Encrypter/Decrypter role, select the key in the service settings, and audit Encrypt and Decrypt calls. After configuration, access feels the same as Google default encryption because the service calls KMS for you.

Rotation creates a new key version that the service uses for new encryption while existing data stays protected. Key states move in order from enabled to disabled to scheduled for destruction to destroyed. Disabling makes data temporarily inaccessible but reversible, while destroying makes it permanently unrecoverable. Organization policy can require CMEK with constraints/gcp.restrictNonCmekServices and restrict which projects supply keys.

Authenticating to Google Cloud services means proving workload or user identity with the right credential for each path. Application Default Credentials (ADC) (opens in a new tab) lets the same code find credentials in development and production, token types authorize APIs or prove identity, Auth proxies secure database tunnels, and Identity Platform manages customer sign-in. Short-lived tokens are preferred over long-lived keys in every path.

5.1Programmatic Authentication with ADC

Application Default Credentials is a strategy where authentication libraries automatically find credentials based on the environment. The libraries make those credentials available to Cloud client libraries and API client libraries. ADC cannot authenticate the gcloud CLI itself and cannot use an API key.

ADC searches in fixed order:

1. GOOGLE_APPLICATION_CREDENTIALS environment variable: Path to a JSON file for federation or service account key.
2. Local ADC file: Well-known file created by gcloud auth application-default login.
3. Attached service account: Credentials obtained from the metadata server for the account attached to the resource.

If credentials are found earlier, later sources are not checked. For production on Google Cloud, the attached service account is preferred even though it is checked last, because the platform manages short-lived credentials with no stored key file. Local development uses gcloud auth application-default login, with optional impersonation requiring the Service Account Token Creator role.

5.2Tokens, JWT, and Identity Platform Tenants

OAuth 2.0 access tokens carry authorization with scopes to call an API, sent in the Authorization: TYPE CREDENTIALS header. Configuration depends on authentication endpoint, token endpoint, client ID, secret, and space-separated scopes. OpenID Connect (OIDC) ID tokens are JSON Web Tokens (JWTs) that prove authentication as a service account to a specific audience, so a token for one backend cannot be reused by another. A JWT is built from a header, payload claims, and signature, with only HS256 supported in this configuration.

Identity Platform adds user sign-in with tenants as isolated silos for different customers or business units in one project. Each tenant owns its users, providers, IAM and auditing configuration, quota, and usage breakdown. Tenants support email, social providers, SAML, and OIDC federation, but cannot disable account linking per tenant from the console.

5.3Secure Database Connectivity with Auth Proxies

The Cloud SQL Auth Proxy and AlloyDB Auth Proxy build secure TCP tunnels from applications to database instances without storing passwords. The application connects to the proxy on localhost with a plain connection, and the proxy upgrades it to TLS toward the database using IAM authorization and mutual TLS. AlloyDB Language Connectors embed the same function inside application code. Choose the proxy as a sidecar process such as in GKE, and choose a connector when the driver should embed the connection.

Authorization requires the cloudsql.instances.connect permission, included in Cloud SQL Client, Editor, and Admin roles. The proxy must run as a persistent service with the same uptime as the application, because if the proxy stops all connections through it drop. Private paths keep traffic off the internet through private IP, Private Service Connect, Serverless VPC Access, or VPN and Interconnect, while Workload Identity Federation provides keyless credentials for external workloads to authenticate the proxy.

Securing cloud resources with Identity and Access Management (IAM) (opens in a new tab) roles for service accounts means granting only needed permissions at the narrowest hierarchy level. A service account is a non-human identity for applications, identified by an email such as name@project-id.iam.gserviceaccount.com, that acts as both a principal that can be granted access and a resource that can be impersonated. Where a role is bound decides how far access reaches, because child resources inherit ancestor policies.

6.1Hierarchy and Policy Inheritance

The Google Cloud resource hierarchy flows from organization to folder to project to service-specific resource. The organization is the root, folders separate departments or environments, projects hold workloads, and resources such as instances, buckets, or datasets live inside projects. An allow policy attached to an ancestor is inherited by all descendants below it and cannot be edited from the child view.

The effective allow policy is the union of a resource's own policy plus all ancestor policies. To understand access, administrators must check the resource plus project, folder, and organization policies, using tools such as Policy Analyzer.

6.2Least Privilege and Custom Roles

Least privilege means selecting the smallest role that covers required operations and attaching it at the lowest level that allows the work. Basic Owner, Editor, and Viewer roles grant broad project access and should never be used for production service accounts. Predefined roles grant focused service permissions, while custom roles bundle only listed permissions.

A custom role for identity lifecycle management might include only iam.serviceAccounts.list, create, get, getIamPolicy, setIamPolicy, disable, enable, delete, plus iam.roles.list, get, create, and delete. After creation, the role is granted on the narrowest project or resource so the boundary applies only where needed.

6.3Authentication Choices and Scope Interaction

Workloads authenticate as service accounts through attached identities, short-lived impersonation, federation, or static keys. Attached service accounts let code on a Compute Engine VM request OAuth 2.0 and OIDC tokens from the metadata server with no stored secret. Workload Identity Federation for GKE maps Kubernetes pods to IAM without impersonation, federation for external clouds exchanges IdP identities for short-lived Google credentials, and service account keys sign a JWT for an access token as a last resort.

Requests from a VM must pass both IAM and access scope checks. IAM checks the allow policy while the instance checks its scope, so a narrow scope can block an action the role would permit. Set the VM to the cloud-platform scope and enforce least privilege with IAM roles, and audit with IAM Recommender to remove unused grants and disable then delete abandoned accounts.

Incorporating secure service-to-service communication means keeping traffic on private paths, then authenticating and restricting it by identity. Direct VPC egress and Private Service Connect keep serverless and managed traffic on internal addresses, Cloud Service Mesh (opens in a new tab) adds mutual TLS and authorization, and Kubernetes Network Policies restrict pod-to-pod flows. Together they enforce least privilege at the network edge, pod boundary, and service-identity layer.

7.1Private Paths for Serverless and Managed Services

Direct VPC egress lets Cloud Run, App Engine standard environment, and Cloud Run functions send packets directly to internal IPv4 addresses in a VPC network without a connector. Traffic flows from the serverless environment directly into the selected VPC network and can reach other networks connected to that VPC. Because no connector is created, operational overhead is lower when direct egress is available.

A Serverless VPC Access connector handles traffic when direct egress is not an option. The connector attaches to a VPC network and region, and serverless services use it for outbound traffic that originates from the connector subnet or CIDR range. Both options can reach beyond the selected VPC, but only the connector provides a dedicated subnet-based source for routing and firewall control.

Private Service Connect (PSC) exposes a producer service to a consumer VPC through a private endpoint or load balancer without exposing the entire producer network and without external IPs. Traffic flows from the consumer VPC to the PSC endpoint, then over the PSC connection to the producer service attachment and backend. At Layer 4 PSC uses NAT subnets to support overlapping IPs, while at Layer 7 an internal Application Load Balancer with a URL map selects services. VPC firewall rules around the endpoint restrict which VMs can reach it.

7.2Identity-Based Security in Cloud Service Mesh

Cloud Service Mesh secures microservice communication without code changes by giving each service an identity enforced in the data plane. Zero trust means no traffic is trusted by network location; every call must be authenticated, encrypted, and authorized via Envoy sidecars or proxyless gRPC. Certificates are issued by Certificate Authority Service, with automatic provisioning and rotation.

Mutual TLS (mTLS) provides both peer authentication and encryption, with client and server presenting certificates to each other. Simple TLS has only the server present a certificate, while mTLS has both sides verify each other and encrypts all TCP communication. Auto mTLS is enabled by default: clients send mTLS to workloads with sidecars and plain text to those without, while servers accept both by default and should be migrated to strict mTLS only.

Client TLS policies govern how callers initiate secure sessions, server TLS policies govern what receivers require, and authorization policies decide whether one service may access another based on mTLS identity, namespace, or request claims. Because mTLS certificates bind to the channel rather than passing as bearer tokens, stolen tokens cannot be replayed without private keys. Observability records client mTLS identity plus IP for auditing.

7.3Pod Isolation with Network Policies and Firewall Defense

A NetworkPolicy is a Kubernetes resource that acts as a pod-level firewall for ingress and egress. The policy uses podSelector to choose destination pods and policyTypes to declare Ingress, Egress, or both, with allowed peers defined by pod labels, namespace labels, IP ranges, and ports. For example, a backend-policy can select app: backend pods and allow ingress only from app: frontend pods on TCP 6379, denying all other sources and ports.

By default all pods can communicate freely, and namespaces alone do not block traffic between namespaces. When the first NetworkPolicy is created in a namespace, all traffic of that type not explicitly allowed is denied. To implement zero trust, create a default isolation policy selecting all pods with no allowed ingress, then add narrower allows. Enforcement is built into GKE Dataplane V2 or handled by the Container Network Interface such as Calico.

Use VPC firewalls to limit north-south access to nodes and NetworkPolicy to limit east-west access between pods. Do not replace pod rules with node egress-deny firewalls, which can break NodePort and kubectl exec.

Running services with least privileged access means attaching narrow IAM policies to specific resources, using dedicated service accounts, and replacing long-lived keys with short-lived tokens. An IAM allow policy attached to a single bucket or topic reaches only that resource, while a project-level policy reaches everything in the project. A tight attachment contains compromise, a dedicated identity ties it to one workload, and ephemeral credentialing limits how long access lasts.

8.1Resource-Level Scoping and Guardrails

The Google Cloud hierarchy runs from organization to folders to projects to service resources such as VMs, Pub/Sub topics, buckets, and VPN endpoints. A policy attached to a project grants access across all resources inside it, while a policy attached to a specific bucket or topic grants access only there. Choosing the resource-level attachment keeps the trust boundary tight so a compromised account that reads one bucket cannot move sideways.

The IAM model binds principals such as users, service accounts (opens in a new tab), groups, and Workspace accounts to roles on a resource, and requests flow from principal to resource where the policy is checked. Granular controls further limit reach: tags allow conditional access without separate projects, constraints/iam.automaticIamGrantsForDefaultServiceAccounts blocks automatic Editor grants to default accounts, constraints/iam.allowedPolicyMemberDomains limits which domains can be added, and Principal Access Boundary policies cap maximum principal access.

8.2Dedicated Service Accounts and Tailored Roles

A service account is a non-human workload identity with no password that cannot be used for browser sign-in. Because it is both a principal and a resource, compromise causes harm by the account through privilege escalation and spoofing and harm to the account through key theft and impersonation. Default service accounts created when APIs are enabled may receive Editor on the project for convenience, which lets an attacker move across the entire project if one component is compromised.

Single-purpose user-managed accounts replace broad defaults: create one account per task or VM, grant only needed permissions, attach it directly so code gets short-lived tokens from the metadata server, and manage it with the workload lifecycle from active to disabled to deleted. Choose roles by tightness:

Replace Editor only after modeling impact with Policy Simulator, and avoid granting impersonation at project or folder level where one grant exposes every account.

8.3Workload Identity and Short-Lived Tokens

Workload Identity Federation exchanges an external or Kubernetes identity for short-lived Google credentials through Secure Token Service, so no long-lived Google key is stored outside Google Cloud. Tokens carry principal identity and authorized access type, and because they expire quickly a leaked token is useful only briefly. For regional residency, exchange through a regional STS endpoint such as https://sts.REGION.rep.googleapis.com instead of global https://sts.googleapis.com.

For GKE pods, Workload Identity Federation for GKE maps a Kubernetes service account to an IAM service account with minimum roles, which is most secure because the boundary follows one workload. The node service account is weakly isolated because any pod on the node can use node credentials from the metadata server, while JSON keys mounted as Secrets are strongly discouraged because rotation and revocation are unsafe. On Google Cloud, attach the service account to the compute resource and use Application Default Credentials to obtain tokens automatically.

Securing application artifacts using Binary Authorization (opens in a new tab) means allowing only container images with signed proof of required checks to deploy. Artifact Analysis scans images and stores vulnerability results, an attestor verifies that a required process completed, and an attestation is the signed statement proving approval for a specific image digest. The enforcer verifies signatures at deploy time for GKE, Cloud Run, and Google Distributed Cloud.

9.1Vulnerability Gates and Deploy-Time Enforcement

Artifact Analysis supplies vulnerability information when an image is pushed to Artifact Registry, plus On-Demand Scanning from local or Cloud Build steps. A typical gate approves an image only when severity is at or below Medium, source and build service are trusted, and artifacts come from a trusted repository. If findings do not apply, they can be allowlisted so attestation can still be issued. If the image meets criteria, a trusted authority creates a vulnerability attestation for that exact registry path and digest.

Binary Authorization enforces the gate by requiring that attestation instead of rescanning the image. Each promotion stage from build to development to QA to canary to production can have its own environment and policy, and an image moves forward only after required attestations verify for that environment. Pre-deployment checks can also block images not on the exempt list.

1. Build and unit testing: Image is built and scanned.
2. Development deployment: Image deploys where users are not affected.
3. QA deployment: Image deploys where only internal users are affected.
4. Canary deployment: Image deploys to a fraction of external users.
5. Production deployment: Image deploys broadly after prior stages pass.

9.2Attestors, Notes, and Cryptographic Verification

An attestor is the trusted verification authority, often a build or test system, that holds the public key used for verification. An Artifact Analysis note is the trusted metadata record backing the attestor, created through the global API endpoint because regional endpoints are not supported. In a multi-project setup, the deployer project owns the cluster and service agent, the attestor project centrally stores attestors and notes, and the attestation project stores readiness statements.

Setup requires creating the note and attestor together, granting the deployer service account the Attestors Verifier role, granting viewer access on note occurrences, and registering a public key. The recommended algorithm is Elliptic Curve Digital Signature Algorithm (ECDSA) such as ec-sign-p256-sha256, with private keys kept in Cloud KMS. The private key signs the image digest to create the attestation, and the public key in the attestor verifies it. Because attestation binds to the immutable digest, changing image contents requires a new attestation.

The end-to-end flow runs in order: define policy naming trusted attestors, generate keys, sign the digest with the private key, store the attestation in the registry and Artifact Analysis, register the public key, request Pod deployment, then verify and move the request to allowed or blocked.

9.3Policy Modes, Scope, and Emergency Handling

The project-singleton policy holds deployment rules for a project, while each cluster opts in through its evaluation mode. Before enforcement, the cluster must be registered with a fleet, the Binary Authorization API must be enabled, and the binauthz-system/binauthz-agent service account must hold the Policy Evaluator role.

Emergency bypass through breakglass or exempt images lets urgent fixes ship without satisfying normal rules, but the request still flows through the enforcer so it is logged. Enforcement blocks non-compliant deploys and writes reasons to Cloud Audit Logs, while continuous validation lets running pods continue but logs non-conformance to Cloud Logging when policy changes after deployment.

Key Facts

• Cloud Storage lifecycle rules live on the bucket and run an action only when every condition on age, date, and version state is true, while Bucket Lock and Object Retention Lock block deletion until retention expires.
• Identity-Aware Proxy (IAP) forwards traffic to a web app or VM only after verifying Google identity and IAM permission, with no external IP needed for IAP-based SSH.
• Artifact Analysis scans images on push to Artifact Registry and monitors them for 30 days, while Binary Authorization blocks deployment when required attestations are missing.
• Application Default Credentials searches in order: GOOGLE_APPLICATION_CREDENTIALS file, local ADC file, then attached service account via metadata server, with the attached account preferred for production.
• A Kubernetes NetworkPolicy uses podSelector and policyTypes to control ingress and egress, and creating the first policy in a namespace denies all traffic of that type that is not explicitly allowed.