Migrate scan-scheduling CronJobs off unauthenticated /v1/triggerAction to OperatorCommand CRDs

[matthyx]

Background

/v1/triggerAction (restapihandler/triggeraction.go, port 4002) is an unauthenticated HTTP endpoint — no caller identity check, and its Service (operator:4002, named trigger-port) carries no NetworkPolicy. Verified live on armo-dev-stage: an anonymous, tokenless POST from a throwaway in-cluster pod returns 200/ok with no auth challenge at any layer.

Its only legitimate callers, confirmed live:

CronJob	commandName sent
kubescape-scheduler	kubescapeScan
kubevuln-scheduler	scan
registry-scan CronJob (created dynamically by watcher/registryhandler.go when registry scanning is configured)	scanRegistryV2

All three run quay.io/kubescape/http-request, POSTing a fixed request body to operator:4002/v1/triggerAction with automountServiceAccountToken: false — i.e. no credentials at all.

#411 adds a CommandName allowlist as a stopgap, closing off the immediate risk (an unauthenticated caller directing operatorAction/remediation commands, including patch from #410, at the operator's cluster-wide remediation RBAC). But the endpoint itself remains unauthenticated for the scan commands it does allow.

The real fix

The operator already has an authenticated, RBAC-gated channel for exactly this kind of command delivery: the synchronizer component holds its own K8s ServiceAccount with a ClusterRole explicitly granting create/update/patch/delete on operatorcommands.kubescape.io, reached only through its own authenticated outbound connection to the backend. It creates OperatorCommand custom resources directly, which the operator's existing CRD watcher (watcher/commandswatcher.go) already picks up — no HTTP listener involved.

The scan-scheduling CronJobs should do the same instead of an unauthenticated HTTP callback:

1. Grant kubescape-scheduler's and kubevuln-scheduler's ServiceAccounts (kubescape and kubevuln — they already exist) a narrowly-scoped Role: create on operatorcommands.kubescape.io, namespaced to kubescape only. (The registry-scan CronJob, created dynamically, would need the same.)
2. Replace the http-request container with something that creates the OperatorCommand CR directly (e.g. a small kubectl apply-based image + script, the same pattern the chart's own certgen-create/certgen-patch init containers already use for a different resource).
3. Once migrated, delete /v1/triggerAction entirely — the route in restapihandler/restapi.go, and ActionRequest/HandleActionRequest in restapihandler/triggeraction.go — removing the unauthenticated HTTP surface instead of just narrowing it.

This is strictly better than adding application-level auth (TokenReview/SubjectAccessReview) to the endpoint: it reuses Kubernetes' own authentication and authorization, which is already the trust boundary for the equivalent synchronizer-driven path, and it removes the attack surface rather than policing it.

Scope note

Steps 1–2 require changes to the kubescape-operator Helm chart (a separate repo from this one) — the CronJob templates, their ServiceAccount RBAC, and the request-body ConfigMaps all live there. Step 3 (deleting the endpoint) is this repo's change, and should land only once the chart-side migration has shipped and rolled out, so no live CronJob is left calling a route that no longer exists.

Related

• feat(remediation): add generic patch action for arbitrary workload patches #410 — added the patch remediation action, which is what raised the stakes of this endpoint's lack of auth enough to investigate it.
• fix(restapi): allowlist commandName on the unauthenticated triggerAction endpoint #411 — stopgap CommandName allowlist while this migration is pending.

[matthyx]

Correction: the endpoint itself cannot be deleted

I need to walk back part of this issue's original framing. I've since found designs-and-proposals/cli-cluster-operations.md, which documents /v1/triggerAction as the intended transport for the kubescape CLI's operator remediate annotate|quarantine|revert subcommand (reached via kubectl port-forward, itself RBAC-gated). This isn't a narrow CronJob-only integration detail — it's a first-class, documented feature. Step 3 below (deleting the endpoint) is no longer correct as a goal; it's out unless/until the CLI itself is changed to use a different transport, which is a much larger, separate effort with its own tradeoffs (a human running the CLI from their laptop can't as conveniently "create an OperatorCommand CR" without something equivalent to what kubectl apply already offers, which the design doc notes is already an alternative path).

What's still valid and still worth doing: migrating the three scan-scheduling CronJobs (kubescape-scheduler, kubevuln-scheduler, the dynamically-created registry-scan CronJob) off this endpoint onto direct OperatorCommand CR creation, per steps 1–2 below — that part doesn't depend on the CLI at all and still closes real attack surface for those specific callers.

What replaces step 3: the actual fix for the endpoint's lack of caller authentication is a NetworkPolicy in kubescape/helm-charts restricting external (Service/pod-network) ingress to port 4002 — kubectl port-forward traffic never crosses the pod network a NetworkPolicy governs, so this closes the vulnerability (any pod hitting the Service directly) without breaking the CLI's port-forward-based flow. That should be tracked as its own issue against kubescape/helm-charts rather than bundled with the CronJob migration here.

Separately: the immediate risk that motivated all of this — the new patch action (#410) being reachable through this endpoint with no other actions' safety net — is now addressed directly in #410 by gating patch on the OperatorCommand CRD delivery path specifically (since patch, unlike annotate/quarantine/revert, was never part of the CLI design and has no legitimate reason to arrive via triggerAction).