The Security & Access chapter covers how our engineers reach your systems. This chapter covers what the platforms themselves do: KubeAid on Kubernetes clusters and LinuxAid on Linux servers. Every control below is configured in Git, and where a control is opt-in rather than on by default, we say so.
Every cloud and bare-metal cluster kubeaid-cli builds runs Cilium. The kubeaid-addons chart can render a default-deny CiliumNetworkPolicy per namespace, which turns off ingress and egress for every pod in it, apart from DNS to kube-dns. Where a workload needs more, you name the pods that get it. Cilium exports every dropped packet as a Hubble metric.
On bare metal you can switch on the Cilium host firewall. It limits what the nodes themselves answer, and SSH from outside the cluster then answers only the sources you list in values-cilium.yaml. On Hetzner bare metal, kubeaid-cli offers to switch it on at the end of the build. On AWS and Azure the provider's security groups do this job, and on cloud clusters the host firewall stays off.
KubeAid ships two runtime engines, off until you switch one on for a cluster. Tetragon records process execution, kernel module loads and privilege changes as kernel events over eBPF, and follows network and file access once you add a policy for it. KubeArmor can refuse an operation at the Linux Security Module hook before it runs.
When you switch on vulnerability scanning, Trivy Operator scans the images your workloads run and keeps the critical and high findings that have a fix as report objects in the cluster. Kubescape can take its place. Secrets live encrypted in the cluster's Git repository, sealed to the key of the cluster that may open them, and only the controller inside that cluster can decrypt them. kubeaid-cli installs that controller while it builds the cluster.
A NetworkPolicy whose selector matches nothing looks protected in Git and leaves the pod open. So, where you switch it on, KubeAid reads what Cilium computed for each pod and reports, per workload:
Where Cilium has not filled in the endpoint status, the answer is null, meaning unknown. The collector creates nothing and changes nothing. Where your cluster reports to Obmondo, it sends the snapshot over mTLS, with workload names, the images they run and their findings, but no application data, logs or secret contents.
Once an hour, an OpenVox agent on each server compares the server with its settings in Git and reports what has drifted. The installer sets the agent to report-only. Enforcement is a switch per class, and the hourly run corrects the classes where it is on, plus a few files LinuxAid always keeps in place, such as the SSH server configuration. The firewall, database and web settings have no such switch. They apply only when someone runs linuxaid-cli run-openvox --enforce.
On a fully managed server, the hourly run writes a hardened SSH configuration even while LinuxAid only reports on the rest, and SSH uses it from its next restart:
You can add a NetBird or WireGuard VPN to reach your servers over a private network.
With the firewall switched on, each enforcing run sets the server's IPv4 iptables rules from Git:
User accounts, groups, SSH keys and sudo rights for each server live in Git, with password hashes and expiry dates. LinuxAid reports SSH keys that are not in Git, and once it enforces, it removes them from the accounts it manages and from root. pam_access can limit who may log in and from where.
Each server sends its metrics every 15 seconds over TLS to Obmondo's Prometheus and identifies itself with its OpenVox certificate.
Security texts often read as if every switch were already on. Here is where ours are not.