Skip to main content
Version: v0.0.2

Install on OpenShift

Jafra v0.0.2 supports OpenShift. Workload recordings use an emptyDir volume; only the node Agent needs elevated OpenShift permissions to discover those files under the kubelet path. Opted-in application Pods stay on standard restricted policies.

For a first-time walkthrough, start with Install Jafra on OpenShift in Getting Started. This page covers admin workflows, images, and teardown in more detail.

For the security and SCC model, see OpenShift security and SCCs.

Prerequisites​

  • An OpenShift cluster and a kubectl context (or oc login) that can reach it
  • Images available to the cluster (quay.io/jafra.io/jafra-*:0.0.2 or your registry)
  • cert-manager for webhook TLS (install with the script or ask a cluster admin)
  • Cluster-admin (or equivalent) once to create the custom agent SCC and RoleBindings, unless an admin already applied deploy/openshift/

Confirm the API surface:

kubectl api-resources --api-group=security.openshift.io | head
# or
oc whoami

From the jafra-io repository root:

# Full path: SCC bindings + cert-manager (if needed) + deploy
./install-jafra.sh --target openshift --install-cert-manager

# Images already in the registry; manifests + SCC only
./install-jafra.sh --target openshift --deploy-only

# Remove Jafra from the cluster
./install-jafra.sh --target openshift --teardown

You can also set JAFRA_TARGET=openshift. Defaults use JAFRA_VERSION=0.0.2 and the image tags in the deploy manifests.

Unlike Kind, OpenShift does not build or kind load images. Nodes must pull from the registry (or use imagePullSecrets on the ServiceAccounts).

What the script does on OpenShift​

  1. Detects OpenShift APIs (security.openshift.io).
  2. Ensures namespace jafra-system exists.
  3. Creates custom SCC jafra-agent (and its use ClusterRole) if missing.
  4. Applies RoleBindings that attach SCCs to platform ServiceAccounts (scc-platform.yaml).
  5. Deploys the same controller, analyzer, and agent manifests used on Kind.
  6. Switches the agent to JAFRA_MODE=grpc after the analyzer is ready.

Split admin workflow​

If your team separates cluster-admin and namespace-admin:

Cluster admin (one-time):

kubectl apply -f deploy/controller/namespace.yaml
kubectl apply -f deploy/openshift/scc-jafra-agent.yaml
kubectl apply -f deploy/openshift/scc-platform.yaml
# cert-manager cluster-wide if not already installed

Namespace admin (jafra-system) afterward:

./install-jafra.sh --target openshift --deploy-only

Namespace admin needs create/update on Deployments, DaemonSet, Services, PVC, ServiceAccounts, Secrets, and cert-manager Issuer / Certificate in jafra-system. They do not need a custom SCC for application namespaces.

Verify​

kubectl get pods -n jafra-system -o wide
kubectl get rolebinding -n jafra-system -l app.kubernetes.io/part-of=jafra
kubectl get scc jafra-agent
kubectl get mutatingwebhookconfiguration jafra-controller

Then opt in a workload the same way as on Kind:

kubectl apply -f deploy/examples/auth-cache.yaml

Confirm injection and /jfr-data files, then use the Analyzer API.

Images and pull secrets​

Manifests default to quay.io/jafra.io/jafra-{controller,agent,analyzer}:0.0.2. If the cluster cannot pull publicly, mirror the images and either update the Deployment/DaemonSet image fields or attach imagePullSecrets to:

  • jafra-controller ServiceAccount
  • jafra-agent ServiceAccount
  • default ServiceAccount in jafra-system (analyzer)

Next steps​