Un Talos européen sécurisé de qualité à coût maîtrisé

Talos devient au fil du temps la solution de choix pour déployer des clusters Kubernetes cloud ou bare metal hautement sécurisés et performants. Zéro SSH, API-REST first, à peine une douzaine de binaires embarqués, support chiffrement complet, cet OS est entièrement construit de manière conteneurisée et bootstrappé depuis le projet stagex, permettant un build entièrement reproductible et théoriquement insensible aux attaques supply-chain. Nous allons ici tenter de mettre en place un cluster kubernetes Talos sur des Cloud Service Providers européens (non GAFAM), le plus proche possible du production-grade, sans coût délirant.

Pour qui et pourquoi ? 🤔

Ce guide s’adresse aux devs à fortes inspirations DevOps/GitOps, principalement européens, adeptes du self-hosting, souhaitant s’affranchir des VPS à la papa et s’extirper de notre dépendance aux GAFAM, notamment :

• De leurs coûts délirants, inhérents aux modèles économiques de ces hyperscalers.
• De leur main mise sur nos données du fait du Cloud Act.
• De leur opacité et aspect vendor-locking, du fait de l’intégration dans leur écosystème propriétaire, alors que l’écosystème standardisé Kubernetes offre de sérieuses alternatives via de puissants opérateurs.

En bref :

• Vous pensez avoir avez fait le tour de Dokploy et/ou de tout ce qui est possible de faire à partir des solutions type Docker Swarm, qui reste toujours parfaitement adapté aux besoins simples.
• Vous souhaitez passer au niveau supérieur, basé sur des solutions Kubernetes et vous rapprochez de ce qui se fait de mieux chez les hyperscalers sans pour autant en subir le coût*.
• Aller plus loin que les solutions classiques type k3s / kubeadm montées à l’arrache vite fait sur des Debian abandonnées, et monter votre infra complète entièrement contrôlée en mode GitOps.
• Avoir une chaîne de déploiement CI/CD complète, incluant tous les outils d’observabilité nécessaires.

Le but ici est donc de se rapprocher raisonnablement et à notre échelle de ces hyperscalers sur le triptyque suivant :

• La sécurité, via Zero Trust, chiffrement des données, mTLS, WAF (nous voulons aussi éviter les solutions de facilité tel que Cloudflare).
• La résilience, via haute disponibilité, backups et Plan de Reprise d’Activité (PRA).
• L’observabilité, à tous les niveaux, métriques, logs, traces.

Le sacrifice en échange ?

• Des efforts et du temps…
• Une plus grande part de responsabilité technique.

Les bénéfices :

• Une maîtrise de la stack logicielle complète, infra incluse, du build jusqu’au run.
• Un juste milieu entre les VPS à la papa et les hyperscalers.
• Des coûts 100% maitrisés, aux rapports performances/prix d’un niveau sur lequel aucun CSP ne peut réellement rivaliser.

Et les solutions type OVHcloud ou Scaleway alors ? Très bien, c’est un vrai pas dans la bonne direction, et un excellent compromis entre le GAFAM et le cluster kube tout géré à la main. Si cela répond parfaitement à votre besoin alors nickel, vous pouvez déjà vous arrêter ici !

Mais il reste encore la problématique du coût, que ces Cloud Services Providers ont bien naturellement besoin de marger aux clients du fait du nombre toujours grandissant de services cloud proposés.

Comment ? 🛤️

Ici, ce guide se focalisera sur une seule ressource principale et essentielle : ce bon vieux VPS, mais cuisiné aux petits oignons. Exit les grands CSP multi-services managés, en dehors des S3, DNS, TEM (email transactionnel).

Sur tout ce que j’ai testé, Hetzner Cloud reste le leader incontestable du marché du VPS Cloud européen au rapport performance/prix imbattable, tout en disposant d’une interface UX et API/CLI simple et sans fioritures, uniquement centrée autour des VPS et des volumes. Il ne propose pratiquement aucun autre service managé mis à part le Load Balancer (l’Object Storage n’est d’ailleurs arrivé que très récemment), et c’est à peu près tout ce qu’on lui demande ! Il inclut également un provider terraform simple qui fait super bien son taf sans 15000 ressources à connaître (coucou les providers AWS/AZ).

