Déployer Elastic Stack sous Rocky Linux 9 : TLS, ILM et exploitation

EdwardMoon

Déployer Elastic Stack ne se résume pas à installer quatre paquets. Concevez l'authentification de la collecte, TLS et les droits Elasticsearch, l'exposition de Kibana, la rétention et la récupération par snapshot comme un ensemble d'exploitation cohérent. Ce guide fournit une procédure reproductible d'installation et de validation sous Rocky Linux 9 avec Elastic Stack 9.4.2.

Le laboratoire démarre sur un seul hôte ; en production, séparez les rôles et les domaines de panne. Chaque commande est accompagnée de son objectif et de vérifications. Ne publiez pas de mots de passe ou clés API en clair dans la configuration ou l'historique du shell, et conservez les protections Elastic par défaut.

Périmètre et composants

Conception et prérequis

Rocky Linux 9 est compatible RHEL, mais si vous exigez un support commercial, vérifiez la combinaison exacte dans la matrice Elastic. Alignez tous les composants Elastic Stack sur la même version. Ce guide utilise 9.4.2 comme référence d'exemple, sans affirmer qu'il s'agit de la dernière version. À l'installation, consultez le dépôt officiel et la matrice de support.

Distinguer laboratoire et production

Vérifier les ressources de l'hôte et la synchronisation horaire

sudo dnf install -y curl jq

cat /etc/rocky-release
uname -r
timedatectl status
free -h
df -hT /var/lib /var/log
sysctl vm.max_map_count
ulimit -n

Elasticsearch utilise intensivement le cache du système de fichiers en plus du tas JVM. Un traitement Logstash lourd sur le même hôte peut donc provoquer une concurrence mémoire. Commencez par le dimensionnement automatique du tas et ne fixez Xms et Xmx à une même valeur explicite que si les tests de charge le justifient.

Configurer le dépôt et installer la version 9.4.2

Utilisez la clé GPG officielle Elastic et son dépôt RPM 9.x. Laisser ce dépôt désactivé par défaut réduit les changements de version imprévus lors des mises à jour dnf courantes. Examinez les changements et la compatibilité avant installation.

Enregistrer la clé GPG et le dépôt officiels

sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

sudo tee /etc/yum.repos.d/elastic-9.x.repo >/dev/null <<'EOF'
[elastic-9.x]
name=Elastic repository for 9.x packages
baseurl=https://artifacts.elastic.co/packages/9.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=0
type=rpm-md
EOF

sudo dnf clean metadata
sudo dnf --disablerepo='*' --enablerepo=elastic-9.x list available   elasticsearch kibana logstash filebeat

Installer des versions identiques et vérifier le verrouillage

STACK_VERSION='9.4.2'
sudo dnf install --enablerepo=elastic-9.x   "elasticsearch-${STACK_VERSION}"   "kibana-${STACK_VERSION}"   "logstash-${STACK_VERSION}"   "filebeat-${STACK_VERSION}"

rpm -q elasticsearch kibana logstash filebeat
sudo dnf install python3-dnf-plugin-versionlock
sudo dnf versionlock add elasticsearch kibana logstash filebeat

Sécuriser un nœud Elasticsearch unique

Pour le laboratoire, faites écouter Elasticsearch uniquement sur le bouclage. Au premier démarrage, Elastic 9.x configure automatiquement l'authentification et TLS pour HTTP et le transport. Configurez chaque client pour qu'il fasse confiance à l'AC générée au lieu de désactiver la sécurité.

Paramètres minimaux du laboratoire dans elasticsearch.yml

Sauvegardez et modifiez le fichier avec les commandes suivantes. Définissez chaque clé YAML une seule fois dans le fichier existant, en conservant l'authentification et TLS générés automatiquement. Ne remplacez pas tout le fichier par ce court fragment.

sudo cp -a /etc/elasticsearch/elasticsearch.yml /etc/elasticsearch/elasticsearch.yml.before-lab
sudoedit /etc/elasticsearch/elasticsearch.yml

cluster.name: logs-lab
node.name: es01
network.host: 127.0.0.1
http.host: 127.0.0.1
transport.host: 127.0.0.1
discovery.type: single-node

