fix(k8sdiscovery): accurately classify workloads and reject non-workl…

[shellyco-code]

Overview

This PR fixes a bug in k8sinterface.IsTypeWorkload where non-workload Kubernetes resources (such as ConfigMap, Secret, Service, ServiceAccount, Role, ClusterRole, RoleBinding, NetworkPolicy, Ingress, and arbitrary CRDs) were incorrectly classified as workloads.

It also resolves the existing TODO comments (// TODO - check if found in supported objects and // TODO - consider using a k8s manifest validator) and fixes the docstring typo.

Problem & Root Cause

IsTypeWorkload previously evaluated len(getResourceTriplets(group, version, s2)) == 1. Because getResourceTriplets appends a triplet for any resource with an API group or matches core discovery resources like configmaps and secrets, the slice length was always 1, resulting in false-positive classification for virtually all Kubernetes objects.

Changes Made

1. Canonical Workload Classification:
   • Implemented isStandardWorkload to validate supported workload controllers (Pod, Deployment, DaemonSet, StatefulSet, ReplicaSet, Job, CronJob, ReplicationController) against their recognized API groups ("", core, apps, extensions, batch).
2. Custom Resource Spec Detection:
   • Implemented hasPodOrContainerSpec to inspect custom resources for pod templates (spec.template.spec.containers / initContainers), direct containers (spec.containers), or scheduled job templates (spec.jobTemplate.spec.template.spec.containers), enabling support for CRD workloads like Argo Rollouts while safely rejecting non-workload CRDs.
3. Comprehensive Test Suite:
   • Expanded TestIsTypeWorkload in k8sdiscovery_test.go into a 38-case table-driven test covering all canonical workloads, legacy extensions groups, CRD container specs, non-workload resources, and malformed inputs.

How to Test

1. Run go test -v ./k8sinterface -run TestIsTypeWorkload
2. Run go test ./... across the repository to verify all packages pass.

Related issues/PRs:

Fixes #181

Checklist before requesting a review

• My code follows the style guidelines of this project
• I have commented on my code, particularly in hard-to-understand areas
• I have performed a self-review of my code
• If it is a core feature, I have added thorough tests.
• New and existing unit tests pass locally with my changes

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 1605be61-9691-4181-816c-37ccee693487

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

---

_{Comment @coderabbitai help to get the list of available commands.}

[matthyx]

Approve: the classification fix is needed and no introduced blockers were found in the two changed files. Reviewed head 578d664cb29efb70d16dd3a4b6901d1ed5db2f78 against main at fa34e9d841dce49a3862bd39de6e3b004b1a95e0.

The old getResourceTriplets fallback accepts arbitrary nonempty group/version resources. An isolated regression probe rejects a Role and a container-free custom resource: it fails on the target branch and passes on this head. The canonical-kind checks and bounded CR shape checks address #181 directly without changing the public signature, dependencies, or discovery APIs.

History: searched all-state PRs/issues using IsTypeWorkload, k8sdiscovery, workload, discovery, classification, non-workload, ConfigMap, and pod-spec terms (up to 100 results per query). No duplicate, superseding fix, or relevant closed-unmerged rejected approach surfaced. This is bounded GitHub search, not proof of absence. #151 fixes multi-group discovery, #160 refreshes discovery, and #157 hardens manifest accessors; none fixes classification. Their discussions support preserving discovery and safe accessor behavior, which this PR does. #63 filters controller ownership on a different path, not workload kind classification.

Validation in credential-free, capability-dropped Go 1.25.8 containers: go test ./k8sinterface -run TestIsTypeWorkload -count=1; before/after regression probe; go test ./k8sinterface ./workloadinterface -count=1; go vet ./k8sinterface ./workloadinterface; changed-file gofmt check and git diff --check all passed on head. CI for this exact commit passed package tests, lint, and cross-platform builds. Full-repository tests and race tests were not run locally; downstream Kubescape/MCP integration was not exercised. The added tests do not exercise all init-container paths. Semantic gopls tooling was unavailable; code/data-flow review was manual, with independent code and architecture reviews both clear.

Nonblocking limitation: direct-container and custom scheduled-job CRs already classify true on main, but kind-based workloadinterface.PodSpec cannot extract their containers. The before/after probe confirms unchanged behavior; recognizing a workload does not guarantee every reader supports its layout. This is existing follow-up scope, not an introduced defect.

FOSSA License Compliance reports ERROR / “2 issues found”; details were not available in this review, so I do not attribute it to infrastructure or claim it resolved. No dependencies changed. Retrieved main protection/rules require PR approval, with no named required status checks; those approval requirements remain subject to GitHub enforcement. Existing PR reviews/inline comments were empty when rechecked. No severity-rated blockers or inline comments to add; approval applies only to the reviewed head, not a merge action.