GCP

How IAM Evaluates, and Why Access Is Hard to Read Back

Allow policies attach at the organization, folder, project, and individual resource level, and they combine additively down the hierarchy. A role granted at the folder cannot be taken back by a policy on a project inside it. The only subtractive mechanism is a deny policy, which is evaluated before allow policies and blocks a named permission for a named principal regardless of what granted it. The practical consequence is that a resource's own policy tells you almost nothing about who can reach it.

That is what makes access hard to read back. Who can read a given bucket is a question for Policy Analyzer or the Policy Troubleshooter running against the whole hierarchy, not for the bucket's own policy page. Policy changes are also eventually consistent, so a grant that was just made can return 403 on the next call and succeed a minute later, which is worth knowing before you start debugging the application instead.

• Basic roles are the first thing to look for. Owner, Editor, and Viewer predate the granular roles and span every service in the project, so an Editor grant made early to keep things moving is usually still there, and it covers far more than whoever granted it intended.
• Service account keys are long-lived credentials sitting in a file, and rotating them does not change that; Workload Identity Federation removes the key instead.
• Impersonation is the alternative to granting a person a role outright. Grant Service Account Token Creator on a service account that holds the role, and that person's access becomes a short-lived token that appears in audit logs as an impersonation event.
• The Compute Engine default service account is granted Editor on the project by default, so anything running as it inherits that reach. An organization policy constraint turns off the automatic grant, and setting it before the first workload is much easier than unpicking it after.
• Custom roles do not track their source. Permissions Google later adds to a predefined role do not appear in the custom role you copied from it, so a copied role falls quietly behind as the service changes.

IP Planning and the Default Network

Every new project arrives with a default VPC in auto mode: one subnet in every region, drawn from the same fixed block at 10.128.0.0/9. Auto mode hands out those same ranges in every project it is created in, which is why an estate assembled from default networks tends to overlap with itself. Overlapping ranges cannot be peered, so the discovery usually lands the day two systems built independently are asked to talk to each other.

Address planning also has to account for how quickly Kubernetes consumes space. With alias IP ranges, each GKE node takes a slice of the pod range, a /24 by default for the standard limit of 110 pods per node, and Services come out of a second secondary range. A cluster given a /22 for pods runs out of node capacity long before it runs out of CPU, and the primary pod range is fixed at cluster creation: growing past it means attaching an additional range or rebuilding, not editing the original. Private Service Access, which is how Cloud SQL and Memorystore get private addresses, needs its own allocated block that overlaps nothing else.

• Converting a network from auto mode to custom mode is one way. Custom mode is what you want for anything long-lived, because the subnets are yours to place.
• VPC Network Peering is not transitive and does not re-advertise routes learned from another peer. A hub project peered to two spokes does not connect the spokes to each other; that needs Network Connectivity Center or a routing appliance in the middle.
• Instances without external addresses reach Google APIs through Private Google Access, and reach the public internet, including package registries, only through Cloud NAT. A private GKE node that cannot pull an image is usually missing one of the two.
• Shared VPC keeps subnets in a host project while workloads run in attached service projects, so addresses come out of one plan instead of one plan per team.

The Cloud Run Settings That Decide Behavior

Four settings do most of the work in a Cloud Run service, and concurrency is the one that catches people. A container instance accepts up to 80 requests at once by default, which means the code inside has to be safe to run concurrently. A per-request buffer that stacks, a library that is not thread safe, or an in-process cache written as though it belonged to one request will pass testing and fail under load, and the failure does not present as a deploy error.

CPU allocation is the second. By default CPU is throttled outside the handling of a request, so anything the container tries to do after the response goes out, flushing telemetry, writing an audit record, running a timer, is unreliable and may resume much later inside an unrelated request. Setting CPU to always allocated fixes that behavior and moves the service to instance-based billing, which is the point at which idle time starts to cost.

• Minimum instances above zero keeps containers warm and removes cold starts on the first request. Idle instances bill at a lower rate, so the trade is a fixed floor against startup latency.
• The request timeout defaults to 5 minutes and can be raised to 60. Work that needs longer is not a request: it belongs in a Cloud Run job or a queue-driven worker.
• Maximum instances is the blast radius on both a traffic spike and the bill.

Connection Counts Between Cloud Run and Cloud SQL

Horizontal scaling and a connection-per-process database meet badly. Each Cloud Run instance opens its own pool, and PostgreSQL allocates a backend process per connection, so a pool of ten in each of a hundred instances is a thousand connections against an instance whose max_connections is tied to its size. Passing that limit does not degrade gradually, it refuses: new connections get 'sorry, too many clients already', and they get it during the traffic spike that caused the scale-out in the first place.

The arithmetic is most of the fix. Keep per-instance pools in single digits, choose maximum instances with max_connections in view rather than in isolation, and put a server-side pooler in front of anything with a high ceiling. Pooling in transaction mode carries a cost worth knowing in advance: session-scoped behavior stops working, so advisory locks held across statements, LISTEN and NOTIFY, and session-level SET commands need rethinking before the pooler goes in, not after.

• The Cloud SQL Auth Proxy and the language connectors authenticate with IAM and wrap the connection in TLS, so clients do not need an authorized network entry per source address.
• Reaching a private IP instance from Cloud Run requires Direct VPC egress or a Serverless VPC Access connector. Neither is needed on the public path, but that path leaves the instance's public endpoint reachable and puts the whole weight of access control on the connector's authentication.
• A read on the request path does not belong in BigQuery. Query latency there has a floor measured in hundreds of milliseconds even against a small table, which is fine behind a dashboard and wrong in front of a user who is waiting.