9.1 Private Communication, Key Rotation, and Vulnerability Response

Private Communication, Keys, and Vulnerability Response

Application security is a collection of independent boundaries. A network route can make an endpoint reachable without granting permission to invoke it. An identity token can prove who called without proving which customer's record may be read. Encryption can protect traffic without making vulnerable application code safe. Exam scenarios often become clear when each boundary is named separately.

End-User Identity and Workload Identity

Identity Platform supports application user authentication and identity-provider integration. The backend validates a user token's signature, issuer, audience and expiry using a supported verification library. It then authorizes access to tenant-specific resources in application logic. A signed token containing a user ID does not automatically establish an IAM role on Google Cloud or grant access to another user's order.

A Cloud Run service identity or GKE federated workload principal serves a different purpose: it authorizes the backend's calls to Cloud Storage, databases and other Google APIs. Grant the backend only the required resource roles. The user-facing application must still enforce its own access rules because a powerful server identity can read records that an individual user should not see. Do not forward a user ID string as if it were a verified identity token.

Private Networking and Service Authentication

Direct VPC egress gives Cloud Run an outbound VPC path. It does not change inbound IAM, make another service public, or create a route across every peering. For a private datastore, verify the selected network/subnet, route, firewall rules, DNS and service-specific connection mechanism. Private Service Connect and private services access have different provisioning and reachability models; use the datastore's supported design rather than treating both as interchangeable labels.

On GKE, namespaces organize resources and scope some authorization, but do not automatically isolate traffic. A NetworkPolicy selects Pods and permits specified ingress/egress connections when the cluster's enforcement implementation supports it. For a default-deny design, explicitly allow required DNS, metadata/token access and backing-service paths as appropriate. Test both an allowed caller and a denied caller; an untested policy can silently block the application's credential flow.

Cloud Service Mesh can provide workload-to-workload mutual TLS and policy-controlled communication. Certificates authenticate peers and encrypt transport; authorization policies determine which authenticated workload may call another. Certificate issuance, trust roots and renewal are managed/configured through the chosen mesh. A namespace name or encrypted connection alone is insufficient proof of business authorization. For custom TLS integrations, verify trust, hostname/identity and expiry rather than disabling certificate checks to make a connection succeed.

Secrets and Encryption Keys Have Different Lifecycles

Secret Manager stores secret values and immutable versions, such as an external API password. Its rotation schedule can notify a Pub/Sub topic; application automation must actually create the new credential, update the external system, publish the version and verify client adoption. A rotation notification is not proof that the database password changed. Keep a controlled overlap/rollback period and retire old values only after clients have transitioned.

Cloud KMS manages cryptographic keys and key versions. Rotating a symmetric encryption key selects a new primary version for future encryption; existing ciphertext still depends on the version used to encrypt it. Rotation does not automatically re-encrypt every stored value, disable old versions or delete them. Test decryption and inventory dependencies before destroying a version, because destruction of required key material can make data unrecoverable. Asymmetric signing-key rotation also requires distributing the new public verification key and updating trust; KMS does not automatically rotate asymmetric keys on the same schedule mechanism.

For envelope encryption, an application can encrypt data with a data-encryption key and wrap that key with KMS. Rewrapping and re-encrypting payloads are different operations with different cost and migration implications. Prefer established client libraries/service integrations to hand-written cryptographic protocols. Separate the principal administering keys from the principal allowed to decrypt when the access model requires that distinction.

Resolve Vulnerabilities Through the Artifact Lifecycle

Web Security Scanner can identify supported web-application weaknesses, while Artifact Analysis reports vulnerabilities in supported container/package contents. Security Command Center aggregates findings from configured sources and tiers. These tools are complementary: a clean dependency scan does not establish that an authorization check is correct, and an open network path is not itself a software-package CVE.

Start triage with the affected resource, artifact digest, package/version, severity, exploitability and exposure. Confirm whether the vulnerable artifact is actually deployed. A mutable tag can point to a new image while older running Pods still execute a previous digest. Prioritize exploitable internet-facing findings, but document any exception and expiry rather than silently treating a severity threshold as a complete risk assessment.

Remediation normally means updating the dependency or base image, rebuilding from reviewed source, running tests, rescanning, and releasing the new immutable digest. Review scan errors or unavailable results explicitly; absence of a successful scan is not a clean result. Binary Authorization can require a trusted attestation before deployment, but only if the pipeline creates that attestation after the intended checks and the admission policy requires it.

After rollout, verify the live workload's digest and service behavior, then confirm the finding's current status. Keep the previous safe rollback artifact where appropriate, recognizing that rolling back to a known vulnerable digest may reintroduce the issue. Audit emergency exceptions and check them after the incident. This closes the loop from detection to an observable repair rather than stopping when a dashboard row is marked acknowledged.

Sources checked October 18, 2026: KMS rotation, GKE network policy, Identity Platform documentation, Security Command Center documentation.

Retention, Location, and Organization Policies

At design time, identify the applicable retention and residency requirements before creating storage, backups, logs and build artifacts. Resource-location organization constraints can restrict supported resource creation, but do not automatically move existing data or cover every service path. Public-access prevention and uniform bucket-level access address different Cloud Storage access-control concerns. Check the documented constraint scope and exceptions; a policy display name is not proof of retroactive enforcement.

Distinguish Object Lifecycle Management from retention. Lifecycle rules schedule transitions/deletion under supported conditions, while a retention policy prevents deletion before the required time. A locked retention policy cannot be shortened or removed, so test the intended policy on disposable resources before locking production data. Backups, replication, soft delete and versioning serve different recovery needs and do not replace a required retention control. Verify the location of replicated copies and exported logs independently of the application region.