Problem
The team needs to know which Cloudflare routes reach EKS workloads and whether any public paths skip expected authentication or WAF controls.
Use case
Cloud security misconfigurations
A team wants to know which public cloud and Kubernetes paths are exposed, whether the exposure is intended, and what should be reviewed before remediation.
This page is short on purpose: problem, app query, required context, sample output, and safety boundary before the CTA.
Use Clanker Cloud when security review needs edge, DNS, WAF, ingress, and cluster context without moving credentials to a hosted scanner.
Concrete workflow
Problem, query, context, output, and safety boundary
App workflow/query
Clanker Cloud app:
1. Open Security.
2. Select Cloudflare plus the production EKS context.
3. Ask:
Scan Cloudflare edge, DNS, WAF, tunnels, and EKS ingress for exposed paths, missing auth, and risky public API surfaces.
Optional focused app query:
Which DNS records, Workers routes, and tunnels point at the production EKS ingress?Open-source CLI equivalent
clanker security "Scan Cloudflare edge, DNS, WAF, tunnels, and EKS ingress for exposed paths, missing auth, and risky public API surfaces." --profile prod
clanker ask --cloudflare "Which DNS records, Workers routes, and tunnels point at the production EKS ingress?"Input context
Clanker Cloud app connected to AWS for EKS discovery, Cloudflare account or zone credentials configured locally, production cluster context, known domains, and any expected public/private route list.
Output example
Finding: api.example.com is proxied through Cloudflare to an AWS ALB backing ingress prod/public-api. /admin/health is reachable without auth and bypasses the Worker route that enforces JWT checks. WAF rules are active for /api/* but not /admin/*. Suggested next step: add an explicit Cloudflare rule for /admin/* and verify the ingress annotation set before exposing additional paths.Safety boundary
The scan inventories resources and performs bounded reachability checks. It does not mutate DNS, WAF, ingress, or Kubernetes objects. Remediation stays behind a reviewed plan.
Supported providers
Next step
Generate a reviewed plan for route tightening, WAF coverage, or ingress annotation changes, then re-run the scan to confirm the public surface changed.
Buyer query
A team wants to know which public cloud and Kubernetes paths are exposed, whether the exposure is intended, and what should be reviewed before remediation.
Read-only first
The scan inventories resources and performs bounded reachability checks. It does not mutate DNS, WAF, ingress, or Kubernetes objects. Remediation stays behind a reviewed plan.
Proof artifact
The workflow below includes the app query, local context required, example output, supported providers, and next step.
Next step
Generate a reviewed plan for route tightening, WAF coverage, or ingress annotation changes, then re-run the scan to confirm the public surface changed.
Related proof
Read the supporting pages
Full example workflow
Open the longer proof page with the same app-first workflow pattern.
Local credentials
Read what stays local, what can go to model providers, and how read-only/maker/apply differ.
Example library
Browse all proof workflows for cost, security, Kubernetes, MCP, and review-before-apply.
FAQ
Common questions
Does this use case require write access first?
The scan inventories resources and performs bounded reachability checks. It does not mutate DNS, WAF, ingress, or Kubernetes objects. Remediation stays behind a reviewed plan.
Why is this separate from the example page?
The use-case page answers the high-intent buyer query directly. The example page is the deeper proof artifact with the same concrete workflow format.
Next step
Run the read-first workflow
Download the desktop app, connect the existing local context, and start with inspection before reviewed plans.