Apps – VEEAM Repo & MinIO Object Storage

L’immuabilité prend bien des formes. Si j’ai abordé dans un billet précédent l’immuabilité au sens SE¹ du terme intégré avec VEEAM, aujourd’hui je me suis tourné vers l’immuabilité au sens S3², toujours interfacée avec l’application tierce VEEAM.

Difficile néanmoins de progresser vite sur cette technologie puisque je suis Candide. M’enfin comme l’écrivait Franquin, je vais essayer de décortiquer la techno et son fonctionnement et de présenter ma compréhension de la chose. L’objectif étant naturellement de prouver s’il est possible d’altérer l’inaltérable du stockage objet.

Prérequis

• SE : RHEL, UBUNTU
• Apps : VEEAM B&R 12.1
• Autres :
  • Environnement GNU LINUX Durci
  • VEEAM B&R 12.1 et versions ultérieures
  • License VEEAM Entreprise

Avant Propos

Nous allons commencer par un petit brin d’histoire sur l’interface S3.

Qu’est ce que signifie l’interface S3 ? Il signifie Amazon Simple Storage Service (et oui, Jeff BEZOS in da house !). Contrairement à ce que j’ai pu penser, l’interface n’est pas toute jeune (quoi que vous me direz, le temps c’est relatif, non ?). L’API S3 a été officiellement mis sur le marché en 2006 par Amazon.

L’objectif initial était et reste de proposer à des entreprises un service de stockage de données dans le nuage et de s’assurer de la disponibilité et de l’intégrité de ces dernières. Ouai mais bon en 2006, le cloud c’est pas trop d’actualité, c’est plus l’ère du Personal Computer ? Pour la plèbe, oui, mais nous avons toujours un train de retard avec les grands GAFAM³ et autres sociétés de la tech 🙂

Bref, certaines entreprises décident de stocker leurs données chez Amazon à travers ce nouveau service pour s’affranchir des coûts et inconvénients d’un SI local. En contrepartie, Amazon facture ces dites entreprises au stockage (Go) ainsi qu’au trafic internet à destination de ces données. Depuis, l’usage a littéralement explosé puisque nous ne parlons plus en Gigaoctet, mais de manière commune en Téraoctet voir Pétaoctet et certains plus consommateurs que d’autres en Exaoctet (1 Eo = 1 000 000 000 Go) puisque l’usage du cloud n’est plus restreint à un besoin professionnel mais orienté comme un service à destination des usagers (coucou NETFLIX, SPOTIFY, FACEBOOK, X etc).

La base de l’API S3 est donc de fournir une disponibilité de la data la plus haute possible de manière sécurisé tout en restant le plus flexible possible. L’objectif étant de stocker des quantités phénoménales de données. Dans certains cas, il n’est pas rare de parler de DataLake (Lac de données).

Oui mais alors qu’est ce qu’on stocke ? Principalement tout et rien, c’est à dire des données de sauvegarde, d’archive, des applications, sites webs, contenu multimédia, bases de données, etc. Cependant tous ces types de données pour la plupart répondent à un même usage, le WORM⁴. (C’est un super jeu avec des vers qui se tirent dessus ? Non ça c’est WORMS 🙂 )

WORM signifie Write Once Read Many. Soit dans les faits j’écris une fois les données et je les consulte énormément. Par exemple, je charge une photo sur un réseau social. Je vais l’écrire une fois sur le système puis cette dernière sera visible et accessible de tous. La donnée ne va pas vivre. Sur ce principe, il va alors être possible de définir des algorithmes de segmentation de cette donnée pour garantir un gain d’espace, d’évolutivité, la sécurité de la donnée ainsi que sa disponibilité.

Si nous regardons à la loupe les 4 critères ces derniers permettent :