Comme il est de rigueur, nous n’allons pas mettre tous nos œufs dans le même panier, et utiliserons à ce titre 2 cloud providers différents :

• Hetzner Cloud : l’infrastructure principale, VPS / volumes / Load Balancers
• Scaleway : pour la partie DNS, TEM (serveur de mail transactionnel), et S3, qui sera utilisé pour la partie stockage long-terme (logs / traces) et backups. Scaleway propose depuis très récemment SSE-ONE, un équivalent SSE-KMS assurant le chiffrement automatique côté serveur.

Les objectifs 🎯

• Monter un cluster Talos fonctionnel européen sécurisé, résiliant, et totalement monitoré.
• Tout en self-hosted ou presque, on maîtrise toute la brique infra logicielle.
• Déploiement 100% GitOps via Terraform/OpenTofu puis FluxCD
• Afin de comprendre et maîtriser chaque étape du processus, l’infra est construite en mode pas à pas, sans raccourci ni utilisation d’outil tout-en-un qui fait tout tel que terraform-hcloud-kubernetes.
• Zero Trust de bout en bout, via l’utilisation de Tailscale.
• Cluster construit avec la notion de worker pools, comme chez tous les providers d’infra cloud proposant du kube managé.
• Chiffrement à tous les niveaux (volumes systèmes et externes, backups, s3, réseau pod à pod, mTLS).
• Intégration de Cilium sur la couche réseau physique de l’infra Hetzner.
• Intégration cloud (Network, Nodes et Load-Balancer) avec Hetzner Cloud Controller Manager.
• Solution de volumes distribués et backups via Longhorn.
• Du Ingress avec tout l’attirail qui va bien (cert-manager, Traefik, et CrowdSec en tant que solution WAF incluant analyse comportementale du trafic).
• Un Ingress avec endpoint public via Load Balancer et endpoint privé à travers le réseau Tailscale pour l’accès aux outils internes.
• Un cluster primary/replica PostgreSQL des familles via CloudNativePG, avec backup barman cloud sur s3 chiffré.
• Un cluster Dragonfly (équivalent Redis).
• Observabilité à tous les niveaux, monitoring complet via Prometheus/Grafana, logging et tracing distribué via Loki et Tempo en passant par le collecteur Alloy.
• Mis en place d’une logistique CI/CD via Gitea Action et Flux, avec analyse de code via SonarQube, incluant l’observabilité post-déploiement, au travers d’un exemple de projet .NET API.

Un sacré programme, be brave.

Pré-requis 🛠️

Déjà niveau prérequis ça va demander pas mal d’effort avant de commencer quoi que ce soit :

• Un compte Hetzner Cloud.
• Un compte Tailscale et être connecté sur votre tailnet de travail. Activer Tailnet Lock en option pour le maximum de sécurité, sinon activer au moins l’approbation manuelle d’un nouvel appareil.
• Un service S3 avec fonction de chiffrement SSE-C. Un équivalent SSE-KMS en plus sera idéal, car certains services de backup comme barman cloud ne supporte pas le chiffrement client. On utilisera ici Scaleway. Activer le versioning pour être moins vulnérable aux ransomwares.
• Un nom de domaine avec un accès admin au DNS (on partira sur ohmytalos.io ici). On réservera un sous-domaine int.ohmytalos.io pour l’accès aux outils internes.
• Un compte de mail transactionnel, déjà actif et pré-paramétré sur votre nom de domaine, avec SPF/DKIM et tout le bousin. Si vous n’utiliser pas Scaleway pour la partie DNS, il faudra adapter le provider DNS-01 en fonction pour le challenge ACME.
• Un environnement bash/zsh avec une belle brochette d’outils CLI préinstallés suivants : mise, fnox, sops, age, hcloud, talosctl, kubectl, helm, terraform, packer, flux. On n’est pas là pour déconner. L’utilisation de brew ou encore mieux mise est vivement recommandé pour les installer et mettre à jour facilement.
• Outils complémentaires optionnels pour la productivité sur kube : cilium, cmctl, cnpg (plugin krew), k9s, ktop, kube-capacity, oh-my-zsh avec plugin kubectl pour les alias.

