feat(C-0021): cover AI/ML inference and MLOps interfaces in sensitiveInterfaces - #753

Overview

Extends the sensitiveInterfaces posture-control input with the AI/ML inference and MLOps interfaces that have become standard in Kubernetes clusters — Ollama, vLLM, KServe, NVIDIA Triton, the Ray dashboard/head, MLflow, JupyterHub, Seldon and BentoML. With these names in the allowlist, the existing exposed-sensitive-interfaces-v1 rule (C-0021) immediately flags a LoadBalancer/NodePort Service that fronts any of these workloads — no rule logic changes required.

Problem / motivation

C-0021 detects sensitive interfaces exposed to the internet via LoadBalancer/NodePort Services, matching workload names against the sensitiveInterfaces list. That list predates the current wave of AI/ML serving stacks and only covers classic DevOps tooling (NiFi, Argo, Kubeflow, Weave Scope, the Kubernetes dashboard, Jenkins, Prometheus).

Modern AI/ML serving and MLOps components share the exact property that makes this control matter: they commonly ship without authentication by default and bind broadly. When exposed they enable model/prompt exfiltration and, in several cases, remote code execution on cluster nodes:

• Ray — the dashboard's Jobs API allows arbitrary job submission with no auth; abused in the wild for cryptojacking ("ShadowRay", CVE-2023-48022, disputed by the vendor but actively exploited).
• vLLM / Ollama / Triton / KServe / Seldon / BentoML — OpenAI-compatible or gRPC/HTTP inference endpoints with no built-in authN/Z; exposure leaks served models and prompts and provides an unauthenticated inference surface.
• MLflow — tracking server has a documented LFI/RFI and path-traversal history (e.g. CVE-2023-6014, CVE-2023-6018) reachable when the UI/API is exposed.
• JupyterHub — exposed notebooks provide interactive code execution inside the cluster.

This is the same class of "exposed sensitive interface" the control already guards (MITRE ATT&CK for Containers, Initial Access — Exposed Sensitive Interfaces) and is reflected in OWASP's ML/LLM security guidance. The gap is a coverage false-negative: real, high-impact exposures go unflagged today.

Change

• default-config-inputs.json — appended ten entries to settings.postureControlInputs.sensitiveInterfaces: ollama, vllm, kserve, triton-inference-server, ray-dashboard, ray-head, mlflow, jupyterhub, seldon, bentoml.
• controls/C-0021-exposedsensitiveinterfaces.json — updated description and long_description to note that the same exposure pattern applies to AI/ML inference and MLOps interfaces, with examples.
• rules/exposed-sensitive-interfaces-v1/test/vllm/ — new test case: an exposed vLLM Deployment + LoadBalancer Service, with the expected alert, mirroring the existing workloads (LoadBalancer) and workloads2 (NodePort) fixtures exactly.

kubeflow-pipelines is intentionally not added: the rule uses a substring match (contains(wl.metadata.name, wl_name)), so the existing kubeflow entry already covers kubeflow-pipelines* workload names. The names chosen above are specific enough to avoid broad substring collisions (e.g. ray-dashboard/ray-head rather than ray, triton-inference-server rather than triton).

Security rationale

• Framework / mapping: MITRE ATT&CK for Containers — Initial Access, Exposed Sensitive Interfaces (the control's existing microsoftMitreColumns tag). The added interfaces are direct, current instances of that technique.
• OWASP: aligns with OWASP LLM/ML security guidance on exposed inference and MLOps endpoints (model/prompt disclosure, unauthenticated inference, supply-chain/RCE via model servers).
• Representative CVEs/exposure classes: Ray dashboard unauthenticated job submission (CVE-2023-48022, "ShadowRay" in-the-wild cryptojacking); MLflow path traversal / file read (CVE-2023-6014, CVE-2023-6018). These are reachable precisely when the interface is fronted by a LoadBalancer/NodePort Service — exactly what C-0021 detects.
• Impact framing: for a security team, an internet-exposed model server is both a data-exposure (models, prompts, potentially PII in prompts) and an RCE/lateral-movement risk into the cluster. Surfacing it in an existing, already-trusted control is high-signal and low-cost.

Testing / validation

Run from testrunner/ (go1.26.2, -tags=static):

# Targeted — the touched rule (includes the new vllm case)
go test -tags="static" rego_test.go -run TestSingleRule -args -rule exposed-sensitive-interfaces-v1
# PASS — pod, workloads, workloads2, vllm

# Full suite — confirms the shared config edit causes no regressions
go test -tags="static" rego_test.go -run TestAllRules
# ok  (337s)

• New positive case (vllm): an exposed vLLM Deployment behind a LoadBalancer Service is correctly flagged.
• False-positive control: the rule still requires a LoadBalancer/NodePort Service selector-matched to the workload, so ClusterIP-only AI workloads (the common, non-exposed case) are not flagged — the entire existing test matrix continues to pass unchanged.
• All touched JSON validated as well-formed; the control file's existing ’ (’) escaping convention is preserved.

Checklist before requesting a review

• My code follows the style guidelines of this project
• 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

Summary by CodeRabbit

• New Features

  • Enhanced detection of exposed sensitive interfaces to include AI/ML frameworks: vLLM, Ollama, KServe, Triton Inference Server, Ray, MLflow, JupyterHub, Seldon, and BentoML.
  • Added Prometheus monitoring interface detection.

• Documentation

  • Expanded control descriptions with detailed examples of sensitive interfaces and frameworks.