sudo systemctl daemon-reload
sudo systemctl enable --now elasticsearch
sudo systemctl status elasticsearch --no-pager

Si une clé existe, modifiez sa valeur sans la dupliquer. En cas d'échec de démarrage, examinez le journal systemd et les journaux Elasticsearch pour les contrôles bootstrap, permissions ou erreurs YAML avant de changer la configuration ; ne désactivez pas la sécurité.

sudo journalctl -u elasticsearch --since '-10 min' --no-pager
sudo tail -n 100 /var/log/elasticsearch/logs-lab.log
sudo ss -lntp | grep -E ':(9200|9300)\b'

Réinitialiser le mot de passe et vérifier HTTPS avec l'AC

Copiez uniquement le certificat public de l'AC vers un emplacement distinct accessible à curl depuis un shell ordinaire. Ne copiez pas la clé privée de l'AC ni les keystores de transport ou HTTP.

sudo install -d -m 0755 /etc/elastic-client
sudo install -o root -g root -m 0644 /etc/elasticsearch/certs/http_ca.crt /etc/elastic-client/http_ca.crt
openssl x509 -in /etc/elastic-client/http_ca.crt -noout -fingerprint -sha256

sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password   -u elastic -i

read -rsp 'elastic password: ' ELASTIC_PASSWORD
echo
export ELASTIC_PASSWORD

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   https://127.0.0.1:9200/ | jq .

unset ELASTIC_PASSWORD

Ignorer la vérification du certificat peut permettre la connexion, mais empêche de détecter une usurpation du serveur. Distribuez l'empreinte ou le certificat de l'AC générée et utilisez des comptes ou clés API propres à chaque service, au moindre privilège, plutôt que des mots de passe personnels.

Enrôler Kibana et le publier en HTTPS

Kibana peut s'enrôler avec un jeton contenant les informations d'AC et d'authentification Elasticsearch. Une configuration simple le fait écouter sur 127.0.0.1 et termine HTTPS sur un proxy inverse avec le certificat de l'organisation, plutôt que d'exposer directement le port 5601 aux navigateurs.

Créer un jeton et enrôler Kibana

sudo /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token   -s kibana

# Saisir dans la commande suivante le jeton temporaire affiché précédemment.
sudo /usr/share/kibana/bin/kibana-setup   --enrollment-token '<ONE_TIME_ENROLLMENT_TOKEN>'

sudo tee -a /etc/kibana/kibana.yml >/dev/null <<'EOF'
server.host: "127.0.0.1"
server.port: 5601
server.publicBaseUrl: "https://kibana.example.com"
EOF

sudo systemctl enable --now kibana
sudo journalctl -u kibana --since '-10 min' --no-pager

Exemple de proxy inverse Nginx HTTPS

Installez d'abord le certificat et la clé privée du domaine aux chemins indiqués, puis enregistrez le bloc server dans /etc/nginx/conf.d/kibana.conf. Vérifiez que le bloc http de nginx.conf inclut ce répertoire.

sudo dnf install -y nginx policycoreutils-utils
sudoedit /etc/nginx/conf.d/kibana.conf
# Autoriser Nginx à joindre Kibana sur le bouclage avec SELinux enforcing.
sudo setsebool -P httpd_can_network_connect on