Snapshots 💽

Nous allons avoir besoin d’uploader des images Talos prête à l’emploi pour la création à la volée de nos VPS. Un peu comme propose l’outil hcloud-upload-image, mais je préfère utiliser packer pour une approche plus GitOps.

La 1ère chose à faire est d’aller sur le site officiel de Talos Image Factory afin de construire vos images Talos personnalisées. Vous pouvez également créer un fichier de définition des extensions offline comme nous allons le faire ici.

Dans ce guide, nous allons avoir besoin de 2 types d’images :

1. Une dédiée pour les control planes, contenant l’extension Tailscale pour accéder à nos nodes en mode zero-trust.
2. Une dédiée par défaut pour les workers, sans Tailscale car l’on passera par les control planes pour y accéder, mais avec les extensions nécessaires au bon fonctionnement de Longhorn (iSCSI, util-linux-tools).

Créez-vous un nouveau répertoire projet ohmytalos-cluster puis les 2 fichiers suivants :

1
customization:
2
  systemExtensions:
3
    officialExtensions:
4
      - siderolabs/tailscale

1
customization:
2
  systemExtensions:
3
    officialExtensions:
4
      - siderolabs/iscsi-tools
5
      - siderolabs/util-linux-tools

Récupérer les hashs d’identifiant de l’image comme suit :

curl -s -X POST --data-binary @schematic-cp.yaml https://factory.talos.dev/schematics | jq .id
# 4a0d65c669d46663f377e7161e50cfd570c401f26fd9e7bda34a0216b6f1922b
curl -s -X POST --data-binary @schematic-wk.yaml https://factory.talos.dev/schematics | jq .id
# 613e1592b2da41ae5e265e8789429f22e121aab91cb4deb6bc3c0b6262961245

2 infos importantes à retenir à partir de ce hash :

• Notre image de première installation qui va nous servir pour la création de notre snapshot https://factory.talos.dev/image/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/v1.13.3/hcloud-amd64.raw.xz
• L’URL de l’image OCI pour les opérations d’upgrade factory.talos.dev/hcloud-installer/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:v1.13.3

Pour chaque image, il faut prévoir une pour l’archi amd64, et une autre pour arm64, car l’on pourrait très bien imaginer des node pools sous différentes architectures. Rajouter autant de schematics que nécessaire, par exemple une contenant les drivers spécifiques pour des clusters de nodes GPU. On reflète tout cela dans le fichier packer suivant :

1
packer {
2
  required_plugins {
3
    hcloud = {
4
      source  = "github.com/hetznercloud/hcloud"
5
      version = "~> 1"
6
    }
7
  }
8
}
9

10
variable "hcloud_token" {
11
  type      = string
12
  default   = env("HCLOUD_TOKEN")
13
  sensitive = true
14
}
15

16
variable "schematic_id" {
17
  type    = string
18
  default = "376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba"
19
}
20

21
variable "image_name" {
22
  type    = string
23
  default = "default"
24
}
25

26
variable "talos_version" {
27
  type    = string
28
  default = "v1.13.3"
29
}
30

31
variable "arch" {
32
  type    = string
33
}
34

35
variable "server_location" {
36
  type    = string
37
  default = "nbg1"
38
}
39

40
locals {
41
  server_types = {
42
    amd64 = "cpx22"
43
    arm64 = "cax11"
44
  }
45
  image = "https://factory.talos.dev/image/${var.schematic_id}/${var.talos_version}/hcloud-${var.arch}.raw.xz"
46
}
47