• Gain d’espace : Compression de la données avec déduplication et dans certains cas de l’eraser coding
• Evolutivité : Possibilité de définir un nouveau stockage et de joindre celui ci au système existant à travers internet.
• Sécurité : Les données sont traduites en objets et stockées à plusieurs emplacements de stockage permettant de reconstruire la donnée en cas de corruption d’un ou plusieurs stockages (sur la base de la reconstruction par parité). Il sera également possible de définir une durée de vie à cette donnée (coucou immutability). J’ai vulgarisé. En réalité, l’objet étant une entité logique, ce dernier est stocké sous forme de fragment… Complexe d’un coup non ? 🙂
• Disponibilité : A partir du critère précédent, si un des serveurs où se trouve ma donnée est HS ou momentanément inaccessible, ma donnée continue d’être disponible car ces données en tant qu’objet sont fragmentées sur d’autres serveurs.

Avant d’aller plus loin, il est important de comprendre que l’interface S3 a tout son sens en tant que SaaS⁵. Néanmoins, cela implique de souscrire à ce service chez Amazon par exemple. Ce n’est pas objectif car je recherche une solution OnPremise pour construire et éventuellement proposer ce service dans mon catalogue de service. C’est pourquoi il a été compliqué de trouver une solution S3 OnPremise totalement « open ». L’une des forces du stockage objet (S3) est sa flexibilité. L’un des inconvénients (selon moi) est comment s’assurer que les données (mes datas à moi) ne sont pas utilisées par autrui, sont bien supprimées etc ? Il faut faire confiance mais aujourd’hui cela ne suffit pas…

Bref, en cherchant un petit peu mais pas trop, j’ai identifié une solution opensource MinIO. C’est avec cette dernière que je vais m’amuser avec le stockage objet.

Théorie

L’une des premières questions que nous pouvons nous poser, Linux Hardened VS S3 ?

Comme j’ai pu le présenter dans un article précédent, l’immuabilité au sens hardened du terme est portée par l’OS⁶ nativement. Toutefois, ce dernier est plus adapté pour la protection des fichiers que des données et le risque se trouve au niveau du compte système (Root). S’il y a escalade des droits et donc contournement des mécanismes de sécurité, il est possible de supprimer les données en retirant l’attribut « i« .

Dans le cas de S3, l’approche est différente car c’est le moteur S3 qui gère l’immuabilité et les données ne sont pas stockées sous forme de fichier mais d’objet. Ainsi, pas possible de supprimer la donnée peu importe que nous soyons administrateur, Trump, Gourou d’une secte ou même une divinité. Toutefois, un acte physique devrait faire y arriver…

Histoire

Comme toujours, mon côté père castor il est important de s’intéresser à l’histoire de MinIO.

MionIO a été fondé en 2014 par Arnand Badu Periasamy, Garima Kapoor et Harshavardhana. L’objectif du projet est de démocratiser le stockage cloud autour de la technologie de stockage objet dans le vaste univers de la communauté OpenSource. C’est ainsi que naît Minimal Object Storage » ou MinIO :).

Une première release ou version voit le jour courant 2017. Durant cette période un changement de licence va être réalisé suite à son essor auprès de la communauté. L’ensemble des technologies est alors protégé par la licence GNU-AGPLv3. L’objectif étant de se prémunir des géants de la tech.

Par la suite, le bras de fer et les contentieux vont commencer. MinIO avec la montée en puissance de KUBERNETES est perçu comme une licorne. MinIO ira jusqu’à révoquer les droits d’usage de NUTANIX sur son service NUTANIX Objects pour violation de licence… Quand il y a du pognon en jeu, cela devient vite le bordel, je l’ai toujours dit… M’enfin. Le pourquoi ? L’usage commercial sans paiement, ça ne passe pas…

2025, MinIO cesse la publication d’images Docker et des binaires précompilés pour les versions communautaires. MinIO devient MinIO AIStor.

Malheureusement, c’est le cas classique d’un projet formidable ouvert à tous qui avec le temps s’enferme dans la génération de profit, de protection intellectuelle. MinIO souhaite avoir comme tous les acteurs de ce monde une part du gateau CLOUD+IA.

S3 versus Linux Hardening

Dans un billet précédent, je ventais par Mont et par Vaux les mérites et robustesses du hardening linux, mais qu’en est il du hardening S3 ?

Je pense que pour répondre à cette magnifique question, il est nécessaire de passer par un tableau (oui j’aime rédiger sous la forme de tableau).