server {
    listen 443 ssl http2;
    server_name kibana.example.com;

    ssl_certificate     /etc/pki/tls/certs/kibana-fullchain.pem;
    ssl_certificate_key /etc/pki/tls/private/kibana.key;

    location / {
        proxy_pass http://127.0.0.1:5601;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

sudo nginx -t
sudo systemctl enable --now nginx
sudo systemctl reload nginx

# Remplacer par la plage du réseau d'administration.
sudo firewall-cmd --permanent --new-zone=kibana-admin || true
sudo firewall-cmd --permanent --zone=kibana-admin   --add-source=10.20.0.0/16
sudo firewall-cmd --permanent --zone=kibana-admin --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --zone=kibana-admin --list-all

Préparer les data streams et ILM avant la collecte

Créez la politique et le modèle avant d'envoyer les premiers journaux. Les changements de modèle ne s'appliquent pas rétroactivement aux index sous-jacents existants. Pour un flux existant, examinez sa politique ILM et gérez les changements et le rollover dans une procédure distincte. Exécutez ILM explain ci-dessous après la création d'un index sous-jacent par la collecte.

Écrire continuellement des journaux temporels dans un seul index crée des shards trop volumineux et allonge la récupération. Les data streams et ILM permettent de basculer vers un nouvel index sous-jacent lorsque les conditions sont remplies, puis de supprimer les données à l'échéance de rétention. Cet exemple déclenche un rollover à 50 Go ou après un jour.

Créer une politique ILM de 30 jours

read -rsp 'elastic password: ' ELASTIC_PASSWORD
echo

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT https://127.0.0.1:9200/_ilm/policy/logs-30d   -H 'Content-Type: application/json' -d @- <<'JSON'
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {"max_primary_shard_size": "50gb", "max_age": "1d"}
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": {"delete": {}}
      }
    }
  }
}
JSON

Créer un modèle d'index pour le data stream

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT https://127.0.0.1:9200/_index_template/logs-app   -H 'Content-Type: application/json' -d @- <<'JSON'
{
  "index_patterns": ["logs-app-*"],
  "priority": 500,
  "data_stream": {},
  "template": {
    "settings": {
      "index.lifecycle.name": "logs-30d",
      "number_of_shards": 1,
      "number_of_replicas": 1
    }
  }
}
JSON

Examiner l'état ILM

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/_ilm/status?pretty'

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/.ds-logs-app-*/_ilm/explain?pretty'

Construire le pipeline Logstash et Filebeat

Dans cet exemple local, Filebeat envoie à Logstash sur le bouclage et Logstash vérifie le certificat Elasticsearch avec son AC. Si des Beats distants utilisent le port 5044, déployez séparément les certificats serveur et clients et restreignez les sources au pare-feu.

Créer un compte de collecte au moindre privilège

read -rsp 'elastic password: ' ELASTIC_PASSWORD
echo
read -rsp 'logstash_writer password: ' LOGSTASH_WRITER_PASSWORD
echo

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT https://127.0.0.1:9200/_security/role/logstash_writer_role   -H 'Content-Type: application/json' -d @- <<'JSON'
{
  "cluster": ["monitor"],
  "indices": [
    {
      "names": ["logs-app-*"],
      "privileges": ["auto_configure", "create_doc"]
    }
  ]
}
JSON

jq -n --arg password "$LOGSTASH_WRITER_PASSWORD"   '{password:$password,roles:["logstash_writer_role"]}' | curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT https://127.0.0.1:9200/_security/user/logstash_writer   -H 'Content-Type: application/json' --data-binary @-

unset LOGSTASH_WRITER_PASSWORD

Valider la syntaxe Logstash et la connectivité

sudo install -d -o logstash -g logstash -m 0750 /etc/logstash/certs
sudo install -o logstash -g logstash -m 0640   /etc/elasticsearch/certs/http_ca.crt   /etc/logstash/certs/http_ca.crt

sudo /usr/share/logstash/bin/logstash-keystore   --path.settings /etc/logstash create
sudo /usr/share/logstash/bin/logstash-keystore   --path.settings /etc/logstash add ES_PASSWORD

ES_PASSWORD doit contenir le mot de passe du compte de collecte dédié, et non celui du superutilisateur elastic utilisé au début de l'apprentissage. La configuration référence des variables du keystore au lieu de secrets en clair afin de les exclure du fichier.

sudo tee /etc/logstash/conf.d/beats-to-elasticsearch.conf >/dev/null <<'EOF'
input {
  beats { host => "127.0.0.1" port => 5044 }
}

filter {
  if ![@metadata][pipeline] { mutate { add_tag => ["pipeline-default"] } }
}

output {
  elasticsearch {
    hosts => ["https://127.0.0.1:9200"]
    user => "logstash_writer"
    password => "${ES_PASSWORD}"
    ssl_enabled => true
    ssl_certificate_authorities => ["/etc/logstash/certs/http_ca.crt"]
    ecs_compatibility => "v8"
    manage_template => false
    ilm_enabled => false
    data_stream => "true"
    data_stream_type => "logs"
    data_stream_dataset => "app"
    data_stream_namespace => "default"
  }
}
EOF

