Protection de l’application WordPress

1. Contexte

L’architecture de l’application MailHog est simple. En effet, MailHog n’interagit pas avec d’autres services (pas de base de données ou services à appeler).

Une application WordPress est de ce point de vue plus représentative d’un cas réel puisqu’elle possède les parties suivantes :

  • une couche de présentation,

  • une base de données.

2. Déploiement de WordPress

Pour la suite de l’exercice, un site WordPress va être déployé dans l’espace de nom test avec une règle Ingress sur l’adresse wordpress.eni.yannig.ovh.

Afin de publier l’application WordPress à l’aide du chart Helm, il est nécessaire de faire appel aux paramètres suivants :

  • activation d’Ingress à l’aide du champ ingress --> enabled=true,

  • annotations de configuration des règles Ingress :

  • utilisation de Nginx : kubernetes.io/ingress.class=nginx

  • activation de la sécurisation TLS : kubernetes.io/tls-acme=’true’

  • spécification de l’adresse à l’aide du champ hosts --> name=wordpress.eni.yannig.ovh

Ci-dessous le contenu du fichier de configuration wordpress-test.yaml correspondant :

ingress: 
 enabled: true 
 annotations: 
   kubernetes.io/ingress.class: nginx 
   kubernetes.io/tls-acme: 'true' 
 hosts: 
   - name:...
Pour consulter la suite, découvrez le livre suivant :
couv_EPKUB.png
60-signet.svg
En version papier
20-ecran_lettre.svg
En version numérique
41-logo_abonnement.svg
En illimité avec l'abonnement ENI
130-boutique.svg
Sur la boutique officielle ENI
Précédent
Les polices réseau (network policies)
Suivant
Objectifs du chapitre et prérequis