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

# Install on OpenShift

> The SecurityContextConstraints that ships with the zero-code chart, why attaching to the privileged SCC is the wrong fix, and how to review it first.

OpenShift is Kubernetes plus an admission layer that will refuse the agent's
DaemonSet unless something grants it the privilege it needs. The chart ships
that something.

<Warning>
  **Availability.** The zero-code agent is an early-access distribution. It is
  installable, upgradable and tested, and it is **not yet an integrated part of
  the product**: there is no dashboard page for it, no in-product installer and
  no self-service download. Ask your account contact for access.

  Its telemetry, once flowing, is ordinary OTLP and needs nothing special —
  it appears in Services, Traces and Metrics exactly like SDK telemetry does.
  That is the design rather than a shortcut.
</Warning>

<Info>
  **Read [Install on Kubernetes](/zero-code/kubernetes) first.** Everything
  there applies. This page covers only what OpenShift adds.
</Info>

## Install

```bash theme={null}
helm install aiaxoniq-zerocode ./helm/aiaxoniq-zerocode \
  -n aiaxoniq --create-namespace \
  --set endpoint="$OIQ_ENDPOINT" \
  --set licenseKey="$OIQ_LICENSE_KEY" \
  --set clusterName=prod-eu \
  --set openshift.enabled=true
```

`openshift.enabled=true` creates a minimal `SecurityContextConstraints` and
binds it to this release's ServiceAccount.

## What the constraints grant

|                            |                                                   |
| :------------------------- | :------------------------------------------------ |
| `allowPrivilegedContainer` | **false**                                         |
| Host PID access            | Granted — required, or the agent sees only itself |
| Capabilities               | Exactly the chosen profile's set, no more         |
| Bound to                   | **This release's ServiceAccount, by name**        |

<Note>
  **Bound to a ServiceAccount, not to a group.** A constraints object attached
  to a group applies to every workload that lands in it, now and in future.
  Binding by ServiceAccount name means this grant covers this agent and nothing
  else — including nothing you deploy next year.
</Note>

## Why not just use the privileged SCC

Without the shipped constraints, OpenShift denies the DaemonSet. The usual
workaround is to attach the workload to the cluster's built-in `privileged`
SCC, and it does make the error go away.

<Warning>
  **`privileged` grants far more than the agent needs, and permanently.** It
  allows privileged containers, host namespaces, arbitrary volume types and any
  capability — a superset of the six the agent asks for, with no relationship
  to what it actually uses.

  The shipped constraints exist precisely so that "make it start" and "grant it
  root-equivalent access on every node" stop being the same action. If your
  cluster administrator is going to review one thing, this is it.
</Warning>

## Review it before applying

Render everything the chart would create and read the constraints object
directly:

```bash theme={null}
helm template aiaxoniq-zerocode ./helm/aiaxoniq-zerocode \
  --set endpoint="$OIQ_ENDPOINT" --set licenseKey=dummy \
  --set openshift.enabled=true \
  | grep -B2 -A20 'kind: SecurityContextConstraints'
```

Nothing about the deployment is opaque, and a cluster administrator should not
have to take a documentation page's word for the grant. See
[Security model](/zero-code/security).

## Profiles on OpenShift

The same constraint as ordinary Kubernetes applies: **profile A is not
available**, because it cannot be expressed through the upstream chart. Use B,
which is the default and is designed to be sufficient on its own.

Profile C additionally needs host networking, which is a materially larger ask
on OpenShift than elsewhere — raise it with your cluster administrator before
planning around it. See [Capability profiles](/zero-code/profiles).

## Node prerequisites

The `kernel.perf_event_paranoid` requirement applies to OpenShift nodes as it
does everywhere. On a cluster where you do not manage node sysctls directly,
this is a machine-config change and is worth arranging **before** the install
rather than after — the failure it produces is silent, so it costs an
afternoon to diagnose from the symptom.

See [How eBPF works](/zero-code/ebpf#the-setting-that-catches-everyone).

## Next

<CardGroup cols={3}>
  <Card title="Security model" icon="shield-halved" href="/zero-code/security">
    The document to forward to whoever approves this.
  </Card>

  <Card title="Verification" icon="circle-check" href="/zero-code/verification">
    Confirm data is arriving.
  </Card>

  <Card title="Troubleshooting" icon="triangle-exclamation" href="/zero-code/troubleshooting">
    Symptom to cause to fix.
  </Card>
</CardGroup>