sudo chown logstash:logstash /etc/logstash/logstash.keystore
sudo chmod 0600 /etc/logstash/logstash.keystore

sudo -u logstash /usr/share/logstash/bin/logstash   --path.settings /etc/logstash --config.test_and_exit
sudo systemctl enable --now logstash

Configurer l'entrée filestream et la sortie Filebeat

sudo tee /etc/filebeat/filebeat.yml >/dev/null <<'EOF'
filebeat.inputs:
  - type: filestream
    id: system-messages
    enabled: true
    paths:
      - /var/log/messages

output.elasticsearch:
  enabled: false

output.logstash:
  hosts: ["127.0.0.1:5044"]

logging.level: info
EOF

sudo filebeat test config -e
sudo filebeat test output -e
sudo systemctl enable --now filebeat
sudo journalctl -u filebeat --since '-10 min' --no-pager

Vérifiez que Filebeat peut lire /var/log/messages. Examinez le compte de service et les permissions du paquet au lieu de l'exécuter automatiquement en root. Supprimez ou masquez les champs sensibles, données personnelles et jetons avant collecte. Suivez les échecs d'analyse avec un tag et un tableau de bord distincts.

Passer à un cluster de production à trois nœuds

Placez trois nœuds éligibles master dans des domaines de panne distincts. Deux nœuds ne conservent pas de majorité si l'un tombe. Ajoutez les nouveaux nœuds avec des jetons d'enrôlement, puis nettoyez les paramètres de découverte une fois le cluster formé.

Enrôler les nœuds et vérifier le cluster

Vous ne pouvez pas ajouter des nœuds en conservant la configuration précédente limitée au bouclage et au mode single-node. Sur le nœud existant, retirez discovery.type: single-node et définissez transport.host sur une adresse dédiée joignable par les autres nœuds. L'enrôlement exige aussi son API HTTPS : faites inclure cette adresse privée et le bouclage à http.host, puis vérifiez les SAN du certificat. N'autorisez 9200 que depuis les hôtes d'administration d'enrôlement et 9300 qu'entre nœuds. Conservez TLS.

cluster.name: logs-lab
node.name: es01
network.host: 10.20.30.11
http.host: ["127.0.0.1", "10.20.30.11"]
transport.host: 10.20.30.11
discovery.seed_hosts: ["10.20.30.11:9300", "10.20.30.12:9300", "10.20.30.13:9300"]

Remplacez les adresses par celles des trois nœuds réels et modifiez les clés YAML existantes. Laissez cluster.initial_master_nodes absent du cluster existant. Après validation des contrôles bootstrap et du redémarrage, générez un jeton distinct par nouveau nœud. Avant leur premier démarrage, vérifiez cluster.name, node.name, les adresses et les seed hosts de chacun.

sudo systemctl restart elasticsearch
sudo systemctl status elasticsearch --no-pager
sudo ss -lntp | grep -E ":(9200|9300)\b"

# Exécuter sur un nœud existant du cluster
sudo /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token   -s node

# Exécuter sur le nouveau nœud juste après l'installation du paquet
sudo /usr/share/elasticsearch/bin/elasticsearch-reconfigure-node   --enrollment-token '<ONE_TIME_NODE_TOKEN>'
sudo systemctl enable --now elasticsearch

# Vérifier les nœuds et leurs rôles depuis le cluster existant
curl --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/_cat/nodes?v&h=name,ip,node.role,master,heap.percent,disk.avail'

cluster.initial_master_nodes sert uniquement à la première élection d'un nouveau cluster. Retirez-le de tous les nœuds après formation et ne le rétablissez pas. Le conserver lors des redémarrages risque d'amorcer accidentellement un cluster distinct. Renseignez discovery.seed_hosts avec les nœuds éligibles master joignables après redémarrage.

Snapshots et exercices de récupération

Une réplique protège contre la panne d'un nœud ; ce n'est pas une sauvegarde. Une suppression accidentelle est immédiatement répercutée. Un déploiement complet exige un dépôt de snapshots hors cluster, des politiques SLM automatisées et de véritables tests de restauration.