Ce que nous pouvons conclure de cette analyse, S3 est plus à même de protéger les données que le hardening LINUX. S3 permettant une meilleure immuabilité dans le temps et ce dernier est prévu pour cet usage précis. Même si cela fonctionne avec la gestion de l’immuabilité LINUX.

Vous lecteurs, ne pouvez pas savoir la souffrance que cela m’apporte d’écrire de tels mots. J’ai toujours défendu bec et ongles le hardening linux et voyez vous, force est de constater que je suis dans le déni. Tel Pierre CAMBRONNE à la bataille de WATERLOO :

La garde meurt mais ne se rend pas.

Pierre CAMBRONNE

Même si dans mon cas c’est un peu exagéré (mais juste un iota hein 🙂 )

Mécanisme S3

Maintenant que nous savons faire la différence entre le hardening et l’API S3, intéressons nous à comment l’objet est rendu immuable 🙂 Chose que j’ai mise un certain temps à assimiler personnellement et qui je le pense ne doit pas forcément être très claire pour bon nombre d’entre nous.

S3 Comment ça marche ?

Pour faire simple car je rentre dans le détail dans la sous partie suivante, lorsque nous envoyons un fichier vers un média S3, le service S3 va générer un fichier de metadata qui va contenir toutes les informations de la donnée. Puis le fichier va être découpé suivant l’algorithme d’Erasure coding paramétré afin de définir notre donnée avec des blocs de données puis de parité.

Le moteur va alors stocker les donnée en respectant les contraintes de restauration et de disponibilité de la données sur chaque disque puis retournera à l’utilisateur le succès ou non de l’opération. Le stockage des données va se faire dans des Buckets.

La durée de vie de la donnée sera stockée dans le fichier de métadonnées. Ainsi, si je souhaite supprimer une donnée pour laquelle la durée de rétention n’est pas atteinte, lors de l’appel de l’opération de suppression, le moteur va lire le fichier de donnée puis me retourner une erreur 403 Forbidden car je ne réponds pas à la condition d’altération de la donnée.

Plutôt simple non ?

Déroulé d’un appel S3

Architecture S3

Dans la logique, l’architecture que nous devrions mettre en place est la suivante :

• Infrastructure Clustérisé pour MinIO (ring)
• Protection par un certificat si publication du service
• Mise en place de NAT ⁷+ PAT⁸
• Configuration de l’Eraser Coding

Vous comprendrez qu’il n’est pas possible chez moi d’établir un ring.

Un seul argument s’y oppose, un seul ! C’est dangereux. Bah ceux qui n’aiment pas le danger, faut qu’ils choisissent une autre activité.

Nicolas SARKOZY

En l’occurrence, le danger étant ma formidable épouse, je vais choisir une autre solution. Je lui ai déjà pris une partie de son dressing, de la buanderie, je ne suis pas venu ici pour souffrir okay ? 🙂 (Je t’aime chérie, promis je vais faire le ménage).

Donc, pas de VM que du physique. Toutefois, je vous parle d’Eraser Coding. Qu’est que cela vient faire la dedans ? Je pense qu’une sous partie va être nécessaire.

Eraser Coding

L’Eraser Coding est un moyen de protection des données par calcul mathématique plutôt que la copie des données. Cette technologie est bien plus efficace en terme de stockage que le RAID ou la réplication.

Voyons plutôt.

Une donnée est découpée par N blocs de données et M blocs de parité. La configuration EC:M définit alors le nombre de blocs de parité. Exemple : EC:2, 2 blocs de parité.

Chaque bloc de parité est une combinaison linéaire des blocs de données calculée. Ainsi, n’importe quels N blocs parmi les N+M suffisent à reconstruire l’objet entier, que ce soit des blocs de parité ou de données. Si nous avons 4 blocs de données et 2 de parité, 4 blocs sur 6 permettent de reconstruire la donnée.

Les systèmes vont alors distribuer la donnée aléatoirement sur les disques de l’erasure définit. Soit un seul bloc par disque par objet. Aucun disque ne doit contenir deux blocs du même objet, puisque en cas de panne d’un disque, les blocs restants sur les autres disques doivent permettre de recalculer le bloc manquant.

Faisons une petite comparaison avec un RAID5 et RAID6.

