Professional Cloud Network Engineer
Secure Web Proxy architectures in Google Cloud give administrators centralized control over internet egress traffic by inspecting, filtering, and securing outbound connections from cloud workloads. These architectures support explicit proxy configurations, transparent proxying, and integration with Google Cloud’s security services to enforce compliance and protect against threats. The choice of deployment model depends on whether clients must be individually configured or can derive proxy settings automatically.
Explicit proxy configurations require client applications to be directly configured with the proxy server’s hostname, port, and optional authentication credentials. In Google Cloud, this is done using environment variables such as HTTPS_PROXY, HTTP_PROXY, and NO_PROXY, or through application-level properties like https.proxyHost and https.proxyPort for Java client libraries. When authentication is needed, credentials can be supplied via custom HttpTransportFactory implementations or secure credential providers that avoid storing secrets in logs. The gcloud CLI supports explicit proxy configuration through properties set with gcloud config set proxy/type, proxy/address, and proxy/port, and authentication credentials are optionally set using environment variables CLOUDSDK_PROXY_USERNAME and CLOUDSDK_PROXY_PASSWORD to prevent credential exposure.
Proxy auto-configuration (PAC) files define dynamic proxy routing rules based on URL patterns, allowing centralized control without configuring each client individually. Google Cloud services typically use a JSON-based proxy configuration file that specifies httpProxy, httpsProxy, and noProxy fields. The noProxy list accepts IP addresses, CIDR ranges, domain names, and the asterisk character to bypass the proxy for specific destinations; domain names prefixed by a dot (such as .google.com) tell the proxy that all subdomains should also bypass it. Notably, the httpProxy and httpsProxy fields do not accept https:// prefixes—even when the proxy server uses HTTPS, the URL must start with http://, because requests to port 443 automatically use HTTPS encryption.
Google Kubernetes Engine (GKE) and related services support proxy configurations at the cluster level to control egress from containerized workloads. For GKE on AWS, the proxy configuration is stored as a JSON string in AWS Secrets Manager and referenced during cluster creation using the --proxy-secret-arn and --proxy-secret-version-id flags, routing control plane and node pool traffic through the proxy. GKE attached clusters use a similar approach where the configuration is stored as a Kubernetes Secret and referenced during cluster registration or update. Google Distributed Cloud (formerly Anthos) supports proxy configuration through its cluster configuration file using the proxy.url and proxy.noProxy fields, and additional configuration is required for GKE Identity Service when using OIDC authentication behind a proxy.
When deploying proxy architectures, VPC endpoints provide private connectivity to AWS services without requiring public internet access, which is critical for GKE on AWS environments that must route traffic through a proxy while maintaining security boundaries. Required VPC endpoints include interface endpoints for services such as Auto Scaling, EC2, EFS, Load Balancing, Key Management Service, Secrets Manager, and Security Token Service, plus a gateway endpoint for S3. Security groups must allow outbound traffic from control plane and node pool security groups to the proxy server address and port. The proxy allowlist must include domains like .gcr.io, container.googleapis.com, gkeconnect.googleapis.com, oauth2.googleapis.com, and regional variants to ensure connectivity to Google Cloud services.
In environments where direct connectivity to Certificate Authority (CA) services is blocked, Cloud Service Mesh can be configured to route CA traffic through an explicit CONNECT-based HTTPS proxy. This is done by deploying an Istio ProxyConfig custom resource that sets the CA_PLUGIN_PROXY_URL environment variable in sidecar proxies. The sidecar establishes a CONNECT handshake with the proxy, which then forwards CA-destined traffic to endpoints like meshca.googleapis.com and privateca.googleapis.com. The ProxyConfig must be applied to the cluster before restarting workloads in service mesh-labeled namespaces, allowing pods to obtain signed workload certificates from the CA.
Proper firewall configuration is essential: rules must allow traffic from cluster nodes to Google Cloud service endpoints through the proxy server. For Google Distributed Cloud, firewall rules must permit outbound traffic from cluster node IP addresses on source ports 1024-65535 to endpoints including cloudresourcemanager.googleapis.com, gkeconnect.googleapis.com, gkehub.googleapis.com, oauth2.googleapis.com, logging.googleapis.com, monitoring.googleapis.com, and storage.googleapis.com on port 443. The proxy server itself must be allowlisted for all required Google Cloud domains. Additionally, the noProxy list should include the VPC IP range and internal service domains to prevent routing loops for internal traffic.
Integrating and managing proxy operations involves configuring proxy services to control, inspect, and secure internet egress traffic from cloud environments. This includes setting up forward proxies for outbound connections, integrating them with other cloud security services, and managing their configuration and lifecycle to enforce security policies and ensure compliance.
Secure Web Proxy is a managed Google Cloud service that acts as a forward proxy to inspect and control egress traffic from your VPC network to the internet. To configure it, you first create a Secure Web Proxy resource that defines the proxy endpoint. You must then create a Target HTTPS Proxy (for HTTPS traffic) or a Target HTTP Proxy (for HTTP traffic) that references a URL map and an SSL certificate. The target proxy terminates the TLS connection from clients for inspection. The traffic flow begins with a client inside your VPC; the request is routed to the Secure Web Proxy based on firewall rules and route configurations. The proxy then forwards traffic to the internet, applying any configured security and access policies. For services like Apigee, proxy configuration involves uploading a proxy bundle (a ZIP file) to the runtime environment using the Apigee API and deploying it to a specific environment; the deployment makes the proxy active and ready to accept traffic.
Proxy configuration is typically defined in a structured file (JSON or YAML) that specifies the httpProxy, httpsProxy, and noProxy settings. Both httpProxy and httpsProxy fields must use the http:// scheme even when connecting to a proxy server over HTTPS; they define the proxy server’s hostname, port, and optional authentication credentials. The noProxy field is a comma-separated list of destinations (IPs, CIDR ranges, or domains) that should bypass the proxy; it is critical to include internal service domains like kubernetes.default.svc.cluster.local and the VPC IP range to prevent routing loops. This configuration file is stored as a secret in a service like AWS Secrets Manager or as a Kubernetes Secret, and its ARN or name is referenced when creating or updating cloud resources. Integrating a proxy with services like GKE on AWS, GKE attached clusters, or Cloud Service Mesh requires granting the service’s IAM roles (such as the control plane and node pool roles) permission to read the proxy secret (e.g., secretsmanager:GetSecretValue). The service then injects this configuration into its components.
When managing proxy operations, you must ensure cloud workloads have network connectivity to the proxy server’s IP and port. This often requires configuring VPC firewall rules or security groups to allow egress traffic from the workload subnet to the proxy. The proxy server itself must be configured to allow traffic to necessary Google Cloud service domains (e.g., *.googleapis.com, gcr.io). If TLS inspection is enabled on the Secure Web Proxy, additional services like Certificate Authority Service (privateca.googleapis.com) must be included in the service perimeter if using VPC Service Controls, because the proxy needs to generate and sign certificates. Lifecycle management involves updating the secret when proxy details change and then updating the dependent cloud resources. For a GKE on AWS cluster, use the gcloud container aws clusters update command with the new --proxy-secret-arn and --proxy-secret-version-id. The IAM policy for the control plane and node pool roles must be updated to include the new secret ARN before updating the cluster, or the operation fails. Removing proxy configuration involves updating the resource to point to an empty configuration or a secret that bypasses proxying.
Proxy security and access policies control how network traffic exits a cloud environment and enforce boundaries between internal workloads and external services. Administrators configure these policies to inspect encrypted sessions, restrict outbound traffic to approved domains using URL filtering, and enforce identity constraints on incoming connections. Combining transport layer controls, certificate validation mecanisms, and identity-aware proxies creates a layered defense for cloud resources.
Transport Layer Security (TLS) inspection allows a proxy to act as an intercepting intermediary to decrypt, inspect, and re-encrypt outbound traffic. For TLS inspection to work, client workloads must trust the organization’s private root certificate authority (CA) and must send the Server Name Indication (SNI) extension during the TLS handshake. The proxy does not support Encrypted Client Hello (ECH)—formerly Encrypted SNI—because it cannot access the pre-established server keys required to decrypt initial handshake parameters. Servers using private or self-signed certificates cannot be intercepted, and the proxy does not perform certificate revocation list (CRL) checks. Managing certificates requires understanding CA caching: the Network Security Service Agent generates intermediate CAs using a designated private CA pool to issue leaf certificates dynamically. If an administrator removes a CA from the private CA pool, the proxy continues serving cached certificates signed by that CA for up to 28 hours. To immediately stop using cached certificates, administrators must update the regional TLS inspection policy to target a completely new CA pool, forcing the proxy to generate fresh certificates.
URL filtering enables organizations to allow or block egress traffic to specific domains at Layer 7. To apply URL filtering across a VPC network, administrators create security profiles and group them into a security profile group. A regional or global firewall policy then applies this group to outbound traffic by configuring policy rules with the apply_security_profile_group action. The firewall policy must be associated with the same VPC network where the inspected workloads reside, routing traffic through dedicated zonal firewall endpoints that handle Layer 7 processing and optional TLS inspection. The flow is: workload egress traffic enters the VPC network, is matched by the firewall policy rule, and is redirected to a firewall endpoint which performs TLS inspection and URL filtering before forwarding to the destination.
Identity-Aware Proxy (IAP) provides principal-based access control and device validation for web applications without requiring traditional VPN connections. When implementing certificate-based access (CBA), administrators create custom access levels in Access Context Manager to authenticate incoming device certificates. If using Certificate Manager trust configurations, the access level condition validates the certificate path using the expression certIsPkiAttested(origin, ["certificatemanager.googleapis.com/projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME"]) == true. For devices that use self-signed certificates managed via Endpoint Verification, the access level uses the expression certificateBindingState(origin, device) == CertificateBindingState.CERT_MATCHES_EXISTING_DEVICE. Once created, the access level is attached directly to the target application resource settings within IAP. Target HTTPS proxies terminate the client mTLS connection using SSL certificates whose lifecycle states must reach ACTIVE before successfully serving requests.
Client workloads route their egress connections through an HTTP forward proxy by defining specific proxy environment variables and configurations. A standard proxy configuration file requires three core parameters: httpProxy, httpsProxy, and noProxy. Both httpProxy and httpsProxy fields require the http:// prefix rather than https://, even when forwarding traffic targeted for secure port 443. The noProxy attribute accepts a comma-separated list of IP addresses, CIDR ranges, and domain names to bypass the proxy, where a leading dot like .google.com mandates subdomain matching, and an asterisk wildcard (*) bypasses proxying for all traffic.
StudyCerts
StudyCertshttpProxy and httpsProxy fields must use the http:// prefix even when the proxy server uses HTTPS, because port 443 traffic automatically uses HTTPS encryption.An explicit proxy configuration requires each client application to be manually configured with the proxy server’s hostname, port, and optionally credentials through environment variables or application properties. PAC files, on the other hand, define dynamic proxy routing rules that are downloaded by clients automatically, allowing centralized control without individual client configuration.
The proxy continues serving cached certificates signed by a removed CA for up to 28 hours. To immediately stop using those cached certificates, update the regional TLS inspection policy to target a completely new CA pool, which forces the proxy to generate fresh certificates.
httpProxy and httpsProxy fields use http:// even when the proxy server uses HTTPS?The http:// prefix is required because the fields define the proxy server’s address and port; requests sent to port 443 are automatically upgraded to HTTPS by the proxy without needing an https:// prefix in the configuration.
Prepare and test your skills
Prepare and test your skills