Most AI Helm charts ship without authentication.

01Why defaults matter more than docs

Self-hosting an LLM stack has never been easier: helm install ollama, helm install open-webui, done. But ease of install is not the same as ease of securing. Most of these services were designed as local tools — Ollama has no authentication mechanism at all, MLflow ships without built-in auth, Ray's dashboard famously answers every request — and the chart is often the first thing standing between that design and a routable IP address.

The interesting number is not "how many charts are insecure". It is how far the default values are from an unauthenticated, internet-reachable AI service — because that distance is what a tired engineer closes at 11pm when the demo must work by morning.

02Method, in one paragraph

I searched the Artifact Hub API with 52 AI/LLM terms (ollama, vllm, open-webui, langflow, mlflow, jupyter, qdrant, milvus, weaviate, ray, ...), deduplicated by repository+chart, and pulled the default values.yaml for each chart — HTTP tarballs directly, OCI charts (Bitnami and friends) via helm show values. A deterministic classifier then flagged network exposure (service.type: LoadBalancer/NodePort, ingress/httproute/gateway.enabled: true, with ancestor enabled: false gates respected) and authentication configuration. Finally I joined the charts with an upstream-auth table — what each service offers upstream, with sources — because a chart cannot configure an auth mechanism its app does not have. Every flagged chart was verified by hand.

03The numbers

That last row is the one to sit with: a third of the charts could be exposed with a one-line change, and they contain no authentication configuration to turn on. helm install ollama-helm/ollama (57★) gives you a ClusterIP service and zero auth keys; flipping ingress.enabled=true yields an unauthenticated inference API on the internet — which is exactly the shape of the ~300,000 exposed Ollama deployments the "Bleeding Llama" advisories describe (CVE-2026-7482 and friends).

04The three official charts worth staring at

None of these are obscure forks. They are the charts you land on first.

JupyterHub (77★, the official Zero-to-JupyterHub chart)

proxy:
  service:
    type: LoadBalancer        # exposed by default
hub:
  config:
    JupyterHub:
      admin_access: true
      authenticator_class: dummy   # accepts any username

The dummy authenticator is the documented default so that a first install works out of the box; the docs say plainly it should never run in production. The combination with a default LoadBalancer is what makes it notable: helm install plus nothing else produces an internet-reachable notebook server that lets anyone in.

Weaviate (official chart)

service:
  type: LoadBalancer                 # exposed by default
authentication:
  anonymous_access:
    enabled: true                    # anonymous by default

Anonymous access is the default and API keys / OIDC are opt-in. The upstream docs call this out; the defaults still speak for themselves.

Milvus (official Bitnami chart, OCI)

proxy:
  service: { type: LoadBalancer }    # data plane, exposed
attu:
  service: { type: LoadBalancer }    # web console, exposed
milvus:
  auth: { enabled: false }           # auth disabled by default

Both the gRPC data plane and the Attu web console ship as LoadBalancers while authorization is off — with stock values, a fresh Milvus asks nobody for credentials.

05Patterns by service family

The contrast row matters as much as the offenders: apps with built-in account systems (Dify, LibreChat, Langfuse) expose their UIs happily — because the app authenticates. The problem is concentrated where the service has no auth story and the chart dutifully ships the exposure knob anyway. Ray is the loudest example: every KubeRay chart I scanned is zero-auth, and Ray's dashboard RCE (CVE-2025-62593) sat in CISA's Known Exploited Vulnerabilities catalog in August 2026.

06How to use this (and how not to)

• Before exposing any AI chart: check whether the app has auth at all (the upstream table in the repo answers this for ~30 families), then put auth in front if it doesn't — an ingress with an auth proxy, a service mesh policy, or a gateway with authentication. Ollama, TGI, MLflow, Ray and raw KServe endpoints will never ask for credentials on their own.
• If you maintain a chart: the cheapest hardening is not a new feature — it is aligning the defaults. ClusterIP + ingress closed is the safe posture; if the app has an auth flag, default it on for exposed service types.
• Do not read this as a vulnerability list. It is a snapshot of published default values, verified by hand on 2026-09-17. The raw dataset stays private; the aggregates, the classifier and the upstream-auth table are public so you can rerun everything.

07Reproduce it

git clone https://github.com/dtduc-git/ai-helm-defaults
cd ai-helm-defaults
python3 collect.py    # Artifact Hub API + helm show values
python3 classify.py   # exposure + auth classifier, written to results_final.json

# single chart, no code:
helm show values oci://registry-1.docker.io/bitnamicharts/milvus | grep -A2 "auth:"

Caveats, in full, in the repo README: chart-level analysis of published defaults, "stars" are Artifact Hub stars, the corpus skews to community charts, app-side auth may exist outside a chart's values, and MCP charts (49) were excluded from headline math because their upstream posture varies too much to classify.