Trouver votre première mauvaise configuration en cinq minutes

En cinq minutes, sans compte cloud ni identifiant, vous allez voir Pépin trouver quatre écarts réels dans une configuration, puis les corriger et constater que le verdict bascule. Le dépôt fournit des inventaires d'exemple : un volontairement vulnérable, un corrigé. C'est le meilleur moyen de comprendre ce que l'outil regarde avant de le brancher sur votre propre infrastructure.

Ce que vous allez apprendre

• Lancer un scan et obtenir un verdict non conforme.
• Lire un écart : le contrôle, la ressource en cause, l'observation, la remédiation.
• Corriger les quatre écarts et voir le code de sortie retomber à zéro.
• Reconnaître pourquoi une règle ouverte à Internet n'est pas toujours un écart.

Préparer l'outil

Aucun compte cloud n'est nécessaire pour cette page. Le plus court est de compiler depuis les sources, ce qui demande Go 1.26 ou plus récent :

git clone https://github.com/stephrobert/pepin
cd pepin
go build -o pepin .
./pepin version

La sortie affiche le numéro de version. Si vous préférez un binaire signé, une image de conteneur ou un gestionnaire de paquets, la page d'installation les couvre ; pour découvrir l'outil, la compilation suffit et évite toute question de confiance dans un binaire téléchargé.

Le premier scan

Le dépôt contient un inventaire Scaleway volontairement mal configuré. Il tient en trois ressources : un seau de stockage objet, une clé d'accès et une règle de pare-feu.

./pepin scan scaleway examples/scaleway/inventory.json

La sortie se termine par une synthèse sans ambiguïté :

 Verdict : NON CONFORME

 🔴 CRITICAL 2   🟠 HIGH 2   🟡 MEDIUM 0   🔵 LOW 0

Vérifiez le code de retour, c'est lui qui pilotera plus tard votre chaîne d'intégration :

echo $?

Il vaut 1, ce qui signifie qu'au moins un écart de sévérité critique ou haute a été constaté.

Lire les quatre écarts

Trois ressources ont produit quatre écarts : la clé d'accès en déclenche deux à elle seule, pour deux raisons différentes.

Sévérité	Contrôle	Ressource	Ce qui est observé
CRITICAL	iam_accesskey_expiration_set	la clé d'accès	aucune date d'expiration : une fuite resterait exploitable indéfiniment
CRITICAL	objectstorage_bucket_public_access	backups-prod	une ACL accorde l'accès au groupe global AllUsers
HIGH	iam_no_root_access_key	ci-deploy	la clé est rattachée au compte root, ce qui contourne les politiques IAM
HIGH	network_securitygroup_allow_ingress_from_internet_to_tcp_port_22	sg-1	SSH accepté depuis Internet

Glissez pour voir

