Version: 2.0.0

Restricting Redis Network Access

The Redis instance bundled with LLMWhisperer has no password set and accepts connections on its ports from any pod in the cluster, not only from LLMWhisperer's own services. Restricting it to the namespace LLMWhisperer is installed in is recommended.

This is a values change, not a version upgrade. It alters only a NetworkPolicy object — no pods restart and there is no downtime — and it can be reverted the same way.

The background, the reasons this matters, and how to tell whether your cluster enforces NetworkPolicy at all are covered once in the Unstract guide, and apply here unchanged: Restricting Redis Network Access. Read that first — in particular the "Does this apply to my cluster?" section, since on a cluster whose CNI does not enforce NetworkPolicy this setting is silently inert.

The LLMWhisperer-specific part is the values block. Add it to your onprem.values.yaml:

redis:
  networkPolicy:
    enabled: true
    allowExternal: false
    extraIngress:
      - ports:
          - port: 6379
          - port: 26379
        from:
          - podSelector: {}

If you are installing for the first time, this is simply part of your values file — the setting applies at install time and there is nothing extra to do. If you are already deployed, re-run your usual helm upgrade at the version you are already on; this alters only the NetworkPolicy.

Apply both settings together

allowExternal: false must not be used on its own. Alone it restricts Redis to pods carrying a redis-client label, and no LLMWhisperer service sets that label — every service would immediately lose access. The extraIngress block is what restores access for the namespace. Copy the whole block.

Port 26379 is not optional here. LLMWhisperer runs Redis in Sentinel mode by default, and clients reach Sentinel on 26379 to discover the master. Omitting it breaks every consumer.

podSelector: {} matches every pod in the namespace the policy is installed in, so no pod needs a label and the same setting is correct in any namespace.

Verifying

The NetworkPolicy is named redis, and the Redis pods are redis-node-0, -1 and -2. $NAMESPACE below is the namespace LLMWhisperer is installed in, as used throughout the On-Prem Deployment Guide.

# The policy now restricts sources — expect a `from:` block, not just `ports:`
kubectl get networkpolicy -n $NAMESPACE redis -o yaml

# LLMWhisperer can still reach Redis and Sentinel
kubectl exec -n $NAMESPACE deploy/whisperer-backend -- \
  sh -c 'timeout 8 python -c "
import socket
for p in (6379, 26379):
    socket.create_connection((\"redis\", p), 5).close()
print(\"OK\")"'

Expect OK — both ports must succeed, since clients use 26379 to discover the master.

Checking whether Redis has already been taken over

LLMWhisperer always runs Redis in Sentinel mode, where two of the three nodes are replicas by design — so role:slave on a node is the normal, healthy reading and is not evidence of a problem on its own.

We deliberately do not publish a self-check for this. If a Redis in another namespace has taken a node over, the two competing Sentinel quorums — yours and theirs — move it back and forth every few seconds, so any single reading lands on either state at close to even odds. Acting on one sample is as likely to detach a healthy replica — which causes an outage — as to find a real problem.

If you have reason to believe your deployment is affected (unexplained cache loss, or another Redis in the cluster you do not control), contact Unstract support rather than running remediation yourself.

Verifying​

Verifying