Prepare and test your skills
Prepare and test your skills
Automated vulnerability assessment with Web Security Scanner (opens in a new tab) is the practice of automatically testing public web applications for common flaws before attackers find them. Web Security Scanner targets applications running on App Engine, Compute Engine, and Google Kubernetes Engine (GKE). Results flow from the scanner to the development team through the Google Cloud console and APIs, so findings drive code fixes and secure coding practices.
Web Security Scanner is a vulnerability detection service for publicly facing App Engine, Compute Engine, and GKE web applications. The scanner sends test traffic from outside the application to its public URLs, so the trust boundary being tested is the internet-facing surface rather than internal traffic. The service is available under Security Command Center Standard-legacy, Premium, and Enterprise tiers, and it supports the goal that public web applications stay protected against attacks.
Web Security Scanner looks for application-layer weaknesses that violate secure coding practices:
Running a Web Security Scanner scan means choosing how the scan is triggered from the Google Cloud console or from a build pipeline. Scans can be started on demand for an immediate check after a major code change, and scans can be scheduled from the Google Cloud console for repeated coverage over time. Using the Security Scanner APIs, the scan depends on the application build pipeline, because the pipeline calls the API so scanning runs automatically as part of the security test suite.
This automation connects development to security operations in a fixed order:
This order keeps vulnerability checks inside the normal path from code commit to release.
Exam tip: Web Security Scanner applies only to publicly facing App Engine, Compute Engine, and GKE web applications; it does not replace container-image scanning for images stored in registries.
Evaluating Web Security Scanner results means ranking each finding by risk and fixing the highest-risk issues first. High-risk and critical vulnerabilities that are reachable from the internet receive priority because their potential impact is greatest, while lower-severity misconfigurations are scheduled after exploitable flaws are addressed. Remediation flows from the finding to the application code or configuration, where developers apply secure coding fixes, update insecure libraries, and correct misconfigurations.
Fixed applications must then be re-scanned to confirm that the vulnerability is closed and no new issue was introduced. Over time, repeated on-demand, scheduled, and pipeline-automated scans create a continuous check where each release depends on passing security assessment before promotion. This cycle helps teams keep public web applications hardened and aligned with secure development practices.
Resource protection and service hardening is the practice of layering identity, network, and configuration controls so compromised credentials or exposed endpoints cannot reach sensitive services. In Google Cloud, Chrome Enterprise Premium (opens in a new tab) provides user-centric request checks, VPC Service Controls provides resource-centric perimeters, Identity-Aware Proxy (IAP) (opens in a new tab) provides context-aware access to apps and mesh services, and Identity and Access Management (IAM) plus hardening of keys, logins, and mesh policy completes the defense.
Chrome Enterprise Premium is a user-centric control that evaluates attributes on every API request and rejects user traffic that does not meet the policy. An access level and binding can require conditions such as IP-based access or certificate-based access for mutual TLS, so a request that uses compromised authorization credentials but fails those conditions is rejected. Not all device attributes collected by Endpoint Verification are evaluated on every API request.
VPC Service Controls is a resource-centric control that defines service perimeters within which resources can communicate. VPC Service Controls blocks access to Google-managed services outside a trusted perimeter, blocks access from untrusted locations, and mitigates data exfiltration risks. When Chrome Enterprise Premium and VPC Service Controls are used together, they reduce the effectiveness of compromised credentials on an attacker-controlled machine outside the environment.
| Control | Focus | Identities covered |
|---|---|---|
| Chrome Enterprise Premium | User API traffic and request context such as IP or mTLS certificate | Only user identities in the organization |
| VPC Service Controls | Resources and the perimeters in which they can communicate | All user identities and service account identities |
Exam tip: VPC Service Controls applies to all user and service account identities, while Chrome Enterprise Premium applies only to user identities within the organization.
Hardened remote access for Compute Engine means requiring a second authentication factor for SSH and applying coarse session controls where granular enforcement is not possible. If developers access Compute Engine resources with SSH, configure OS Login with 2-Step Verification. This creates an additional checkpoint where the user must reauthenticate with a password or security key, so an attacker with compromised OAuth tokens but no password or security key is blocked.
Remote Desktop Protocol (RDP) access to Windows instances does not support the OS Login service, so 2-Step Verification cannot be granularly enforced for RDP sessions. When using IAP Desktop or Google Chrome-based RDP plugins, set coarse-grained controls such as session length for Google services and 2-Step Verification settings for web sessions, and disable the Allow user to trust the device setting under 2-Step Verification.
IAM service account keys (opens in a new tab) are long-lived downloaded credentials that increase the risk of credential theft and replay. When a service account key is used for authentication, the key value is stored in gcloud CLI configuration files separately from the downloaded key file. An attacker with access to the environment can copy the key from the gcloud CLI configuration or copy the key file from the local file system or internal code repository. To reduce this risk, replace key-based workflows with more secure authentication alternatives and enforce organization policy constraints to disable key creation and upload. The constraints constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload prevent creation and upload of user-managed keys. Complement this with least privilege in IAM policy design: grant only the roles required for a task at the smallest scope, and review and apply role recommendations to remove unused and excessive grants.
Endpoint protection addresses the risk that an attacker compromises a trusted developer workstation or Compute Engine instance and then runs gcloud CLI commands or other code directly on it. A plan for compromised credentials is not sufficient if the endpoint itself is compromised, so security tools and operations must protect and monitor endpoints for compromise. Security operations should also ensure that incident response teams already have appropriate access across the Google Cloud console and the Admin console before an incident occurs.
Security operations for endpoints should address each of the following questions:
Correct access enforcement depends on the audience and deployment model of the application. For applications and workloads that serve corporate users, Identity-Aware Proxy (IAP) enforces context-aware access without exposing the workload directly. IAP policy is controlled through the IAM policy of the IAP-protected web application, including the IAP-Secured Web App User role, and visibility and access can be managed at scale with groups provisioned from an external identity provider.
For other audiences and for APIs, standard identity protocols and API gateways provide enforcement. Applications can directly integrate Sign-In With Google or use OAuth 2.0 and OpenID Connect for end-user authentication. API access can be enforced in Istio and Cloud Endpoints, and both products can be used whether applications serve corporate users or end users.
Cloud Service Mesh (opens in a new tab) secures workload-to-workload communication with mutual TLS (mTLS), in which client and server present certificates to each other and verify each other's identities. Mutual TLS provides both authentication and encryption between services and supports a Zero Trust posture through declarative policy without modifying application code. Unlike bearer tokens such as JSON Web Tokens (JWT), mTLS certificates mitigate replay or impersonation attacks that use stolen credentials.
In Cloud Service Mesh 1.6 and later, auto mTLS is enabled by default. With auto mTLS, the client sidecar proxy first detects whether the server has a sidecar, then sends mTLS to workloads with sidecars and plain text to workloads without sidecars. Services accept both plain-text and mTLS traffic by default, so services should be migrated to only accept mTLS traffic. The default cipher suites are FIPS-compliant, including ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES256-GCM-SHA384, and ECDHE-RSA-AES256-GCM-SHA384. The server-side minimum TLS version for Cloud Service Mesh workloads is 1.2, which supports customizing cipher suites. Cloud Service Mesh also supports TLS v1.3, which hard-codes cipher suites and does not support changing them.
Token replay defense for mesh services requires exchanging a long-lived external token for a short-lived internal token at the mesh edge. A request from outside the mesh to a mesh service includes a token such as a JWT or cookie, but that external token may be long-lived. The flow therefore exchanges the external token at the ingress of the mesh for a short-lived, mesh-internal token with limited scope, and the mesh service authenticates and authorizes the request based on that internal token. Cloud Service Mesh supports integration with IAP, which generates a RequestContextToken for authorization in the mesh. Because of its limited scope and lifetime, a token stolen inside the mesh cannot be reused to access other services, which greatly reduces the chance of a token replay attack.
Secure exception handling means treating any bypass of Cloud Service Mesh security policy as a security gap that needs compensating controls and monitoring. Traffic can be excluded from the Envoy sidecar with Pod annotations such as excludeInboundPorts, excludeOutboundPorts, and excludeOutboundIPRanges, or the mesh can be bypassed entirely by disabling sidecar injection with the label sidecar.istio.io/inject="false" on the application Pod. Bypassing mTLS and authorization policy removes access control for traffic on that port or IP range and can allow eavesdropping or traffic modification, and it also affects non-security policies such as network policies. When a bypass exists, traffic that bypasses the sidecars must be natively encrypted and authenticated to prevent man-in-the-middle attacks, and Kubernetes network policies must limit connectivity of the excepted ports, for example by allowing traffic only from another service in the same namespace or only through ports where mesh security policy is enforced. To prevent configuration drift, where mesh policy deviates from its source of truth, use a GitOps approach with Config Sync. Mesh administrators should use observability resources such as Cloud Audit Logs, Cloud Service Mesh audit logging, access logs, service-level metrics, and Cloud Trace to verify configuration and monitor exceptions. Security teams and Security Command Center itself also depend on preserved IAM permissions, including the service account Google Cloud creates for scans and log processing when Security Command Center is activated, and those roles and permissions must not be removed or modified.
Identity-Aware Proxy (IAP) (opens in a new tab) is a Google Cloud service that enforces a zero-trust security model for web applications and virtual machines (VMs). Zero trust means no user or device is trusted because of network location alone, so every request is verified for identity and context before access is granted. IAP sits between the client and the protected resource and applies centralized Identity and Access Management (IAM) policies, which removes the need to expose apps or SSH directly to the public internet.
IAP protection for web applications and VMs works by placing IAP as an intermediary, similar to a bastion host or reverse proxy, between the client device and the backend. Traffic flows from the user to IAP first, and IAP forwards the traffic to the application or VM only after authentication and authorization succeed. For web apps, a user must sign in with a valid Google credential and be granted the IAP-Secured Web App User role (roles/iap.httpsResourceAccessor); users without that role or who fail authentication cannot reach the app. For SSH to VMs, a user must be granted tunnel permission such as IAP-secured Tunnel User (roles/iap.tunnelResourceAccessor), and IAP removes the need to assign an external IP address to the VM.
IAP TCP-forwarding is the path that carries SSH connections from the client device through IAP to the VM. The connection starts at the workstation, is evaluated by IAP, and only then is forwarded over the internal network to the target VM. Exposing SSH directly on port 22 is not recommended because default firewalls can leave it open to the internet and invite attacks.
Direct internet SSH increases risk in three main ways:
When a user attempts an SSH connection through IAP TCP-forwarding, IAP performs four checks:
Context-aware access is the zero-trust rule that checks user identity plus device and location signals before granting access. By default, a user granted SSH access can connect from any device, network, and location, which is convenient but risky if devices are compromised or networks are untrusted. Access Context Manager defines access levels for allowed networks, geographies, and device conditions, and IAP enforces those levels on each request.
Rich device checks depend on Chrome Enterprise Premium managing the client devices. With managed devices, Access Context Manager receives device signals and can enforce basic access levels based on network or geo-location plus stronger controls based on credential strength, browser configuration, and device posture. If the configuration of a client device is not controlled, the device must be treated as unmanaged and potentially untrusted. For unmanaged devices, IAP TCP-forwarding can only control access by user identity and IP address, and cannot restrict access based on device posture.
Access levels for IAP TCP-forwarding can be applied in two ways that differ in scope and ownership. Access bindings create an identity-based policy by assigning an access level to a group, and the policy applies to all resources that user attempts to access, including IAP, other APIs, and the Google Cloud console. Access bindings work best when context-aware access must be enforced uniformly across resources. IAM conditions create a resource-based policy by attaching an access level to an individual IAM role binding on specific VMs, so different sets of VMs can have different policies. IAM conditions work best when different VM groups need different device, network, or location rules.
The choice of SSH approach depends on whether the VM needs external access and whether the VM is part of a VPC Service Controls perimeter. A service perimeter is a resource-centric boundary that controls which identities and sources can move data in and out, while Chrome Enterprise Premium is a user-centric control that applies only to user identities in the organization. When SSH access to a VM inside a perimeter is granted to a user outside the perimeter, data could be copied out through SSH, so IAP must enforce the perimeter ingress rules.
| Approach | Use when | How access is controlled |
|---|---|---|
| IAP-based SSH access | VM must be reachable externally or from a large internal network and is not in a service perimeter | IAP TCP-forwarding (opens in a new tab) checks Google identity and IAM permission; no external IP needed |
| IAP-based context-aware SSH access | Same as above, but access should be limited to certain devices, networks, or locations | IAP TCP-forwarding checks identity plus access levels applied through access bindings or IAM conditions |
| VPC Service Controls-based SSH access | VM is part of a service perimeter | IAP TCP-forwarding checks IAM permission and perimeter ingress rules for connections from outside; connections from inside skip ingress rules |
| Firewall-controlled internal SSH access | VM needs no external access, is on a small to medium internal network, and is not in a perimeter | No external IP or firewall rules block SSH from outside the VPC; only VPC-internal SSH is allowed |
IAP considers a TCP-forwarding connection to originate from inside a service perimeter in three cases: the source IP is the external IP of a VM that is part of the perimeter, the connection uses Private Google Access from a VM that is part of the perimeter, or the connection uses a Private Service Connect access endpoint that is part of the perimeter. Connections from outside the perimeter must satisfy both IAM permission on the VM and an ingress rule that allows the IAP source for the stated identities. To allow external access safely, configure ingress rules to enforce context-aware access rather than opening SSH directly.
Exam tip: Use access bindings when the same context rule must apply uniformly to IAP and other resources, and use IAM conditions when different sets of VMs need different context rules.
Web Security Scanner tests publicly facing web applications running on App Engine, Compute Engine, and Google Kubernetes Engine (GKE) by sending test traffic from outside to public URLs. It looks for application-layer weaknesses such as cross-site scripting flaws, security misconfigurations, and vulnerable resources including insecure libraries. Scans can be started on demand, scheduled from the Google Cloud console, or triggered automatically from a build pipeline through the Security Scanner APIs.
Chrome Enterprise Premium is a user-centric control that evaluates attributes on every API request and applies only to user identities in the organization, while VPC Service Controls is a resource-centric control that defines service perimeters and applies to all user and service account identities. Chrome Enterprise Premium can require conditions such as IP-based access or certificate-based access for mutual TLS, while VPC Service Controls blocks access to Google-managed services outside a trusted perimeter and mitigates data exfiltration risks.
Use access bindings when the same context rule must apply uniformly across resources including Identity-Aware Proxy (IAP), other APIs, and the Google Cloud console by assigning an access level to a group. Use IAM conditions when different sets of virtual machines need different device, network, or location rules by attaching an access level to an individual IAM role binding on specific virtual machines.
Last updated