Chaque écart est présenté avec sa remédiation, pas seulement son constat :

  Remediation
    Restreindre la règle à des sources/destinations et ports légitimes
    (CIDR d'administration, bastion, VPN) ; ne jamais exposer un service
    sensible à 0.0.0.0/0.

  ↳ docs: https://stephane-robert.info/scsl/CLD-NET-1

Deux façons de nommer le même contrôle

Vous verrez deux identifiants selon le format de sortie. La sortie lisible affiche la référence normative, CLD-NET-1, celle qui relie l'écart au référentiel commun. Les formats machine affichent le nom technique du contrôle, network_securitygroup_allow_ingress_from_internet_to_tcp_port_22, celui qu'on utilise pour cibler une exception ou filtrer un rapport.

Retenez le premier pour discuter avec un auditeur, le second pour écrire une règle dans un fichier.

Corriger, une cause à la fois

L'inventaire est un simple fichier JSON : provider, puis une liste de resources portant chacune un type, un identifiant et des attributes. Voici ce que la version corrigée change, écart par écart.

1. Le seau exposé

   L'ACL qui accordait la lecture au groupe global AllUsers est remplacée par une ACL nominative sur le propriétaire, et le versionnage est activé.

   "acl_grants": [
     { "grantee": { "type": "CanonicalUser", "id": "owner-id" }, "permission": "FULL_CONTROL" }
   ],
   "versioning": "Enabled"

2. La clé rattachée au compte root

   Elle est rattachée à une application plutôt qu'à une personne ou au compte racine. C'est la distinction entre une identité humaine et une identité de machine.

   "root_owned": false,
   "application_id": "22222222-2222-2222-2222-222222222222"

3. La clé sans expiration

   Une date d'expiration est posée. Elle transforme la rotation en obligation plutôt qu'en bonne intention.

   "expiration_date": "2027-06-30T00:00:00Z"

4. SSH ouvert au monde

   La plage source passe de 0.0.0.0/0 à un réseau d'administration.

   "cidrs": ["10.0.0.0/8"],
   "port_from": 22,
   "port_to": 22

Vérifier que le verdict bascule

./pepin scan scaleway examples/scaleway/inventory-ok.json
echo $?

Le code de retour vaut désormais 0, et le verdict mérite d'être lu mot à mot :

 ✓ No deviations found in the audited scope.

 Verdict : conforme sur le périmètre évalué
 (aucune non-conformité détectée, 12 contrôles conformes)

« Sur le périmètre évalué », et douze contrôles conformes. Pépin ne dit pas « votre cloud est sûr » : il dit ce qu'il a vérifié et combien de contrôles l'établissent. C'est la différence entre un résultat et une promesse.

Le contre-exemple qui prouve que la règle réfléchit

Regardez l'inventaire corrigé de plus près : il contient quatre ressources, soit une de plus que l'inventaire vulnérable. La nouvelle est une règle de pare-feu qui accepte le trafic depuis 0.0.0.0/0.

{
  "type": "security_group_rule",
  "attributes": {
    "direction": "inbound", "action": "accept", "protocol": "tcp",
    "cidrs": ["0.0.0.0/0"],
    "port_from": 443, "port_to": 443
  }
}

Et le scan reste conforme. C'est voulu : exposer le port 443 au monde est le comportement normal d'un site web, alors qu'exposer le port 22 ne l'est pas. Un scanner qui signalerait toute règle contenant 0.0.0.0/0 produirait un faux positif à chaque serveur web, et vous apprendriez très vite à ignorer ses alertes.

Faites l'expérience inverse

Le meilleur moyen de vérifier une règle est de la casser. Copiez l'inventaire corrigé, remplacez "port_from": 443, "port_to": 443 par 22, relancez le scan : l'écart réapparaît.

Le fichier étant indenté, une substitution par sed sur une seule ligne échouerait sans le dire. Passez par un court script, qui relit ce qu'il écrit :

# casse.py : ouvre le port 22 au monde, à la place du 443
import json

d = json.load(open("examples/scaleway/inventory-ok.json"))
for r in d["resources"]:
    a = r.get("attributes", {})
    if a.get("port_from") == 443:
        a["port_from"] = a["port_to"] = 22
json.dump(d, open("/tmp/essai.json", "w"), ensure_ascii=False, indent=2)

python3 casse.py
./pepin scan scaleway /tmp/essai.json
echo $?

Le verdict repasse à NON CONFORME, avec exactement un écart de sévérité haute et un code de retour de 1. La règle a donc bien réagi au port, pas à la plage d'adresses.

Un contrôle qu'on n'a jamais vu échouer sur un cas qui devrait échouer ne prouve rien. C'est vrai de Pépin comme de vos propres tests.

Ce que ce scan n'a pas prouvé

Le verdict conforme porte sur douze contrôles, pas sur les cinquante-sept du référentiel. Le format assessment le montre sans détour :

./pepin scan scaleway examples/scaleway/inventory.json -f assessment

Sur l'inventaire vulnérable, la répartition réelle est de 4 écarts, 7 conformes, 2 non applicables et 14 non évalués. Ces quatorze contrôles ne sont ni réussis ni ratés : la donnée nécessaire n'était pas dans l'inventaire, et chacun porte sa raison.

compute_instance_has_security_group
  aucune ressource de type « compute_instance » dans l'inventaire évalué

C'est logique ici, puisque l'inventaire d'exemple ne contient aucune machine. Mais c'est exactement ce qui se produira sur votre infrastructure si un droit de lecture manque à vos identifiants : le contrôle ne sera pas évalué, et il le dira au lieu de compter pour un succès.

Passer à votre propre infrastructure

Deux chemins s'ouvrent, et ils ne répondent pas à la même question.

Ce que vous voulez savoir	La commande
Ce que je m'apprête à déployer est-il correct ?	terraform show -json tfplan > plan.json puis pepin scan scaleway --terraform plan.json
Ce qui tourne réellement est-il correct ?	pepin scan scaleway --live --region fr-par

Glissez pour voir

Le plan Terraform ne voit que ce que votre code déclare. La collecte live voit aussi ce que personne n'a déclaré, et c'est souvent là que se cachent les surprises.

À retenir

• Un scan se découvre sans compte cloud : les inventaires d'exemple du dépôt suffisent.
• Le code de sortie vaut 1 dès qu'un écart critique ou haut est constaté, 0 sinon.
• Une ressource peut produire plusieurs écarts : la clé d'accès en déclenche deux, pour deux raisons distinctes.
• Chaque écart porte sa remédiation et sa référence normative, pas seulement son constat.
• Deux identifiants coexistent : la référence normative pour discuter, le nom technique pour écrire une exception.
• Le verdict conforme est qualifié par le nombre de contrôles qui l'établissent, ici douze.
• Ouvrir le port 443 au monde ne déclenche rien, ouvrir le port 22 oui : la règle juge l'usage, pas la présence de 0.0.0.0/0.
• Quatorze contrôles sur vingt-sept n'ont pas pu être évalués faute de données, et le disent.

Ressources externes

• Inventaires d'exemple du dépôt : les fixtures utilisées sur cette page, et leurs équivalents Outscale et Exoscale.
• Documentation de terraform show : produire le plan JSON attendu par Pépin.

×

📖 Voir la documentation →