Name: Kubernetes Gérez la plateforme de déploiement de vos applications conteneurisées (2e édition)
Rating: 4.5 (2 reviews)

Objectifs du chapitre et prérequis

Dans le chapitre précédent, une première sécurisation a été mise en œuvre pour éviter que n’importe qui puisse accéder aux ressources du cluster. En revanche, si un tiers arrive à compromettre l’intégrité d’un pod, rien ne l’empêchera de rayonner depuis celui-ci.

Par défaut, les pods dans Kubernetes peuvent communiquer entre eux sans restriction. Cette situation reste acceptable sur de petits clusters de test mais il peut vite devenir souhaitable de restreindre ces accès.

Les polices réseau (network policies)

1. Présentation du mécanisme

Un moyen de contrôler les accès serait de les définir en fonction de règles applicatives. Tous les pods d’un même service auraient le droit de communiquer entre eux (les pods de présentation avec leur base de données, par exemple), mais pas avec les autres. Un autre exemple de restriction serait de ne pas autoriser la communication entre pods de deux espaces de noms différents.

Dans Kubernetes, ce mécanisme est pris en charge à l’aide des ressources de type NetworkPolicy.

2. Kubernetes Network Plugins

Afin de pouvoir utiliser ce type de ressources, le cluster Kubernetes doit disposer d’une couche de gestion du réseau supportant la notion de polices. Cette couche répond à une norme : CNI (Container Network Interface).

Cette norme est implémentée par des pilotes (Calico, Weave, Flannel, etc.). Le site officiel de Kubernetes en référence une partie sur la page suivante : https://kubernetes.io/docs/concepts/cluster-administration/networking/

Ces pilotes utilisent des mécanismes différents pour réaliser le contrôle des communications :

Overlay : encapsulation de la communication dans un réseau virtuel (VLAN, veth, etc.).
Underlay : utilisation des ressources matérielles sous-jacentes (switchs, routeurs, etc.).

Parmi les nombreuses solutions, l’une d’elles revient très fréquemment : Calico. En effet, on la retrouve dans les cas suivants :

Les solutions managées (AWS, Azure et GKE) sont propriétaires et s’appuient en partie sur Calico (pour la partie NetworkPolicies).
Calico est également utilisable sur des clusters Kubernetes installés sur des machines classiques (on premise).

Dans le cas de Calico, la procédure d’installation sera déroulée sur Minikube.

3. Polices réseau sur services managés et installation maison

L’activation des polices réseau a été abordée respectivement durant la création des clusters par services managés (Azure, AWS ou GKE) ou pour l’installation maison (Kubespray).

N’hésitez pas à revenir sur les chapitres Services managés Kubernetes et Installation de...

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 wordpress-test.yaml correspondant :

# https://github.com/bitnami/charts/blob/master/bitnami/wordpress/values.yaml 
 
ingress: 
  ingressClassName: nginx 
  enabled: true 
  tls: true 
  annotations: 
    kubernetes.io/tls-acme: "true" 
    cert-manager.io/cluster-issuer: "letsencrypt-prod" 
  hostname: "wordpress.eni.yannig.ovh"

À l’aide de ce fichier, lancez le déploiement de WordPress :

$ helm upgrade --install wordpress bitnami/wordpress \ 
               --namespace test --create-namespace \ 
               -f wordpress-test.yaml...

Polices réseau