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 :
En version papier
En version numérique
En illimité avec l'abonnement ENI
Sur la boutique officielle ENI
Conditions générales d'utilisationCopyright - © Editions ENI ||Politique de protection des données du groupe ENI