Exposure

exposure

exposure is the outside-facing path triage command in HarrierOps Kube.

Use it when you need to know which visible cluster edges deserve attention first and what they appear to belong to.

What This Command Answers

• Which ingress, load balancer, node port, or host-level path looks reachable from outside?
• What workload or service does that path appear to front?
• Is the attribution strong, heuristic, or visibility-blocked?
• Which exposure path most changes the next move?

Run It

harrierops-kube exposure --output table

If you want a saved structured artifact:

harrierops-kube exposure --output json --outdir ./harrierops-kube-demo

Example Table Output

priority	exposure	targets	attribution	backend
high	Ingress storefront/web-ing	app.example.com	heuristic -> storefront/web-5d4f6	backend runs as storefront/web (can change workloads)
high	LoadBalancer storefront/web-svc	34.120.0.15	heuristic -> storefront/web-5d4f6	backend runs as storefront/web (can change workloads)
high	NodePort kube-system/metrics	nodePort:30080	heuristic	looks management-facing even without strong backend attribution

When To Use It

• after inventory shows visible public paths
• when you need the cluster edge before the full workload story
• when a reachable-looking path may matter more than quiet internal services

What To Look For

• public-looking hostnames or IPs
• management-facing paths that deserve earlier review than generic app traffic
• backend attribution strength: direct, heuristic, or visibility-blocked
• backend consequence such as workload identity or workload-change power

Why It Matters

Outside-facing paths change urgency fast.

A workload behind a public hostname or load balancer matters differently than the same workload hidden behind internal-only access. exposure helps you review the visible edge first without pretending it already proved full reachability.

What Should Stand Out First

• public-looking targets
• management-facing paths
• exposed paths tied to meaningful workloads
• blocked or heuristic attribution language that tells you how much trust to place in the join

If You See..., Go Next To...

• If you see clear workload attribution, go next to Workloads because the next question is how risky that execution context really is.
• If the backend identity matters most, go next to Service Accounts because the next question is which identity the reachable workload runs as.
• If the cluster edge is clear but the broader shape is not, go next to Inventory.

What To Do Next

• Start with the exposed path that combines public visibility and meaningful backend consequence.
• Treat heuristic joins as useful triage, not as final proof.
• Use workloads or service-accounts next depending on whether execution or identity matters more.

Boundary

exposure is exposed-surface triage.

It is not full reachability proof, pod-to-pod network modeling, cloud firewall analysis, or a web exploitation workflow.