Ports and Privileges

What a running Racora opens on its nodes and in the cluster, and which of its workloads the Kubernetes Pod Security levels forbid. The Open5GS rows apply when the Open5GS core provider runs; an external core runs none of them.

Ports

What listens, and where. Nothing below authenticates on its own; what a host or a NodePort exposes is yours to fence.

Port	Where	What
6443/TCP	control node host	the k3s API server (k3s platform); the join token authorises workers. Between nodes k3s also needs 8472/UDP (flannel VXLAN) and 10250/TCP (kubelet), per k3s's networking requirements
30300/TCP	every node (NodePort)	Grafana, readable by anyone as the anonymous Viewer; the login, what does not persist, and how to keep it private are on Read Logs, Traces, and Metrics
9999/TCP, 27017/TCP	control node host network	the Open5GS WebUI and MongoDB. MongoDB binds 127.0.0.1. The WebUI binds the address the node's hostname resolves to, the loopback alias 127.0.1.1 on a stock Ubuntu host; check with ss -ltnp | grep 9999, and reach it over ssh -L 9999:127.0.1.1:9999 <control node> (Open5GS)
38412/SCTP, 2152/UDP	control node host network	the Open5GS core (NGAP and GTP-U): the provider runs hostNetwork, so its AMF and UPF ports are the host's
38472/SCTP, 38462/SCTP	cluster-internal (ClusterIP)	CU-CP F1-C and E1
8001/TCP	cluster-internal	the CU-CP metrics and runtime-command WebSocket, unauthenticated
8001/TCP	each cell's Service du-<cell> (ClusterIP, distributed-unit namespace)	the DU's own metrics and runtime-command WebSocket, unauthenticated (Runtime Commands)
830/TCP	each cell's Service du-<cell>, the Services cu-cp and cu-up	the element's O1 NETCONF server (SSH), the account of the o1-netconf-account Secret, host key of the o1-hostkey Secret; both generated by the racora-controller chart into the DU and CU namespaces, the account also into racora-system, where the controller mounts it and reads every element's datastore on this port, at the pod's address (O1 and the SMO Functions); on an ofh DU's host network the port is the node's
5056/TCP	every element pod (on an ofh DU's node host network)	the o1 sidecar's HTTP endpoints (/status, /config-healthy: the gNB container's liveness), unauthenticated; the port is racora-controller.o1.httpPort for the DUs, racora-cu.o1.httpPort for the CU planes
2152/UDP	the CU-UP pod IP	NG-U (N3) toward the UPF; an external UPF must reach it (Configure the 5G Core)
2153/UDP	the CU-UP pod IP	F1-U from the DUs
2000/TCP	a zmq DU's Service	the transmit side of a virtual radio (How Radios Are Driven)
8001/TCP	an ofh DU's node host network	the DU's WebSocket: the DU runs hostNetwork, so its Service du-<cell> resolves to the node, one ofh cell per node
2152/UDP	an ofh DU's node, on the address the node routes toward the CU-UP pod	the DU's F1-U: the port the CU-UP sends downlink to, on an address a UPF on the same node does not hold
8080/TCP	the racora-controller pod	kopf's health endpoint (/healthz), served from the operator's event loop and probed by the kubelet: a controller that stops answering is restarted (racora-controller.livenessProbe); unauthenticated, not exposed by a Service
5055/TCP	an ofh DU's node host network, with an M-plane session	the mplane sidecar's HTTP endpoints (/ru/status, /ru/ready, the DU's startup gate), unauthenticated; the port is the controller's mplaneHttpPort
4334/TCP	an ofh DU's node host network, with ofh.mplane.callHome	the sidecar's NETCONF call-home listener the O-RU dials
67/UDP	a fronthaul-ready node's fronthaul port, untagged and on every VLAN tag	the fronthaul agent's DHCP server for the node's O-RUs (The Fronthaul Agent); it answers only MACs the cells name
9478/TCP	a fronthaul-ready node's host network	the fronthaul agent's /metrics (Prometheus text) and /healthz, unauthenticated; the port is racora-node.nodePlugins.fronthaul.metricsPort
8815/TCP	cluster-internal	the CU-IP Flight endpoint
4317, 4318/TCP	cluster-internal	the OpenTelemetry collector (OTLP); Tempo and ClickHouse behind it
8080/TCP	cluster-internal (racora-smo)	the O1 collector: VES events and the PM stream from the O1 adapters; the element is the basic-auth username, the password unchecked unless racora-smo.collector.ves.auth is verify (O1 and the SMO Functions)

Namespaces and Privileges

The chart creates seven namespaces: racora-system, centralized-unit, distributed-unit, 5g-core, user-equipment, monitoring, racora-smo. Four of them run workloads the baseline Pod Security level forbids:

Namespace	Why
centralized-unit	CU-CP and CU-UP add the SYS_NICE, IPC_LOCK and PERFMON capabilities; their pods set fsGroup: 1000 for the unprivileged NETCONF sidecar
distributed-unit	every DU adds the same three capabilities; a USRP DU also claims the USRP device and runs on isolated cores; an Open Fronthaul DU runs hostNetwork with NET_RAW and NET_ADMIN, mounts /etc/racora from the node and, with an M-plane session, the cell's credentials Secret. Every DU pod runs its netconf sidecar unprivileged (uid 1000) and sets fsGroup: 1000 so it can read the two O1 Secrets
5g-core	the Open5GS provider runs hostNetwork and privileged
racora-system	the USRP device plugin is privileged (it mounts the kubelet's device-plugin socket and /sys/bus/usb); the fronthaul agent runs on the host network with NET_RAW (the raw socket its DHCP server and probe use on the fronthaul interface) and NET_ADMIN (the VLAN sub-interface and route for an O-RU's M-plane, and the port's link settings), mounts the kubelet's device-plugin directory, /etc/racora and /run/racora (the host's PTP status) read-only, reads NRCells and ConfigMaps and may post Events

On the k3s platform no Pod Security level is enforced by default. On a cluster that enforces baseline, exempt these four namespaces before installing. Under restricted, exempt every Racora namespace: no Racora workload sets the non-root user, seccomp profile and dropped capabilities that level demands.

Service Accounts and What They May Do

Most of Racora runs without talking to the Kubernetes API at all: the CU-CP, CU-UP, every DU and the core pods use their namespace's default service account and are given nothing. The device plugins talk to the kubelet over its socket on the node, not to the API. Five identities do use the API, each with the least it needs, created by the charts (so a cluster you run must let the installing identity create ClusterRoles and Roles, which helm does as whoever runs it):

Identity	Namespace	May	So that it can
racora-controller (ClusterRole of the same name)	racora-system	read CRDs and namespaces; read, patch and update nrcells and their status; manage ConfigMaps, Deployments and Services; create Events; get, list and delete pods	reconcile cells into DU Deployments and the CU-CP overlay, write a cell's status and Events, replace an ofh DU pod whose DU restarted or whose O-RU went unreachable, and keep each element's O1 datastore snapshot (o1-snapshot-<element> ConfigMaps); the O1 account it uses toward the elements is a mounted Secret, not an RBAC grant
racora-core-controller (ClusterRole, plus two Roles)	racora-system; Roles in racora-system (Secrets, read) and in the core namespace (ConfigMaps and pods read, pods/exec)	read CRDs and namespaces; read, patch and update subscribers and their status; read the SIM Secrets; read the provider's declaration and run the adapter in the core pod	provision a Subscriber into the selected core
fronthaul-agent (ClusterRole racora-fronthaul-agent)	racora-system	read nrcells and ConfigMaps; create Events	know which O-RUs the node's cells name and their radio profiles; report an O-RU no cell names (The Fronthaul Agent)
cuip (ClusterRole of the same name)	centralized-unit	read nrcells	know the cells it reasons about (The Intelligence Plane)
otel-collector (Role otel-collector-scrape)	monitoring; the Role in racora-system	read pods in racora-system	find the fronthaul agents to scrape (Read Logs, Traces, and Metrics)

Nothing here may read Secrets except the core controller, and only the SIM Secrets in its own namespace; the O-RU account a cell names (ofh.mplane.credentialsSecret) reaches the mplane sidecar as a mounted volume, not through any identity's read access. Nothing may write to nodes. The exact rules are the charts' RBAC templates (charts/*/templates/*rbac*.yaml, charts/racora-node/templates/fronthaul-agent.yaml, charts/racora-monitoring/templates/otel-collector-rbac.yaml), and kubectl auth can-i --as=system:serviceaccount:<namespace>:<name> <verb> <resource> answers any question about them on a live cluster.