48
source "hcloud" "talos" {
49
  rescue       = "linux64"
50
  image        = "debian-13"
51
  location     = var.server_location
52
  server_type  = local.server_types[var.arch]
53
  ssh_username = "root"
54

55
  snapshot_name   = "talos system disk - ${var.image_name} - ${var.arch} - ${var.talos_version}"
56
  snapshot_labels = {
57
    type         = "infra",
58
    os           = "talos",
59
    version      = var.talos_version,
60
    arch         = var.arch,
61
    name         = var.image_name
62
  }
63
  token = var.hcloud_token
64
}
65

66
build {
67
  sources = ["source.hcloud.talos"]
68

69
  provisioner "shell" {
70
    inline = [
71
      "apt-get install -y wget",
72
      "wget -O /tmp/talos.raw.xz ${local.image}",
73
      "xz -d -c /tmp/talos.raw.xz | dd of=/dev/sda && sync",
74
    ]
75
  }
76
}

Il nous est maintenant possible de construire notre image Talos personnalisée pour chaque architecture. Pour cela, nous allons avoir besoin de préparer notre token API Hcloud secrète dans notre environnement.

1er secret avec fnox et age 🔐

Nous utiliserons fnox pour la gestion de nos secrets locaux, notamment les secrets terraform qui seront chiffrés localement avant d’être poussés sur git. fnox supporte nativement age pour le chiffrement asymétrique, ce qui est idéal pour un cas d’usage simple, et nous allons l’utiliser pour générer notre paire de clés.

# 1. On génère notre clé privée et publique, à conserver précieusement dans votre gestionnaire de mot de passe
age-keygen -o ~/.config/fnox/age.txt

# 2. Récupérer la clé publique pour la config de fnox
grep "public key:" ~/.config/fnox/age.txt

Créer le fichier suivant à la racine de votre projet ohmytalos-cluster en y indiquant votre clé publique.

1
[providers.age]
2
type = "age"
3
recipients = ["age1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"]

Créer un nouveau projet dédié sur Hcloud, générez-y une clé API read/write puis inscrivez-la dans votre environnement.

fnox set HCLOUD_TOKEN "xxxxxxxxxxxxxxxxxxxxx" --provider age

Vérifier avec echo $HCLOUD_TOKEN pour vous assurer que la variable d’environnement est correctement définie.

fnox list | awk '/provider \(age\)/ {print $1}' | while read env_key; do
  fnox set "$env_key" "$(fnox get "$env_key")" --provider age
done

Nous allons maintenant utiliser mise pour automatiser le build de nos images pour nos control planes et workers, créer le fichier suivant pour enregistrer nos tâches de build :

1
[tasks.install]
2
run = "packer init ."
3

4
[tasks.amd64-cp]
5
run = "packer build -var arch=amd64 -var image_name=cp -var schematic_id=4a0d65c669d46663f377e7161e50cfd570c401f26fd9e7bda34a0216b6f1922b ."
6

7
[tasks.arm64-cp]
8
run = "packer build -var arch=arm64 -var image_name=cp -var schematic_id=4a0d65c669d46663f377e7161e50cfd570c401f26fd9e7bda34a0216b6f1922b ."
9

10
[tasks.build-cp]
11
depends = ["amd64-cp", "arm64-cp"]
12

13
[tasks.amd64-wk]
14
run = "packer build -var arch=amd64 -var image_name=wk -var schematic_id=613e1592b2da41ae5e265e8789429f22e121aab91cb4deb6bc3c0b6262961245 ."
15

16
[tasks.arm64-wk]
17
run = "packer build -var arch=arm64 -var image_name=wk -var schematic_id=613e1592b2da41ae5e265e8789429f22e121aab91cb4deb6bc3c0b6262961245 ."
18

19
[tasks.build-wk]
20
depends = ["amd64-wk", "arm64-wk"]
21

22
[tasks.build]
23
depends = ["amd64-cp", "arm64-cp", "amd64-wk", "arm64-wk"]