Là on n’y voit plus clair, pourtant, il existe une relation à bien assimiler entre le nombre de parités possibles par rapport au nombre de disques. Cette règle est fondamentale et doit être acquise.

Disques Utilisables = Disques Totaux – Blocs de Parité

Espace Utilisables = (Disques Totaux – EC:N) / Disques Totaux

Donc on ne définit pas au doigt mouillé la parité de notre EC.

Je pense (comme dans tous mes billets lorsque j’arrive à la fin de la partie théorique) que nous sommes suffisamment armés pour nous lancer dans la partie pratique. J’ai choisi d’implémenter un stockage S3 pour mon serveur VEEAM.

Pratiques

Nous considérons que nous possédons déjà un Serveur VEEAM ainsi qu’un serveur physique de préférence (mais virtuel fonctionne aussi bien) RHEL⁹ ou UBUNTU/DEBIAN durci au préalable pour notre stockage objet.

Egalement, notre futur serveur de stockage objet (compatible S3) aura une partition dédiée au stockage montée et formatée au format XFS.

Brouillon enregistré.

Naturellement, cela va être un peu short niveau ressource donc je vais adapter en conséquence les paramètres de ma VM à défaut d’avoir un serveur physique dédié pour le stockage S3.

MinIO

Installation

Serveur

Client

Le client va nous permettre d’interagir directement avec notre daemon en ligne de commande.

# curl -L -o /usr/local/bin/mc https://dl.min.io/client/mc/release/linux-amd64/mc

# chmod +x /usr/local/bin/mc
# /usr/local/bin/mc --version

Configuration Système

J’enfonce une porte ouverte. Mais cette étape est importante car elle représente un enjeu majeur de la sécurité de notre serveur de stockage dédié à la sauvegarde et donc de notre système d’exploitation.

Il nous reste alors à créer notre règle sur notre firewall pour accéder à notre interface web. Puis depuis notre navigateur favori d’accéder à notre interface (pour l’instant en http).

A partir de maintenant, nous allons attaquer les choses sérieuses. C’est parti pour les buckets et l’assaut du Colonel Kentucky !

Certificats

Naturellement il va falloir que l’on sécurise un minimum nos services web. Par défaut MinIO utilise le protocole HTTP¹⁰. Pour ce faire je vais me simplifier la tâche en utilisant un certificat auto-signé. J’ai la flemme monstrueuse de passer par un let’s encrypt de me taper des règles de PAT¹¹ entre ma box, mon UTM¹²…

# vim openssl.cnf

Pour ne pas me prendre la tête, je passe dorénavant par des fichiers de configuration tout prêts. Les données les plus importantes étant comme nous pouvons nous en douter les SANs¹³ (et là je ne parle pas stockage, bande de petits malins).

[req]
default_bits = 4096
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = req_ext

[dn]
C = FR
ST = France
L = MACON
O = RONELAB
CN = egapl-minio-01.ronelab.lan

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = egapl-minio-01.ronelab.lan
IP.1 = 10.127.252.250

Nous générons notre clé privée et notre certificat public avec notre bon vieux openssl des familles.

# openssl req -x509 -nodes -newkey rsa:4096 -days 3650 -keyout private.key -out public.crt -config openssl.cnf

Nous créons si ce n’est pas le cas le répertoire home de notre utilisateur de service dédié à MinIO (dans mon cas « minio »), et reste à déplacer les fichiers générés ainsi que l’attribution des permissions pour garantir un minimum de sécurité.

# mkdir -p /home/minio
# mkdir -p /home/minio/.minio
# mkdir -p /home/minio/.minio/certs

# mv public.crt /home/minio/.minio/certs/
# mv private.key /home/minio/.minio/certs/

# chown -R minio:minio /home/minio
# chown -R 700 /home/minio
# chown 600 /home/minio/.minio/certs/private.key
# chown 644 /home/minio/.minio/certs/public.crt

Ne reste alors plus qu’à restart notre daemon et avanti !

# systemctl restart minio

Une chose de plus en moins à réaliser. Passons à la suite. 🙂

Configuration Bucket

La première question est qu’est ce qu’un bucket ? Et je ne parle pas du saut de poulet spaghetti que l’on trouve à KFC M’sieurs Dames. Un peu de sérieux ! (Dixit le gars… C’est le camembert qui dit au curé qu’il est communiste ?)

