Shopify Overexposed Scans GKE Ingresses and Cloud Run for Exposure

Shopify has unveiled Overexposed, an internal scanner designed to identify Kubernetes Ingresses on GKE and Cloud Run services. The scanner checks for publicly accessible Ingresses without authentication. Its development evolved from an initial version based on repository config files, which produced false positives and missed certain cases. The team rebuilt it using GCP Cloud Asset Inventory and an anonymous HTTP probe, reducing inconclusive Ingress verdicts by around 80% within weeks of fine-tuning.

The original scanner analyzed the infrastructure repository for Ingresses, focusing on public hostnames lacking authentication settings before probing them. However, this approach failed in three ways: teams applying proxy authentication annotations directly led to false positives; admission controllers that modify settings at admission time but not uniformly across clusters might render correct configurations ineffective; and Ingresses created by other repositories or platform tooling remained undetected.

The team addressed these issues by implementing a schedule-based scanner that queries Cloud Asset Inventory, which includes Ingresses verified by GKE post-admission, Cloud Run services, and load balancers. This inventory also retrieves access policies without requiring cluster credentials. The scanner sends a single anonymous request to each candidate, first a HEAD request, then a GET if necessary, follows at most three redirects, and checks each path variation like /ADMIN, as path rules can be case-sensitive.

Results are categorized into six verdicts: exposed, expected, protected, not found, unreachable, and inconclusive. Expected applies when an endpoint is open but matches a reviewed allowlist entry by exact host and path. Shopify emphasizes that status codes are context-dependent, with a 404 behind an Ingress indicating the proxy answered but the path is missing, while a 403 on Cloud Run is not considered proof of protection.

The scanner distinguishes between ingress settings and IAM permissions, determining if a service is public based on specific roles and configurations. Early runs showed roughly three-quarters of results as inconclusive, leading the team to categorize uncertain evidence as inconclusive instead of defaulting to protected to avoid premature conclusions.

The scanner records verdicts, reasons, and team ownership but does not store response bodies or credentials. To mitigate SSRF risks, Shopify ensures every IP returned by DNS is validated, rejects private and loopback addresses, connects directly to the checked IP to prevent DNS rebinding, and repeats checks on each redirect. Shopify's implementation highlights the difference between rule-based checks and inventory-based approaches.

Rule-based tools, like Trend Micro's Cloud Run rule, focus on configuration intent but may miss resources outside the repository and settings altered by admission controllers. Inventory-based methods, such as Cloud Asset Inventory queries, start from the actual cloud resources, addressing blind spots in configuration-based tools.

Overexposed incorporates an anonymous probe, allowlist, and evidence-backed verdicts to complement inventory-based checks, providing a more comprehensive view of exposure. Shopify's approach suggests using inventory as the primary reference, with configuration analysis as an early signal in CI, and supplementing it with an inventory-based probe for more accurate and reliable exposure scanning.