Plus qu’à lancer mise build et c’est parti pour la construction de tous nos snapshots images Talos en parallèle. À la fin de l’opération, vous devriez obtenir 4 snapshots d’image prêt à l’emploi, visible dans l’onglet “Servers/Snapshots” sur Hetzner Cloud ou plus directement côté CLI via hcloud image list -t snapshot. Pour l’utilisation du CLI, pensez à créer puis activer le contexte auparavant via hcloud context create ohmytalos-dev puis hcloud context use ohmytalos-dev, une clé API uniquement en lecture suffira si vous choisissez la voie 100% terraform à la section 2 de ce guide.

Architecture cloud 🏭

Comme toute architecture kube qui se respecte, et à l’image des kubes managés des hyperscalers, notre IaC devra exprimer la notion de node pools, dans lesquels on indiquera les caractéristiques (type de machine par défaut, volumes, talos config, etc.) puis la liste des hosts. Chaque pool sera dédié à un type de workload spécifique. Dans ce guide, nous allons créer 2 node pools :

1. Un pool de worker : dédié aux workloads applicatifs, dont les nœuds ferons également office de reverse proxy traefik et seront rattachés à un load balancer Hcloud dédié au trafic public.
2. Un pool de stockage : dédié aux workloads type base de données, ainsi que backends de métriques, logs et traces, il sera composé de nœuds avec des volumes rattachés à haute capacité.

Côté choix du type de VPS, l’essentiel est de partir sur 4 Go de RAM (minimum requis) pour les control planes (3 fois pour HA), puis 8 Go de RAM pour les 5 workers, répartis sur les 2 node pools. Ensuite, vous aurez principalement le choix entre 2 typologies niveau performance/prix :

Il faudra y inclure le load balancer lb11 à 6,57€ HT

En imaginant un cluster de staging utilisant l’option 1, et un cluster de production sur l’option 2, vous arriverez très grossièrement à un coût total mensuel TTC de ~200€ en comptant tout. À ce tarif, vous pouvez être certain d’avoir bien plus de performance sous le capot tout en étant largement 10 fois moins cher qu’un équivalent anémique chez les hyperscalers. Le tout en étant maître de votre infra de A à Z, avec les avantages, mais aussi disons-le, les inconvénients que cela comporte.

Architecture réseau 🌐

Avant de continuer, il est vital de bien poser l’architecture réseau de notre cluster. Il s’agit du système nerveux de Kubernetes, difficile de le changer après coup sans douleur, sinon à part le recréer. Nous allons dédier un subnet pour nos control planes et chaque node pool. Ce qui nous donne l’architecture suivante :

Côté configuration Talos, il faudra bien préciser la plage des pods et services dans la section cluster.network :

1
cluster:
2
  network:
3
    cni:
4
      name: none
5
    podSubnets:
6
      - 10.42.0.0/16
7
    serviceSubnets:
8
      - 10.43.0.0/16
9
  proxy:
10
    disabled: true
11
  externalCloudProvider:
12
    enabled: true

* Ne faite rien pour le moment, il s’agit juste d’un élément à garder en tête pour la prochaine section du guide.

Architecture storage 🗄️

Chiffrement des disques 🔐

Le chiffrement sera effectué à tous les niveaux, non seulement côté Longhorn mais aussi côté système grâce au support de chiffrement natif de Talos via LUKS. Nous utiliserons la config indiquée dans la doc officielle. Il existe trois types de volumes à chiffrer, les 2 volumes système STATE et EPHEMERAL, valable sur tous les nœuds, ainsi que le volume utilisateur longhorn spécifique aux volumes Hetzner que l’on rattachera aux nœuds du pool de stockage. Nous aurons donc besoin de déclarer jusqu’à 3 configurations de volumes dans notre fichier de configuration Talos :

1
apiVersion: v1alpha1
2
kind: VolumeConfig
3
name: STATE
4
encryption:
5
  keys:
6
    - nodeID: {}
7
      slot: 0