Un bucket, est un conteneur logique qui va stocker des objets (fichiers et les métadatas). Si nous faisons une comparaison avec un système de fichiers classique nous aurions :

Chaque bucket a sa propre configuration comme :

• Les droits d’accès
• Le chiffrement des objets qui le compose
• Le versionning
• Les règles de cycle de vie (suppression, archivage etc)

Là où nous allons devoir être vigilants va se trouver sur la méthode de création du bucket. En GUI¹⁴ et CLI¹⁵, nous n’avons pas les mêmes options et cela va avoir un impact sur certaines applications et dans mon cas un impact sur VEEAM.
Je ne présenterai que la partie CLI. La partie GUI, il faut RTFM¹⁶… 🙂

CLI

VEEAM

L’article à la base, je l’avais commencé sur VBR¹⁷ 12.1 courant 2024. Puis ayant dû me focaliser sur ma vie professionnelle et personnelle par la suite, je me dois de refaire l’intégralité de l’intégration sur VEEAM 13.0.X, et plus particulièrement sur la VSA¹⁸ 13.0.X <3

S3-Repository

Comme toujours avant de créer un job, il est nécessaire de passer par la phase d’ajout d’un nouveau backup repository.

Dans Backup Infrastructure, sélectionnez Backup Repositories et avec votre plus beau clic droit, choisissez Add… Le type de backup sera de nature Object storage. Il est important de choisir S3 Compatible puis de choisir de nouveau ce dernier (je pense que MinIO est en capacité de prendre en charge du S3 Glacier, mais dans le doute je ne vais pas m’avancer…).

Une fois cette étape passée, nous voilà enfin dans le Wizard pour configurer notre repo S3.

Honnêtement, rien ne change vraiment de l’ajout d’un repo classique mais je trouve toujours sympa d’illustrer mes actions. Cela me donne un côté sérieux. Toujours dans les limites de mon infra, j’ai limité le nombre de tâches parallèles à 1.

Le gros du travail se situe à l’étape 2 Account. Là en tant que service point, saisissez l’url de votre serveur https://egapl-minio-01.ronelab.lan:9000 [/!\ Attention : Je me suis encore fait avoir sur la capture d’écran… Le port pour l‘API S3 est 9000 et non 9001. A bon entendeur..]. Renseignez la location et complétez les credentials. Pour cette étape, lors de notre création en ligne de commande précédemment, les informations vous ont été retournées. Ce sont ces dernières qui sont attendues. Lorsque vous cliquerez sur suivant, dans le cas de certificat SSC¹⁹, il faudra accepter comme d’accoutumé le certificat.

La partie 3, Bucket est la dernière étape qui diffère d’un ajout classique. Il faudra choisir le bucket à partir du bouton Browse. Si par pur hasard vous obtenez un message d’erreur de la part de VEEAM c’est que vous avez surement utilisé le port 9001 et non 9000 :). Choisissez également le répertoire. Si aucun n’est présent, créez en un depuis le wizard. Il est important de comprendre que l’immuabilité est portée par VEEAM et non par MinIO. C’est pourquoi c’est à vous de cocher la fonctionnalité Immutability Settings et de définir la période d’immuabilitée.

Pour les autres étapes du Wizard, c’est de la rando. Je vous laisse poursuivre.

Une fois le wizard terminé, si nous regardons notre infrastructure, nous retrouvons bien notre nouveau repo 🙂 <3

Job Configuration

Pour la création du job, cela va être exactement la même chose que la création d’un job classique. Le seul point qui va diverger (Oh il a écrit verge… Okay cool…) va être le choix du repository S3, et c’est tout…

Toujours pour des problématiques d’infrastructures j’ai volontairement restreint la planification du job. De toute façon, l’Appliance va être archivé d’ici la fin de semaine donc OSEF j’ai envie de vous dire…

Notre job étant créé, place au test 🙂

Tests

Le test est plutôt simple, je vais lancer un job et tenter de supprimer ce dernier depuis la console VEEAM.

Début	Fin

