> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensormesh.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Install on OpenShift

> OpenShift overlay for the Tensormesh Operator — handles the privileged SCC required by hostIPC.

The Tensormesh Operator installs on OpenShift the same way it does on vanilla Kubernetes —
with one extra flag. This page covers what that flag does and when you would manage the
underlying ServiceAccount yourself.

<Note>
  Read this **after** [Install with Helm](/operator/installation/helm). The OpenShift
  overlay is additive — it does not replace the Helm install steps.
</Note>

<Note>
  The chart is distributed through a private registry. Request an access token from the
  Tensormesh team, then authenticate before installing — see
  [Install with Helm → Install](/operator/installation/helm#install).
</Note>

## Why OpenShift needs extra config

Engine pods request `hostIPC` so the LMCache cache server can share memory with vLLM
worker processes outside the pod. On OpenShift, `hostIPC` is forbidden by the default
`restricted-v2` Security Context Constraint (SCC) — the engine pod will refuse to start.

To allow it, the engine pod must run as a ServiceAccount bound to an SCC that permits
`hostIPC`. The built-in `privileged` SCC satisfies this.

The chart handles all of that when you set `openshift.enabled=true`:

<Steps>
  <Step title="Creates a dedicated ServiceAccount">
    In the engine's namespace, named `<release>-engine-privileged` by default.
  </Step>

  <Step title="Binds it to the privileged SCC">
    Via a `RoleBinding` to the built-in `system:openshift:scc:privileged` ClusterRole.
  </Step>

  <Step title="Wires the engine CR to use it">
    Renders the `LMCacheEngine` CR with `spec.serviceAccountName` pointing at the new SA —
    so the operator generates pods that run under it.
  </Step>
</Steps>

## Install

Create `values-openshift.yaml` — pin **explicit image tags** (never `latest`):

```yaml values-openshift.yaml theme={null}
openshift:
  enabled: true

# The operator image is supplied by the chart version (--version 0.4.5) — nothing to pin here.
engine:
  enabled: true
  spec:
    l1:
      sizeGB: 60
    image:
      repository: lmcache/vllm-openai
      tag: v0.4.5                      # pin explicitly (matches chart version)
      pullPolicy: IfNotPresent
```

```bash theme={null}
oc new-project tensormesh-operator

helm install tensormesh-operator \
  oci://ghcr.io/tensormesh-production/charts/tensormesh-operator \
  --version 0.4.5 \
  --namespace tensormesh-operator --create-namespace \
  -f values-openshift.yaml \
  --wait
```

## Verify the SCC binding

```bash theme={null}
# The privileged SA exists in your namespace
oc get sa -n tensormesh-operator | grep privileged

# The RoleBinding to the privileged SCC ClusterRole is in place
oc get rolebinding -n tensormesh-operator -o wide | grep privileged

# The engine CR points at that SA
oc get lmcacheengine -n tensormesh-operator \
  -o jsonpath='{.items[0].spec.serviceAccountName}{"\n"}'

# Engine pod is Running, not CreateContainerError
oc get pods -n tensormesh-operator -l app.kubernetes.io/component=cache-engine
```

## Bring your own ServiceAccount

If your organization manages privileged ServiceAccounts centrally — for example, created
by a platform team via OpenShift Operators or external policy tooling — you can opt out of
the chart creating one and point the engine at an existing SA:

```yaml values-openshift.yaml theme={null}
openshift:
  enabled: true
  serviceAccount:
    create: false
    name: my-existing-privileged-sa    # must already exist in the engine namespace
                                       # and already be bound to a privileged SCC

engine:
  spec:
    serviceAccountName: my-existing-privileged-sa
```

<Warning>
  When `openshift.serviceAccount.create: false`, the chart does **not** verify the SA
  exists or has the right SCC binding. A misconfiguration here surfaces as the engine pod
  failing to start with an admission error.
</Warning>

## What "privileged" actually means here

The `privileged` SCC grants more than just `hostIPC` — it also permits running as root,
host networking, and other elevated capabilities. The engine pod only uses `hostIPC`; the
rest is unused but available.

If your security posture forbids the built-in `privileged` SCC, define a custom SCC that
grants only `hostIPC` (plus whatever else your environment requires) and point the chart
at the ClusterRole that authorizes its use:

```yaml theme={null}
openshift:
  enabled: true
  sccClusterRole: my-org:scc:hostipc-only
```

The chart will create the SA and the binding against your custom ClusterRole instead.

## Next steps

<CardGroup cols={2}>
  <Card title="Helm install reference" icon="ship-wheel" href="/operator/installation/helm">
    Full install, upgrade, and uninstall flow.
  </Card>

  <Card title="Troubleshooting" icon="stethoscope" href="/operator/installation/troubleshooting">
    `CreateContainerError`, permission-denied, and SCC diagnostics.
  </Card>
</CardGroup>