8
---
9
apiVersion: v1alpha1
10
kind: VolumeConfig
11
name: EPHEMERAL
12
encryption:
13
  keys:
14
    - static:
15
        passphrase: supersecret
16
      slot: 0
17
      lockToSTATE: true
18
---
19
apiVersion: v1alpha1
20
kind: UserVolumeConfig
21
name: longhorn
22
encryption:
23
  keys:
24
    - static:
25
        passphrase: supersecret
26
      slot: 0
27
      lockToSTATE: true

* De même cette partie sera traitée dans la prochaine section.

Nous utilisons des clés statiques en dehors du volume STATE afin de permettre la rotation des clés. Nouveauté de Talos 1.11, nous activons également lockToSTATE pour mixer la clé de chiffrement du volume EPHEMERAL et Longhorn avec un salt propre au volume STATE (utilisation d’une fonction de dérivation au niveau de la clé de déchiffrement). L’intérêt est que ces volumes soient indéchiffrables en cas de perte du volume STATE.

C’est le mode le plus sécurisé possible (en tout cas sur Hetzner Cloud à date), mais le moindre problème ou changement matériel entraînant une éventuelle modification de nodeID peut vous faire perdre l’ensemble des données du nœud. Toutefois l’utilisation de replicas Longhorn limite l’impact de la perte d’un nœud. Comme toujours un vrai backup externe sera toujours d’autant plus indispensable (naturellement chiffré). N’indiquez pas lockToSTATE (false par défaut) si vous préférez garder la possibilité de récupérer vos volumes en cas de perte du volume STATE.

Paramétrage Longhorn 🛠️

Pour automatiser au mieux la configuration des volumes pour Longhorn lors de son installation plus tard, le mieux est de préconfigurer les nodes en amont, via des labels et annotations spécifiques. Ils seront logiquement différents selon que ce soit un nœud de workload ou un nœud de stockage avec disque externe rattaché. Voici ce qu’on est en droit d’attendre comme labels et annotations pour chaque node pool selon notre schéma d’archi :

1
machine:
2
  nodeLabels:
3
    node.longhorn.io/create-default-disk: config
4
  nodeAnnotations:
5
    node.longhorn.io/default-disks-config: '[{"allowScheduling":true,"name":"system","path":"/var/lib/longhorn","tags":["local"]}]'
6
    node.longhorn.io/default-node-tags: '["worker"]'

1
machine:
2
  nodeLabels:
3
    node.kubernetes.io/exclude-from-external-load-balancers: "true"
4
    node.kubernetes.io/role: storage
5
    node.longhorn.io/create-default-disk: config
6
  nodeAnnotations:
7
    node.longhorn.io/default-disks-config: '[{"allowScheduling":true,"name":"system","path":"/var/lib/longhorn","tags":["local"]},{"allowScheduling":true,"name":"volume","path":"/var/mnt/longhorn","tags":["volume"]}]'
8
    node.longhorn.io/default-node-tags: '["storage"]'

On s’assure que seuls les nœuds workers soient rattachés aux loads balancers via le label node.kubernetes.io/exclude-from-external-load-balancers sur les autres pools.

Le label node.longhorn.io/create-default-disk: config permet de personnaliser la configuration par défaut des disques Longhorn via l’annotation node.longhorn.io/default-disks-config. On indique ici au format json que l’on souhaite un disque system local sur chaque nœud et un disque volume supplémentaire sur les nœuds de stockage. Ce dernier devra être monté au préalable sur /var/mnt/longhorn côté Hcloud.

On précise le tag local vs volume pour différencier les types de disques dans Longhorn, notamment pour l’aspect performance. On veut s’assurer en effet que les workloads à forts besoins en IOPS (base de données, etc) soient bien placés sur les disques locaux, plus performant que les disques externe.

On rajoute enfin node.longhorn.io/default-node-tags pour faciliter le placement des futurs volumes.

Conclusion

Voilà pour la partie préparatif, il est temps de commencer pour de vrai à la prochaine section.