Skip to content

Services

Gateway

Haproxy

HAProxy is a free and open source software that provides a high availability load balancer and reverse proxy for TCP and HTTP-based applications that spreads requests across multiple servers.

Haproxy load-balances all incoming http and https traffic from the Internet (ports 80 and 443) onto the traefik host ports published by klipper-lb on every cluster node (workers preferred, masters as backup), in TCP/TLS-passthrough mode — TLS terminates at traefik inside the cluster. It also load-balances Kubernetes api server traffic on the local network (port 6443) onto the master nodes. An ACL rule is defined to accept only local network IP address requests for the api server.

The web interface lets you view the health status of every backend node on both types of endpoints (server api and internet traffic).

Pi-Hole

Pi-hole is a Linux network-level advertisement and Internet tracker blocking application which acts as a DNS sinkhole and optionally a DHCP server, intended for use on a private network. It is designed for low-power embedded devices with network capability, such as the Raspberry Pi, but can be installed on almost any Linux machine.

Pi-hole has the ability to block traditional website advertisements as well as advertisements in unconventional places, such as smart TVs and mobile operating system advertisements.

Using the web interface, you can enable/disable ad and tracker blocking, add a list of domains to be blocked, and configure local network DNS settings (and DHCP if required). It is also possible to view statistics on blocked domains according to the privacy rules set.

Wireguard

WireGuard is a communication protocol and free and open-source software that implements encrypted virtual private networks (VPNs), and was designed with the goals of ease of use, high speed performance, and low attack surface.

Wireguard's web interface lets you create / delete / activate / deactivate VPN users, download their configuration file and display the user's QrCode. With this user configuration file, a user can access the homelab network to perform an ssh connection to the machines and then request the Kubernetes api server.

CrowdSec

CrowdSec is an open-source security engine that analyses logs from various sources (HAProxy, sshd, syslog) and detects malicious behaviour using community-curated scenarios. Detected attackers are blocked at the network level via an nftables firewall bouncer.

The gateway deployment runs the CrowdSec engine as a Docker container with the following collections:

  • crowdsecurity/linux — SSH brute force, bad user agents, port scans
  • crowdsecurity/sshd — SSH-specific attack patterns
  • crowdsecurity/haproxy — HTTP abuse through the load balancer
  • crowdsecurity/base-http-scenarios — generic HTTP attacks (scanners, exploits)
  • crowdsecurity/http-cve — known CVE exploit patterns

A separate Kubernetes deployment (CrowdSec Helm chart) provides cluster-wide monitoring via a DaemonSet agent that parses the traefik JSON access logs.

Access

Gateway web interface services are deployed and accessible for admin purpose, they are available on local network at :

NameUrl
Haproxy dashboardhttp://192.168.1.99:8404
Pihole dashboardhttp://192.168.1.99:5353
Wireguard dashboardhttp://192.168.1.99:51821

Notes: Replace 192.168.1.99 with the gateway's ip address set in hosts.yml.

Kubernetes

Services

The app catalog under argo-cd/apps/ provides the following charts; each instance enables its own subset via the enabled flag in its core.yaml / tenant.yaml catalogs :

NameDescriptionHelm chart
Actions-runner-controllerGithub Actions runners controlleractions-runner-controller/actions-runner-controller
ArgoCDGitOps continuous delivery toolargo/argo-cd
Argo-workflowsWorkflow automation engineargo/argo-workflows
Cert-managerCloud native certificate managementcert-manager/cert-manager
Cloud-native-postgresCloud native postgres database managementcnpg/cloudnative-pg
CoderRemote selfhosted development environmentscoder-v2/coder
CrowdSecOpen-source security engine & threat detectioncrowdsec/crowdsec
HomepageHome dashboardunknowniq/homepage
GiteaPrivate, Fast, Reliable DevOps Platformgitea/gitea
HarborCloud native registrybitnami/harbor
TraefikIngress controller & Gateway API implementationtraefik/traefik
KeycloakSingle Sign On servicecloudpirates/keycloak
KyvernoKubernetes policy engine (admission control)kyverno/kyverno
LonghornCloud native distributed block storagelonghorn/longhorn
MattermostChat service with file sharing and integrationsmattermost/mattermost-team-edition
MLflowML experiment tracking and model registrycommunity-charts/mlflow
OutlineShare notes and wiki with your teamlrstanley/outline
Prometheus-stackOpen-source monitoring solutionprometheus-community/kube-prometheus-stack
RustFSHigh Performance Object Storage-
SonarqubeCode quality analysis servicesonarqube/sonarqube
SopsSecret manager that decode on the flysops-secrets-operator/sops-secrets-operator
System-upgrade-controllerK3S upgrade controller-
TeleportSecure access and identity for infrastructureteleport/teleport-cluster
Trivy-operatorKubernetes-native security toolkitaqua/trivy-operator
VaultSecret management service (standalone chart)hashicorp/vault
Vault-operatorBank-Vaults operator (HA Vault cluster) + VSObank-vaults/vault-operator + hashicorp/vault-secrets-operator
VaultwardenPassword management servicevaultwarden/vaultwarden

Versions

All services helm charts and versions are managed through ArgoCD ApplicationSets with configuration stored in:

Management

