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.

  • Utilisation de nginx à l’aide du champ ingress --> ingressClassName.

  • Activation du chiffrement à l’aide du champ ingress --> tls.

  • Annotations de configuration des règles Ingress :

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

  • Spécification de l’objet ClusterIssuer à utiliser à l’aide de l’annotation cert-manager.io/cluster-issuer (letsencrypt-prod)

  • Spécification de l’adresse à l’aide du champ ingress --> hostname=wordpress.eni.yannig.ovh.

Ci-dessous le contenu du fichier de configuration...

Pour consulter la suite, découvrez le livre suivant :
couv_EI2KUB.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