La sauvegarde s’est bien déroulée, donc cela prouve qu’avec le durcissement ANSSI²⁰ et notre configuration de MinIO je n’ai pas fait de me**e. Regardons notre chaine de sauvegarde.

Si je choisis de supprimer le point, vais je pouvoir supprimer le backup ? La réponse est évidemment non mais nous nous devons de vérifier ce point.

J’ai envie d’écrire, la messe est dite. L’immuabilité fonctionne.

Je me suis posé la question comme pour la partie hardened de supprimer les données de mon serveur standalone. La réponse est évidemment oui si j’ai les droits root. Je peux démonter le disque ou supprimer son contenu. Toutefois, et c’est là que je n’ai pas les ressources, mais si c’était un ring je n’aurais pas pu.

J’ai mentionné plus haut que même une divinité ne peut supprimer les données c’est pourquoi je nuance mes écrits. Il sera toujours possible à l’utilisateur, que dis-je administrateur qui a tous les accès de supprimer les données.

Conclusion

Cet article fait partie des premiers que j’ai commencé à écrire en 2024 et puis je l’ai abandonné. Je pense par frustration à l’époque.

J’ai toujours défendu bec et ongle l’immuabilité hardened vis à vis de l’immuabilité S3. Pourtant il convient de reconnaitre de ma part que le Storage S3 offre plus de sécurité. Néanmoins je reste convaincue qu’un repo hardened répond très bien au ESN ayant aux moins deux sites et qui veulent arrêter de s’emm***er avec des rotations de disque dur externe (même si cela reste une solution viable et qui est toujours mieux que rien).

Dans les deux cas, je trouve bien la possibilité dans ces deux cas de pouvoir recycler des équipements (serveurs) considérés comme obsolètes pour des environnements de production pour les utiliser comme repo S3 standalone ou hardened.

Si je devais faire un choix ?

Je répondrai en politicien, avec ma plus belle langue de bois. Cela dépendra du contexte. 🙂 Il faut garder à l’esprit que le Hardened protège plus facilement des ransonmware, des erreurs humaines et des compromissions VEEAM. A l’inverse, S3 est plus adapté contre la suppression logique, la conformité réglementaire, les suppressions depuis VEEAM.

Toutefois, si j’avais continué ma carrière en ESN, j’implémenterais ce type de solution avec 3 nodes « obsolètes » sur le papier en conservant une extension de garantie des équipements et intégrerais MinIO au catalogue de service. Mais ça, c’est si j’étais toujours dans une ESN.

L’une des ouvertures et projet à venir serait de monter un ring sur 3 sites différents…

Finalement, c’est beau et bien de terminer un article plus de deux ans après… 🙂

Le mot de la fin :

Je range un cadeau dans MinIO, le S3 applaudit en IPv6, le bucket éternue, et ma théière me retourne une Error 418. Très joli coup. Vous passez en case Jacob Delafonte.

Erwan GUILLEMARD

Sources

• AMAZON S3
• Apps – VEEAM Repo & Backup Hardened
• LINUX – useradd Man
• MinIO – Install Guide
• MinIO – VEEAMBucket

1. SE : Système d’Exploitation ↩︎
2. S3 : Simple Storage Service ↩︎
3. GAFAM : Google Amazon Facebook Apple Microsoft ↩︎
4. WORM : Write Once Read Many ↩︎
5. SaaS : Software As A Service ↩︎
6. OS : Operating System ↩︎
7. NAT : Network Address Translation ↩︎
8. PAT : Port Address Translation ↩︎
9. RHEL : RedHat Entreprise Linux ↩︎
10. HTTP : HyperText Transfert Protocol ↩︎
11. PAT : Port Address Translation ↩︎
12. UTM : Unified Tread Management ↩︎
13. SAN : Subject Alternative Name ↩︎
14. GUI : Graphic User Interface ↩︎
15. CLI : Command Line Interface ↩︎
16. RTFM : Read The Fucking Manual ↩︎
17. VBR : Veeam Backup et Replication ↩︎
18. VSA : Veeam Software Appliance ↩︎
19. SSC : Self-Signed Certificat ↩︎
20. ANSSI : Agence National de Sécurité des Systèmes d’Informations ↩︎