Services are managed by a two-level ApplicationSet hierarchy declared by the ohmlab chart in the argocd-system namespace:

  • The root manager AppSet discovers each instance folder and emits one Application per instance pointing at the instance-manager chart.
  • That chart renders two child AppSets per instance — core-<instance> (platform tier, bound to admin-core AppProject) and tenant-<instance> (apps tier, bound to admin-tenant AppProject).

To enable or disable a service, edit the relevant entry in argo-cd/instances/homelab/core.yaml or tenant.yaml and flip enabled: "true" / enabled: "false".

Access

Kubernetes services that are available through user interfaces are centralized on the Homepage dashboard. Platform (core) services live under the core. subdomain; tenant apps sit directly under the root domain :

Core (platform)

NameUrl
ArgoCD (core)https://gitops.core.domain.com
Keycloakhttps://sso.core.domain.com
Longhornhttps://longhorn.core.domain.com
Teleporthttps://teleport.core.domain.com
Vaulthttps://vault.core.domain.com

Tenant (apps)

NameUrl
ArgoCDhttps://gitops.domain.com
Giteahttps://git.domain.com
Grafanahttps://monitoring.domain.com
Homepagehttps://domain.com
Mattermosthttps://mattermost.domain.com
RustFS - apihttps://s3.domain.com
RustFS - consolehttps://console.s3.domain.com

Notes: Replace domain.com by your own domain configured in your values files. Optional catalog apps (Coder, Harbor, Outline, SonarQube, Vaultwarden, ...) follow the same pattern when enabled.

Single sign on

Keycloak is deployed as the cluster single sign-on tool. It provides a single account (username / password pair) that grants access to multiple services, and propagates user groups to control access levels.

Users and access levels are managed via the Keycloak interface (cf. keycloak service url) using the admin credentials from Vault (keycloak.username / keycloak.password under the keycloak secret path).

Don't forget to select the homelab realm.

A default admin group grants admin-level access on every connected service; users not in this group get standard access.

Services currently connected through SSO (client secrets are stored in Vault and delivered by VSO):

  • ArgoCD (core + tenant instances)
  • Gitea
  • Grafana
  • Longhorn
  • RustFS (console OIDC)
  • Vault

Optional catalog apps (Coder, Harbor, Outline, SonarQube, ...) ship with the same Keycloak OIDC wiring and join the list when enabled.

Secrets

Secrets are sourced from Vault and synced into Kubernetes by the Vault Secrets Operator (VSO). Each chart that needs secrets depends on the vso-utils subchart, which renders VaultStaticSecret custom resources pointing at a Vault path.

VSO talks to Vault over TLS and validates the server against a vault-ca secret present in every app namespace. That secret is distributed by the Kyverno sync-vault-ca generate policy, which targets namespaces labelled ohmlab.fr/vault-access=true. The label itself is applied declaratively by the instance-manager ApplicationSets (managedNamespaceMetadata), so it survives namespace re-creation. The whole secret chain silently stops if that label disappearsohmlab check reports failing VaultStaticSecret resources, which is the first symptom.

Each app also gets a dedicated least-privilege Vault policy (homelab/data/platforms/+/+/<app>, read-only) and a Kubernetes auth role bound to the vso ServiceAccount in the app's own namespace — a role bound to the wrong namespace fails with 403 namespace not authorized.

Security policies

Four Kyverno ClusterPolicies guard admissions (see argo-cd/apps/kyverno/templates/):

PolicyActionNotes
pod-security-baselineEnforcePSS baseline; infra namespaces needing hostPath excluded
require-non-rootEnforcerunAsNonRoot; nginx/log-reader namespaces excluded
disallow-latest-tagEnforce:latest blocked; internal tooling images excluded
require-resource-limitsAuditstays Audit — blocking operator-created pods mid-incident is worse than a report

Actions are configurable per instance via policies.<name>.failureAction in the kyverno app values. Exceptions are GitOps-managed: the kyverno PolicyException feature is enabled but restricted to the kyverno namespace, so every exception lives in policy-exceptions.yaml and workloads cannot self-exempt. In-cluster traffic is encrypted wherever the component supports it: CNPG PostgreSQL serves TLS and every client connects with sslmode=require; gitea⇄valkey uses password auth over TLS; Vault and argocd-server serve TLS that traefik verifies upstream via BackendTLSPolicy (Vault against its own CA, ArgoCD against its Let's Encrypt cert); Teleport terminates TLS itself behind a Gateway API TLSRoute passthrough.

Monitoring

The cluster itself and the platform services are monitored using Prometheus and Grafana. Every component that exposes metrics ships a ServiceMonitor/PodMonitor (ArgoCD, Vault, Traefik, cert-manager, CrowdSec, Longhorn, Gitea, Keycloak, CNPG, sops, ...) — roughly 30 monitors across the cluster.

Some dashboards are already delivered with the installation but more can be added in argo-cd/apps/prometheus-stack/grafana-dashboards/, they will be automatically loaded on ArgoCD synchronization via the dashboards.yaml template. Already added dashboards are:

Dashboard fileGrafana dashboard ID
argo-cd.json14584
cert-manager.json20340
cloudnative-pg.json20417
gitea.json17802
harbor.json- ( source )
k3s.json15282
kube-global.json15757
kube-node.json15759
kube-ns.json15758
kube-pod.json15760
longhorn.json13032
trivy.json16337
vault.json12904