Enregistrer un dépôt sur système de fichiers partagé

Montez le même véritable système de fichiers partagé au même chemin sur tous les nœuds master/data et vérifiez les droits de lecture et d'écriture du compte Elasticsearch. Des répertoires locaux distincts portant le même nom ne forment pas un stockage partagé.

# Sur tous les nœuds master/data, définir la clé path.repo existante dans elasticsearch.yml
# sur path.repo: ["/mnt/elastic-backup"].

# Enregistrer le dépôt après un redémarrage progressif.
curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT https://127.0.0.1:9200/_snapshot/prod_backup   -H 'Content-Type: application/json' -d @- <<'JSON'
{
  "type": "fs",
  "settings": {
    "location": "/mnt/elastic-backup",
    "compress": true
  }
}
JSON

Vérifier le dépôt et créer un snapshot de test

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X POST 'https://127.0.0.1:9200/_snapshot/prod_backup/_verify?pretty'

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT 'https://127.0.0.1:9200/_snapshot/prod_backup/smoke-test?wait_for_completion=true&pretty'

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/_snapshot/prod_backup/smoke-test?pretty'

Copier /var/lib/elasticsearch avec rsync ou des snapshots de système de fichiers n'est pas une méthode de sauvegarde prise en charge. Des processus externes modifiant le dépôt peuvent aussi le corrompre. Restaurez régulièrement dans un cluster de test distinct et vérifiez les index, états des fonctionnalités et tableaux de bord.

Valider et diagnostiquer Elastic Stack

Vérifier ensemble services, TLS et santé du cluster

systemctl --no-pager --full status   elasticsearch kibana logstash filebeat

sudo ss -lntp | grep -E ':(9200|9300|5601|5044)\b'

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/_cluster/health?pretty'

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/_cat/shards?v&s=state,index'

unset ELASTIC_PASSWORD

Démarche de diagnostic

1. Repérer le premier horodatage d'erreur dans les codes de sortie systemd et les entrées récentes du journal.
2. Confirmer que les ports écoutent uniquement sur les adresses prévues.
3. Vérifier la confiance dans l'AC, les noms d'hôtes, les dates de validité et la configuration des clients.
4. Examiner les causes de shards non attribués et les seuils disque avec la santé du cluster.
5. Vérifier la validation Logstash, les files persistantes, les événements rejetés et les tests de sortie Filebeat.
6. Valider l'automatisation de la rétention et des sauvegardes avec ILM explain et la vérification du dépôt.
7. Reproduire l'incident avec les mêmes entrées et paramètres dans un environnement isolé, puis consigner les modifications.

Erreurs fréquentes et solutions

Mises à niveau et exploitation

• Aligner les versions cibles des composants et examiner les notes et ruptures de compatibilité.
• Avant mise à niveau, vérifier la santé, les shards non attribués, les seuils disque et les snapshots réussis.
• Mettre à niveau un nœud à la fois et attendre son retour et la récupération des shards à chaque étape.
• Valider la compatibilité des objets sauvegardés Kibana, plugins Logstash, modules Beats et modèles personnalisés.
• Réexaminer régulièrement l'expiration des certificats, les entrées keystore, la rotation des clés API et les privilèges.
• Déclencher des alertes sur les retards de collecte, la pression JVM, les rejets, la taille des shards et les échecs ILM/SLM.

Ressources associées

• Guide officiel d'installation Elasticsearch par RPM
• Sécurité des déploiements Elastic autogérés
• Documentation officielle Elastic ILM
• Documentation officielle des snapshots et restaurations Elastic
• Diagnostic de l'espace disque et des inodes sous Linux
• Playbooks Ansible et déploiements progressifs
• Conteneurs Linux et Podman rootless

Conclusion

Un déploiement Elastic Stack réussi collecte les données en sécurité, maîtrise leur volume et permet la récupération après incident. Partez de versions officielles identiques et conservez TLS et l'authentification automatiques. Vérifiez ensuite le moindre privilège, les limites du bouclage et du pare-feu, les data streams et ILM, puis les snapshots hors cluster. Cette démarche mène du laboratoire à un nœud au cluster opérationnel à trois nœuds.