Glossary & concepts

Concepts

Short explanations of concepts used across the test plans — networking, storage, secrets management, and more — for anyone who does not work with them every day.

macvtap (NOT supported) vs. OVN-K localnet (official path)

macvtap gives a VM its own MAC — but is NOT officially supported in OpenShift Virtualization. The correct approach is OVN-K localnet.

WaitForFirstConsumer (StorageClass binding mode)

A PVC stays deliberately 'Pending' until a pod/VM actually uses it — not an error!

NodeNetworkConfigurationPolicy (NNCP)

Declarative node network configuration via the Kubernetes API — instead of manual nmcli commands.

OVN-Kubernetes & br-ex

OpenShift's default network plugin uses an OVS bridge (br-ex) that takes over the physical NIC.

HCP: does every hosted cluster need its own public IP?

No — only the API server (with the KubeVirt/on-prem provider) needs a dedicated IP or dedicated port. OAuthServer, Konnectivity, and Ignition already share the management cluster's existing Ingress route today.

Sealed vs unsealed — why pods stay 0/1 Ready

A sealed OpenBao holds only encrypted data and refuses almost every request — the pod runs but is not Ready. Unsealing reconstructs the barrier key.

KV v2 — versions, soft delete, and check-and-set (CAS)

KV v2 keeps a version history per secret and can require a version number on every write — a write is a whole new version, not a field update.

Kubernetes auth method — SA token in, OpenBao token out

Pods authenticate with their projected ServiceAccount JWT; OpenBao validates it against the kube-apiserver and returns a short-lived token carrying the role's policies.

The pod sends its ServiceAccount JWT to auth/kubernetes/login. OpenBao does not verify the JWT itself — it asks the kube-apiserver via the TokenReview API whether the token is valid and live. It then checks the named role: bound_service_account_names AND bound_service_account_namespaces must both match, otherwise login is denied. On success the pod receives an OpenBao token with the role's policies and TTL. No password, no static credential in the pod: identity comes from Kubernetes, authorisation from the role → policy mapping.

Login handshake for TC-OPENBAO-AUTH-001 and every integration that uses Kubernetes auth (ESO, CSI, injector, cert-manager).

✓ ADVANTAGES

No secrets needed to fetch secrets — the SA token is already there
Namespace + SA binding gives per-workload identity (basis of the TC-OPENBAO-UC-003 tenant isolation)
Short TTLs limit blast radius; tokens renew automatically in agents

⚠ LIMITATIONS

auth/kubernetes/config must be redone if the cluster CA or API endpoint changes
A role bound too widely (e.g. wildcard namespaces) silently broadens access
Disabling the auth method invalidates every dependent integration (ESO, CSI, injector, cert-manager)

OpenBao vs Vault — why /vault/ still appears everywhere

OpenBao is the Linux Foundation fork of HashiCorp Vault and keeps API and tooling compatibility — so UI routes, sidecar paths, and third-party integrations still say 'vault'.

Raft integrated storage — leader, quorum, snapshots

OpenBao stores data itself and replicates it with the Raft consensus protocol — no external database, but quorum rules apply.

📚 Glossary & concepts

Glossary & concepts