Add hawk plugin

[lakshya-8000cr]

Summary

Adds the hawk kubectl plugin to the Krew index.

Hawk analyzes Kubernetes workload dependencies and evaluates the
potential blast radius of operational changes. It discovers workload
ownership, service routing, ingress exposure, ConfigMaps, Secrets, and
persistent storage dependencies.

Repository

https://github.com/lakshya-8000cr/Hawk

Release

v1.0.0

Validation

• Source code is publicly available
• Open-source license is included
• LICENSE is packaged and extracted during installation
• Release uses semantic versioning
• Platform-specific archives are published
• SHA256 checksums have been verified
• Local manifest installation was tested
• Plugin command was tested with kubectl hawk
• Plugin uninstall was tested

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: lakshya-8000cr
Once this PR has been reviewed and has the lgtm label, please assign chriskim06 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: lakshya-8000cr / name: lakshya-8000cr (1301f2f)

[kubernetes-prow]

Welcome @lakshya-8000cr!

It looks like this is your first PR to kubernetes-sigs/krew-index 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/krew-index has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[ahmetb]

Hi! 👋 Thanks for submitting the hawk plugin to the Krew index.

Due to the increased rate of plugin submissions from agentic coding tools, we're seeing a strain on our small reviewer community. Please don't tag maintainers directly — we'll get to your plugin eventually.

This is a new plugin submission, so a human reviewer will make the final decision on whether it fits the curated index. In the meantime, here are some initial findings for you to address:

---

Issues to Address

1. Short Description — Remove "Kubernetes"

The shortDescription currently reads:

Analyze Kubernetes dependencies and blast radius

Since this is already a kubectl plugin, the word "Kubernetes" is redundant in this context. Consider something like:

Analyze workload dependencies and blast radius

2. Naming — Consider a More Descriptive Name

The name "hawk" is a metaphor that doesn't clearly convey what the plugin does. The naming guide recommends that plugin names make it clear what verb the plugin performs and on what resource. A name like blast-radius or dep-analyze would be more immediately understandable to users browsing the index. This is a suggestion rather than a strict requirement, but a more descriptive name would help with discoverability.

---

Similar Existing Plugins

Before the human review, please try out these existing plugins and clarify in a comment how hawk differs:

• lineage — Display all dependent resources or resource dependencies
• pod-lens — Show pod-related resources (workloads, services, configmaps, secrets, ingress, PVC, HPA)
• atlas — Visualize Kubernetes resource dependencies

The dependency discovery aspect of hawk (ownership, service routing, ingress, ConfigMaps, Secrets, persistent storage) overlaps significantly with pod-lens and lineage. If the "blast radius analysis" is the key differentiator, please highlight that in your response so the human reviewer can better understand the unique value.

^{🤖 This comment is an automatic review provided by [krew-review-agent(https://github.com/ahmetb/krew-review-agent)].
If you see a problem with this, please file an issue. 🤖}

[lakshya-8000cr]

Thank you for the review and the suggested plugins.

I have updated the short description to remove the redundant "Kubernetes" wording.

I also reviewed the suggested plugins (lineage, pod-lens, and atlas) to better understand the overlap.

My understanding is:

• lineage focuses on traversing and displaying dependency/dependent relationships between Kubernetes resources.
• pod-lens focuses on discovering and inspecting resources associated with Pods and workloads.
• atlas focuses on visualizing Kubernetes dependency graphs.

Hawk certainly overlaps in the dependency discovery stage, since it also discovers ownership relationships, Services, Ingresses, ConfigMaps, Secrets, and PersistentVolumeClaims.

The intended goal of Hawk, however, is different.

Rather than treating dependency discovery as the final result, Hawk uses the discovered dependency graph as input for an operational blast-radius analysis. Starting from a target workload, Hawk evaluates how configuration, networking, storage, and ownership relationships contribute to the potential operational impact of modifying or deleting that workload.

For example, Hawk highlights information such as:

• Whether the workload is externally exposed through an Ingress.
• Which Services route traffic to the workload.
• Which ConfigMaps and Secrets are consumed.
• Which PersistentVolumeClaims and storage resources are involved.
• The overall blast-radius classification (e.g. LOW, MEDIUM, HIGH) based on the discovered dependency graph.

In other words, dependency discovery is the mechanism, while operational impact assessment is the primary objective. Hawk is intended to answer "What is the potential impact of changing this workload?" rather than only "What resources are connected to it?"

Regarding the plugin name, I understand the discoverability concern. I would prefer to retain hawk because it is already the established project and binary name. However, if the human reviewers believe a more descriptive name is necessary for inclusion in the curated index, I am happy to rename the project accordingly.