One place for hosting & domains

      Étapes

      Étapes recommandées pour renforcer Apache HTTP sous FreeBSD 12.0


      L’auteur a choisi le Free and Open Source Fund comme récipiendaire d’une donation dans le cadre du programme Write for Donations.

      Introduction

      Bien que l’installation par défaut d’un serveur Apache HTTP soit déjà sûre, sa configuration peut être considérablement améliorée grâce à quelques modifications. Vous pouvez compléter les mécanismes de sécurité déjà existants, par exemple en mettant en place des protections autour des cookies et des en-têtes, afin que les connexions ne puissent pas être altérées au niveau du client de l’utilisateur. Ce faisant, vous pouvez considérablement réduire les possibilités de plusieurs méthodes d’attaque, comme les attaques de type “Cross-Site Scripting” (également connues sous le nom de XSS). Vous pouvez également éviter d’autres types d’attaques, telles que la falsification de requête inter-sites, ou le détournement de session, ainsi que les attaques par déni de service.

      Dans ce tutoriel, vous allez implémenter certaines mesures recommandées pour réduire la quantité d’informations exposées sur votre serveur. Vous vérifierez la liste des répertoires et désactiverez l’indexation pour vérifier l’accès aux ressources. Vous modifierez également la valeur par défaut de la directive sur le délai d'attente afin d’atténuer les attaques de type déni de service. En outre, vous désactiverez la méthode TRACE afin que les sessions ne puissent pas être inversées et détournées. Enfin, vous sécuriserez les en-têtes et les cookies.

      La plupart des paramètres de configuration seront appliqués au fichier de configuration principal d’Apache HTTP qui se trouve dans /usr/local/etc/apache24/httpd.conf.

      Conditions préalables

      Avant de commencer ce guide, vous aurez besoin des éléments suivants :

      Une fois ces conditions préalables réunies, vous disposez d’un système FreeBSD avec une pile capable de servir du contenu web en utilisant tout ce qui est écrit en PHP, comme les principaux logiciels de gestion de contenu (CMS). De plus, vous avez chiffré des connexions sécurisées grâce à Let’s Encrypt.

      Réduire les informations sur le serveur

      La bannière de système d’exploitation est une méthode utilisée par les ordinateurs, les serveurs et les dispositifs de toutes sortes pour se présenter sur les réseaux. Des personnes malveillantes peuvent utiliser ces informations pour exploiter les systèmes concernés. Dans cette section, vous réduirez la quantité d’informations publiées par cette bannière.

      Des ensembles de directives contrôlent la manière dont ces informations sont affichées. À cet effet, la directive ServerTokens est importante ; par défaut, elle affiche au client qui s’y connecte tous les détails sur le système d’exploitation et les modules compilés.

      Vous utiliserez un outil de balayage du réseau pour vérifier quelles informations sont actuellement révélées avant d’appliquer tout changement. Pour installer nmap, exécutez la commande suivante :

      Pour obtenir l’adresse IP de votre serveur, vous pouvez exécuter la commande suivante :

      • ifconfig vtnet0 | awk '/inet / {print $2}'

      Vous pouvez vérifier la réponse du serveur web en utilisant la commande suivante :

      • nmap -sV -p 80 your-server-ip

      Vous appelez nmap pour effectuer un scan (d’où le drapeau -s), pour afficher la version (le drapeau -V) sur le port 80 (le drapeau -p) sur l’IP ou le domaine donné.

      Vous recevrez des informations sur votre serveur web, semblables à celles qui suivent :

      Output

      Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-22 00:30 CET Nmap scan report for 206.189.123.232 Host is up (0.054s latency). PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.41 ((FreeBSD) OpenSSL/1.1.1d-freebsd Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

      Cette sortie montre que des informations telles que le système d’exploitation, la version d’Apache HTTP et OpenSSL sont visibles. Cela peut être utile aux attaquants pour obtenir des informations sur le serveur et choisir les bons outils à exploiter, par exemple, une vulnérabilité dans le logiciel fonctionnant sur le serveur.

      Vous placerez la directive ServerTokens dans le fichier de configuration principal puisqu’elle n’est pas configurée par défaut. L’absence de cette configuration fait qu’Apache HTTP affiche les informations complètes sur le serveur, comme l’indique la documentation. Pour limiter les informations qui sont révélées sur votre serveur et votre configuration, vous placerez la directive ServerTokens dans le fichier de configuration principal.

      Vous placerez cette directive à la suite de l’entrée ServerName dans le fichier de configuration. Exécutez la commande suivante pour trouver la directive :

      • grep -n 'ServerName' /usr/local/etc/apache24/httpd.conf

      Vous trouverez le numéro de ligne que vous pouvez ensuite rechercher avec vi :

      Output

      226 #ServerName www.example.com:80

      Exécutez la commande suivante :

      • sudo vi +226 /usr/local/etc/apache24/httpd.conf

      Ajoutez la ligne surlignée suivante :

      /usr/local/etc/apache24/httpd.conf

      . . .
      #ServerName www.example.com:80
      ServerTokens Prod
      

      Enregistrez et quittez le fichier avec :wq et ENTER.

      En réglant la directive ServerTokens sur Prod, on affichera uniquement qu’il s’agit d’un serveur web Apache.

      Pour que cela prenne effet, redémarrez le serveur Apache HTTP :

      Pour tester les changements, exécutez la commande suivante :

      • nmap -sV -p 80 your-server-ip

      Vous obtiendrez un résultat similaire à celui qui suit, avec un minimum d’informations sur votre serveur web Apache :

      Output

      Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-22 00:58 CET Nmap scan report for WPressBSD (206.189.123.232) Host is up (0.056s latency). PORT STATE SERVICE VERSION 80/tcp open http Apache httpd Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

      Vous avez vu quelles informations le serveur annonçait avant la modification et vous avez maintenant réduit celles-ci au minimum. De ce fait, vous fournissez moins d’indices sur votre serveur à un acteur externe. Au cours de l’étape suivante, vous gérerez les listes du répertoire pour votre serveur web.

      Gestion des listes du répertoire

      Au cours de cette étape, vous vous assurerez que les listes du répertoire sont correctement configurées, de sorte que les bonnes parties du système soient accessibles au public comme prévu, tandis que les autres sont protégées.

      Remarque : lorsqu’un argument est déclaré, il est actif, mais le + peut le renforcer visuellement, il est en fait activé. Lorsqu’un signe moins - est placé, l’argument est refusé, par exemple, Options -Indexes.

      Les arguments avec + et/ou - ne peuvent pas être mélangés, cela est considéré comme une mauvaise syntaxe dans Apache HTTP et peut être rejeté au démarrage.

      L’ajout de l’énoncé Options -Indexes permet de définir le contenu du chemin de données /usr/local/www/apache24/data pour qu’il ne soit pas indexé (read listed) automatiquement si un fichier .html n’existe pas, et qu’il n’indique pas si une URL correspond à ce répertoire. Cela s’appliquera également lors de l’utilisation de configurations d’hôtes virtuels telles que celui utilisé pour le tutoriel préalable au certificat Let’s Encrypt.

      Vous définirez la directive Options avec l’argument -Indexes et avec la directive +FollowSymLinks, qui permettra de suivre des liens symboliques. Vous utiliserez le symbole + afin de respecter les conventions HTTP d’Apache.

      Exécutez la commande suivante pour trouver la ligne à modifier dans le fichier de configuration :

      • grep -n 'Options Indexes FollowSymLinks' /usr/local/etc/apache24/httpd.conf

      Vous verrez une sortie similaire à ce qui suit :

      Output

      263 : Options Indexes FollowSymLinks

      Exécutez cette commande pour accéder directement à la ligne que vous souhaitez modifier :

      • sudo vi +263 /usr/local/etc/apache24/httpd.conf

      Modifiez maintenant la ligne conformément à la configuration :

      /usr/local/etc/apache24/httpd.conf

      . . .
      #
      Options -Indexes +FollowSymLinks
      
      #
      . . .
      

      Enregistrez et quittez le fichier avec :wq et ENTER.

      Redémarrez Apache HTTP pour implémenter ces modifications :

      Au niveau de votre domaine dans le navigateur, vous verrez un message d’accès interdit, également connu sous le nom d’erreur 403. Cela est dû aux changements que vous avez appliqués. Le placement de -Indexes dans la directive Options a désactivé la capacité d’auto-indexation d’Apache HTTP et il n’y a donc pas de fichier index.html dans le chemin des données.

      Vous pouvez résoudre ce problème en plaçant un fichier index.html à l’intérieur du VirtualHost que vous avez activé dans le tutoriel préalable au certificat Let’s Encrypt. Vous utiliserez le bloc par défaut dans Apache HTTP et le placerez dans le même dossier que le DocumentRoot que vous avez déclaré dans l’hôte virtuel.

      /usr/local/etc/apache24/extra/httpd-vhosts.conf

      <VirtualHost *:80>
          ServerAdmin your_email@your_domain.com
          DocumentRoot "/usr/local/www/apache24/data/your_domain.com"
          ServerName your_domain.com
          ServerAlias www.your_domain.com
          ErrorLog "/var/log/your_domain.com-error_log"
          CustomLog "/var/log/your_domain.com-access_log" common
      </VirtualHost>
      

      Utilisez la commande suivante pour ce faire :

      • sudo cp /usr/local/www/apache24/data/index.html /usr/local/www/apache24/data/your_domain.com/index.html

      Vous verrez maintenant un message Ça marche ! lorsque vous visiterez votre domaine.

      Dans cette section, vous avez imposé des restrictions à la directive Indexes afin de ne pas inclure et afficher automatiquement un contenu autre que celui que vous avez prévu. Désormais, s’il n’existe pas de fichier index.html dans le chemin de données, Apache HTTP ne créera pas automatiquement un index du contenu. Dans la prochaine étape, vous irez au-delà de l’obscurcissement des informations et vous adapterez différentes directives.

      Réduire la valeur de la directive sur le délai d’attente

      La directive Timeout fixe la limite du délai pendant lequel Apache HTTP attendra une nouvelle entrée/sortie avant l’échec de la demande de connexion. Cette échec peut être du à différentes circonstances telles que des paquets n’arrivant pas au serveur ou des données n’étant pas confirmées comme ayant été reçues par le client.

      Par défaut, le délai d’attente est fixé à 60 secondes. Dans les environnements où le service Internet est lent, cette valeur par défaut peut être raisonnable, mais une minute est une durée assez longue, en particulier si le serveur couvre une cible d’utilisateurs avec un service Internet plus rapide. En outre, la période pendant laquelle le serveur ne ferme pas la connexion peut être utilisée abusivement pour effectuer des attaques par déni de service (DoS). Si une invasion de ces connexions malveillantes se produit, le serveur faiblira et s’exposera à des risques de saturation et d’incapacité à répondre.

      Pour modifier la valeur, vous trouverez les entrées Timeout dans le fichier httpd-default.conf :

      • grep -n 'Timeout' /usr/local/etc/apache24/extra/httpd-default.conf

      Vous verrez une sortie similaire à :

      Output

      8 # Timeout: The number of seconds before receives and sends time out. 10 Timeout 60 26 # KeepAliveTimeout: Number of seconds to wait for the next request from the 29 KeepAliveTimeout 5 89 RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

      Dans la ligne de sortie, 10 définit la valeur de la directive Timeout. Pour accéder directement à cette ligne, exécutez la commande suivante :

      • sudo vi +10 /usr/local/etc/apache24/extra/httpd-default.conf

      Vous la modifierez pour la régler sur 30 secondes, par exemple, comme suit :

      /usr/local/etc/apache24/extra/httpd-default.conf

      #
      # Timeout: The number of seconds before receives and sends time out.
      #
      Timeout 30
      

      Enregistrez et quittez le fichier avec :wq et ENTER.

      La valeur de la directive Timeout doit trouver un équilibre entre une période suffisamment longue pour que ces événements permettent une connexion légitime et réussie, et suffisamment courte pour empêcher des tentatives de connexion non souhaitées.

      Remarque : les attaques par déni de service peuvent drainer les ressources du serveur de manière assez efficace. Utiliser un MPM threadé pour obtenir les meilleures performances de la manière dont Apache HTTP gère les connexions et les processus constitue une contre-mesure complémentaire et très efficace. Dans ce tutoriel Comment configurer Apache HTTP avec l’événement MPM et PHP-FPM sous FreeBSD 12.0, il y a des étapes pour activer cette fonctionnalité.

      Pour que cette modification prenne effet, redémarrez le serveur Apache HTTP :

      Vous avez modifié la valeur par défaut de la directive Timeout afin d’atténuer partiellement les attaques par déni de service.

      Désactiver la méthode TRACE

      Le Hypertext Transport Protocol a été développé selon un modèle client-serveur et, à ce titre, le protocole dispose de méthodes de requête pour récupérer ou placer des informations depuis/vers le serveur. Le serveur doit comprendre ces ensembles de méthodes et l’interaction entre elles. Dans cette étape, vous configurerez les méthodes minimales nécessaires.

      La méthode TRACE, considérée comme inoffensive, a été utilisée pour réaliser des attaques de type Cross Site Tracing. Ces types d’attaques permettent à des acteurs malveillants de voler des sessions d’utilisateurs grâce à cette méthode. La méthode a été conçue à des fins de débogage. Le serveur renvoie la même requête que celle envoyée à l’origine par le client. Comme le cookie de la session du navigateur est envoyé au serveur, il sera renvoyé à nouveau. Cependant, cela peut potentiellement être intercepté par un acteur malveillant, qui peut alors rediriger la connexion d’un navigateur vers un site sous son contrôle et non vers le serveur d’origine.

      En raison de la possibilité d’une utilisation abusive de la méthode TRACE, il est recommandé de ne l’utiliser que pour le débogage et non en production. Dans cette section, vous désactiverez cette méthode.

      Modifiez le fichier httpd.conf avec la commande suivante, puis appuyez sur G pour atteindre la fin du fichier :

      • sudo vi /usr/local/etc/apache24/httpd.conf

      Ajoutez le chemin d’entrée suivant à la fin du fichier :

      /usr/local/etc/apache24/httpd.conf

      . . .
      TraceEnable off
      

      Une bonne pratique consiste à spécifier uniquement les méthodes que vous utiliserez dans votre serveur web Apache HTTP. Cela permettra de limiter les points d’entrée potentiels pour les acteurs malveillants.

      LimitExcept peut être utile à cette fin, car il n’autorise aucune autre méthode que celles qui y sont déclarées. Par exemple, une configuration peut être établie comme celle-ci :

      /usr/local/etc/apache24/httpd.conf

      DocumentRoot "/usr/local/www/apache24/data"
      <Directory "/usr/local/www/apache24/data">
          Options -Indexes +FollowSymLinks -Includes
          AllowOverride none
           <LimitExcept GET POST HEAD>
             deny from all
          </LimitExcept>
          Require all granted
      </Directory>
      

      Comme indiqué dans la directive LimitExcept, seules les méthodes GET, POST et HEAD sont autorisées dans la configuration.

      • La méthode GET fait partie du protocole HTTP et elle est utilisée pour récupérer des données.
      • La méthode POST fait également partie du protocole HTTP et est utilisée pour envoyer des données au serveur.
      • La méthode HEAD est similaire à la méthode GET, mais elle n’a pas d’organe de réponse.

      Vous utiliserez la commande suivante et placerez le bloc LimitExcept à l’intérieur du fichier :

      • sudo vi +272 /usr/local/etc/apache24/httpd.conf

      Pour définir cette configuration, vous placerez le bloc suivant dans l’entrée de la directive DocumentRoot où le contenu sera lu, plus précisément dans l’entrée Directory :

      /usr/local/etc/apache24/httpd.conf

      . . .
      <LimitExcept GET POST HEAD>
         deny from all
      </LimitExcept>
      . . .
      

      Pour appliquer les modifications, redémarrez Apache HTTP :

      La nouvelle directive AllowedMethods offre des fonctionnalités similaires, bien que son statut soit encore expérimental.

      Vous avez vu ce que sont les méthodes HTTP, leur utilisation et la protection qu’elles offrent contre les activités malveillantes se servant de la méthode TRACE, ainsi que la manière de déclarer les méthodes à utiliser. Maintenant, vous allez travailler avec d’autres protections dédiées aux en-têtes et aux cookies HTTP.

      Sécuriser des en-têtes et des cookies

      Au cours de cette étape, vous allez définir des directives spécifiques pour protéger les sessions que les machines clientes ouvriront lorsqu’elles visiteront votre serveur web Apache HTTP. De cette façon, votre serveur ne chargera pas de contenu indésirable, le chiffrage ne sera pas déclassé et vous éviterez que votre contenu soit fouillé.

      Les en-têtes sont des éléments des méthodes de requêtes. Il existe des en-têtes pour ajuster l’authentification, la communication entre le serveur et le client, la mise en cache, la négociation de contenu, etc.

      Les cookies sont des éléments d’information envoyés par le serveur au navigateur. Ces bits permettent au serveur de reconnaître le navigateur du client d’un ordinateur à l’autre. Ils permettent également aux serveurs de reconnaître les sessions des utilisateurs. Ils peuvent, par exemple, suivre le panier d’un utilisateur connecté, ses informations de paiement, son historique, etc. Les cookies sont utilisés et conservés dans le navigateur web du client puisque HTTP est un protocole apatride, ce qui signifie qu’une fois la connexion fermée, le serveur ne se souvient pas de la requête envoyée par un client, ou un autre.

      Il est important de protéger les en-têtes ainsi que les cookies car ils assurent la communication entre le client du navigateur web et le serveur web.

      Le module des en-têtes est activé par défaut. Pour vérifier s’il est chargé, vous utiliserez la commande suivante :

      • sudo apachectl -M | grep 'headers'

      Vous verrez la sortie suivante :

      Output

      headers_module (shared)

      Si vous ne voyez aucune sortie, vérifiez si le module est activé dans le fichier httpd.conf d’Apache :

      • grep -n 'mod_headers' /usr/local/etc/apache24/httpd.conf

      En sortie, vous verrez une ligne non commentée renvoyant au module spécifique pour les en-têtes :

      /usr/local/etc/apache24/httpd.conf

      . . .
      122  LoadModule headers_module libexec/apache24/mod_headers.so
      . . .
      

      Supprimez le hashtag au début de la ligne mod_headers.so, s’il est présent, pour activer la directive.

      En utilisant les directives HTTP Apache suivantes, vous protégerez les en-têtes et les cookies contre les activités malveillantes, afin de réduire le risque pour les clients et les serveurs.

      Vous allez maintenant régler la protection de l’en-tête. Vous placerez toutes ces valeurs d’en-tête dans un seul bloc. Vous pouvez choisir d’appliquer ces valeurs comme vous le souhaitez, mais toutes sont recommandées.

      Modifiez le fichier httpd.conf avec la commande suivante, puis appuyez sur G pour atteindre la fin du fichier :

      • sudo vi /usr/local/etc/apache24/httpd.conf

      Placez le bloc suivant à la fin du fichier :

      /usr/local/etc/apache24/httpd.conf

      . . .
      <IfModule mod_headers.c>
        # Add security and privacy related headers
        Header set Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;"
        Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
        Header always edit Set-Cookie (.*) "$1; HttpOnly; Secure"
        Header set X-Content-Type-Options "nosniff"
        Header set X-XSS-Protection "1; mode=block"
        Header set Referrer-Policy "strict-origin"
        Header set X-Frame-Options: "deny"
        SetEnv modHeadersAvailable true
      </IfModule>
      
      • Jeu d'en-tête Strict-Transport-Security "max-age=31536000 ; includeSubDomains" : le HTTP Strict Transport Security (HTSTS) est un mécanisme permettant aux serveurs et clients web (principalement les navigateurs) d’établir des communications en utilisant uniquement le HTTPS. En l’implémentant, vous évitez les attaques de type “man-in-the-middle”, où une tierce partie entre les communications pourrait potentiellement accéder aux bits, mais aussi les altérer.

      • En-tête always edit Set-Cookie (. *) "$1 ; HttpOnly ; Secure" : les drapeaux HttpOnly et Secure sur les en-têtes aident à prévenir les attaques de type “cross-site scripting”, également connues sous le nom de XSS. Les cookies peuvent être utilisés à mauvais escient par les pirates pour se faire passer pour des visiteurs légitimes se présentant comme quelqu’un d’autre (vol d’identité), ou être trafiqués.

      • En-tête Referrer-Policy "strict-origin" : l’en-tête Referrer-Policy définit les informations qui sont incluses en tant qu’informations de référence dans le champ d’en-tête.

      • En-tête Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;": l’en-tête Content-Security-Policy (CSP) empêchera complètement le chargement de contenu non spécifié dans les paramètres, ce qui est utile pour prévenir les attaques par script inter-sites (XSS). Il existe de nombreux paramètres possibles pour configurer la politique pour cet en-tête. L’essentiel est de le configurer pour charger le contenu du même site et de mettre à jour tout contenu ayant une origine HTTP.

      • En-tête X-XSS-Protection "1; mode=block" : cette option prend en charge les anciens navigateurs qui ne sont pas compatibles avec les en-têtes Content-Security-Policy. L’en-tête ‘X-XSS-Protection’ assure une protection contre les attaques de type Cross-Site Scripting. Vous n’avez pas besoin de définir cet en-tête, sauf si vous devez prendre en charge d’anciennes versions de navigateur, ce qui est rare.

      • En-tête X-Frame-Options: "deny": cela permet d’éviter les attaques de type “clickjacking”. L’en-tête “X-Frame-Options” indique au navigateur si une page peut être rendue dans un <frame>, <iframe>, <embed> ou <object>. Ainsi, le contenu d’autres sites ne peut pas être intégré à d’autres, ce qui empêche les attaques de type “clickjacking”. Ici, vous refusez tout rendu de trame afin que la page web ne puisse être intégrée nulle part ailleurs, pas même à l’intérieur du même site web. Vous pouvez l’adapter à vos besoins, si, par exemple, vous devez autoriser le rendu de certaines pages parce qu’il s’agit de publicités ou de collaborations avec des sites web spécifiques.

      • En-tête X-Content-Type-Options "nosniff": l’en-tête “X-Content-Type-Options” contrôle les types MIME afin qu’ils ne soient pas modifiés et suivis. Les types MIME sont des normes de format de fichier ; ils fonctionnent pour le texte, l’audio, la vidéo, l’image, etc. Cet en-tête empêche les acteurs malveillants de fouiller le contenu de ces fichiers et d’essayer de modifier les types de fichiers.

      Redémarrez maintenant Apache pour que les modifications prennent effet :

      Pour vérifier les niveaux de sécurité de vos paramètres de configuration, visitez le site web des en-têtes de sécurité. Après avoir suivi les étapes de ce tutoriel, votre domaine obtiendra la note A.

      Remarque : si vous faites vérifier vos en-têtes en visitant https://securityheaders.com/ et que vous obtenez une note F, cela pourrait être dû au fait qu’il n’y a pas d’index.html dans le DocumentRoot de votre site, comme indiqué à la fin de l’étape 2. Si, en vérifiant vos en-têtes, vous obtenez une note différente d’un A ou d’un F, vérifiez chaque ligne de l'ensemble des en-têtes à la recherche de toute faute d’orthographe qui aurait pu causer le déclassement.

      Dans cette étape, vous avez utilisé jusqu’à sept paramètres pour améliorer la sécurité de vos en-têtes et cookies. Ces mesures permettront d’éviter les attaques de type Cross-Site Scripting, le “clickjacking” et d’autres types d’attaques.

      Conclusion

      Dans ce tutoriel, vous avez abordé plusieurs aspects liés à la sécurité, à la divulgation d’informations à la protection des sessions, en passant par la définition d’autres paramètres de configuration pour les fonctionnalités importantes.

      Pour d’autres ressources concernant le renforcement d’Apache, voici quelques autres références :

      Pour connaître des outils supplémentaires de protection d’Apache HTTP :



      Source link

      Étapes recommandées pour la mise en place d’un cluster DigitalOcean Kubernetes


      L’auteur a choisi Open Sourcing Mental Illness pour recevoir un don dans le cadre du programme Write for DOnations.

      Introduction

      Kubernetes, la plateforme open-source d’orchestration de conteneurs, devient progressivement la solution privilégiée pour l’automatisation, la mise à l’échelle et la gestion des clusters à haute disponibilité. En raison de sa popularité croissante, la sécurité de Kubernetes est devenue de plus en plus pertinente.

      Compte tenu des pièces mobiles impliquées dans Kubernetes et de la variété des scénarios de déploiement, la sécurisation de Kubernetes peut parfois être complexe. Pour cette raison, l’objectif de cet article est de fournir une base de sécurité solide pour un cluster DigitalOcean Kubernetes (DOKS). Veuillez noter que ce tutoriel couvre les mesures de sécurité de base pour Kubernetes, et se veut un point de départ plutôt qu’un guide exhaustif. Pour les étapes supplémentaires, voir la documentation officielle de Kubernetes.

      Dans ce guide, vous prendrez les mesures de base pour sécuriser votre cluster Kubernetes DigitalOcean. Vous devrez configurer une authentification locale sécurisée avec des certificats TLS/SSL, accorder des autorisations aux utilisateurs locaux avec des contrôles d’accès basés sur les rôles (RBAC), accorder des autorisations aux applications Kubernetes et aux déploiements avec des comptes de service, et définir des limites de ressources avec les contrôleurs d’admission ResourceQuota et LimitRange.

      Conditions préalables

      Pour pouvoir compléter ce tutoriel, vous aurez besoin de :

      Étape 1 – Activation de l’authentification des utilisateurs à distance

      Après avoir rempli les conditions préalables, vous vous retrouverez avec un super-utilisateur Kubernetes qui s’authentifiera grâce à un jeton du porteur DigitalOcean prédéfini. Toutefois, le partage de ces identifiants n’est pas une bonne pratique de sécurité, car ce compte peut entraîner des modifications à grande échelle et éventuellement destructrices de votre cluster. Pour limiter cette possibilité, vous pouvez configurer des utilisateurs supplémentaires à authentifier à partir de leurs clients locaux respectifs.

      Dans cette section, vous allez authentifier les nouveaux utilisateurs du cluster DOKS distant à partir de clients locaux en utilisant des certificats SSL/TLS sécurisés. Il s’agira d’un processus en trois étapes : Tout d’abord, vous allez créer des demandes de signature de certificats (CSR) pour chaque utilisateur, puis vous approuverez ces certificats directement dans le cluster par l’intermédiaire de kubectl. Enfin, vous construirez pour chaque utilisateur un fichier kubeconfig avec les certificats appropriés. Pour plus d’informations sur les méthodes d’authentification supplémentaires prises en charge par Kubernetes, consultez la documentation sur l’authentification Kubernetes.

      Création de demandes de signature de certificats pour les nouveaux utilisateurs

      Avant de commencer, vérifiez la connexion au cluster DOKS depuis la machine locale configurée lors des prérequis :

      En fonction de votre configuration, la sortie sera similaire à celle-ci :

      Output

      Kubernetes master is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com CoreDNS is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

      Cela signifie que vous êtes connecté au cluster DOKS.

      Ensuite, créez un dossier local pour les certificats des clients. Pour les besoins de ce guide,~/certs seront utilisés pour stocker tous les certificats :

      Dans ce tutoriel, nous allons autoriser un nouvel utilisateur appelé sammy à accéder au cluster.  N’hésitez pas à modifier cela pour un utilisateur de votre choix. En utilisant la bibliothèque SSL et TLS OpenSSL, générez une nouvelle clé privée pour votre utilisateur en utilisant la commande suivante :

      • openssl genrsa -out ~/certs/sammy.key 4096

      Le drapeau -out rendra le fichier de sortie ~/certs/sammy.key, et 4096 définit la clé comme 4096-bit. Pour plus d’informations sur OpenSSL, consultez notre guide Les essentiels d’OpenSSL.

      Maintenant, créez un fichier de configuration de la demande de signature de certificat. Ouvrez le fichier suivant avec un éditeur de texte (pour ce tutoriel, nous utiliserons nano) :

      • nano ~/certs/sammy.csr.cnf

      Ajoutez le contenu suivant dans le fichier sammy.csr.cnf pour spécifier dans le sujet le nom d’utilisateur souhaité comme nom commun (CN), et le groupe comme organisation (O) :

      ~/certs/sammy.csr.cnf

      [ req ]
      default_bits = 2048
      prompt = no
      default_md = sha256
      distinguished_name = dn
      [ dn ]
      CN = sammy
      O = developers
      [ v3_ext ]
      authorityKeyIdentifier=keyid,issuer:always
      basicConstraints=CA:FALSE
      keyUsage=keyEncipherment,dataEncipherment
      extendedKeyUsage=serverAuth,clientAuth
      

      Le fichier de configuration de la demande de signature de certificat contient toutes les informations nécessaires, l’identité de l’utilisateur et les paramètres d’utilisation appropriés pour l’utilisateur. Le dernier argument extendedKeyUsage=serverAuth,clientAuth permettra aux utilisateurs d’authentifier leurs clients locaux avec le cluster DOKS en utilisant le certificat une fois qu’il sera signé.

      Ensuite, créez la demande de signature du certificat sammy :

      • openssl req -config ~/certs/sammy.csr.cnf -new -key ~/certs/sammy.key -nodes -out ~/certs/sammy.csr

      Le paramètre -config vous permet de spécifier le fichier de configuration pour le CSR, et -new signale que vous créez une nouvelle CSR pour la clé spécifiée par -key.

      Vous pouvez vérifier votre demande de signature de certificat en exécutant la commande suivante :

      • openssl req -in ~/certs/sammy.csr -noout -text

      Ici vous passez dans le CSR avec -in et utilisez -text pour imprimer la demande de certificat en texte.

      La sortie montrera la demande de certificat, dont le début ressemblera à ceci :

      Output

      Certificate Request: Data: Version: 1 (0x0) Subject: CN = sammy, O = developers Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (4096 bit) ...

      Répétez la même procédure pour créer des RSC pour tout utilisateur supplémentaire. Une fois que vous avez enregistré toutes les demandes de signature de certificats dans le dossier ~/certs de l’administrateur, passez à l’étape suivante pour les approuver.

      Gérer les demandes de signature de certificats avec l’API Kubernetes

      Vous pouvez soit approuver soit refuser les certificats TLS délivrés à l’API Kubernetes en utilisant l’outil de ligne de commande kubectl. Cela vous donne la possibilité de vous assurer que l’accès demandé est approprié pour l’utilisateur donné. Dans cette section, vous enverrez la demande de certificat pour sammy et l’approuverez.

      Pour envoyer une CSR au cluster DOKS, utilisez la commande suivante cluster

      cat <<EOF | kubectl apply -f -
      apiVersion: certificates.k8s.io/v1beta1
      kind: CertificateSigningRequest
      metadata:
        name: sammy-authentication
      spec:
        groups:
        - system:authenticated
        request: $(cat ~/certs/sammy.csr | base64 | tr -d 'n')
        usages:
        - digital signature
        - key encipherment
        - server auth
        - client auth
      EOF
      

      En utilisant un document Bash here, cette commande utilise cat pour transmettre la demande de certificat à kubectl apply.

      Examinons de plus près la demande de certificat :

      • nom : sammy-authentication crée un identificateur de métadonnées, dans ce cas appelé sammy-authentication.
      • request : $(cat ~/certs/sammy.csr | base64 | tr -d 'n') envoie la demande de signature du certificat sammy.csr au cluster encodé en Base64.
      • L'autorisation du serveur et l'autorisation du client précisent l’utilisation prévue du certificat. Dans ce cas, l’objectif est l’authentification de l’utilisateur.

      Le résultat sera similaire à celui-ci :

      Output

      certificatesigningrequest.certificates.k8s.io/sammy-authentication created

      Vous pouvez vérifier le statut de la demande de signature de certificat en utilisant la commande :

      Selon la configuration de votre cluster, le résultat sera similaire à celui-ci :

      Output

      NAME AGE REQUESTOR CONDITION sammy-authentication 37s your_DO_email Pending

      Ensuite, approuvez la CSR en utilisant la commande CSR

      • kubectl certificate approve sammy-authentication

      Vous recevrez un message confirmant l’opération :

      Output

      certificatesigningrequest.certificates.k8s.io/sammy-authentication approved

      Remarque : En tant qu’administrateur, vous pouvez également refuser une CSR en utilisant la commande kubectl certificate deny sammy-authentication. Pour plus d’informations sur la gestion des certificats TLS, veuillez lire la documentation officielle de Kubernetes.

      Maintenant que la RSE est approuvée, vous pouvez la télécharger sur la machine locale en exécutant :

      • kubectl get csr sammy-authentication -o jsonpath='{.status.certificate}' | base64 --decode > ~/certs/sammy.crt

      Cette commande décode le certificat Base64 pour une utilisation correcte par kubectl, puis l’enregistre sous la forme ~/certs/sammy.crt.

      Avec le certificat signé sammy en main, vous pouvez maintenant construire le fichier kubeconfig de l’utilisateur.

      Construire des utilisateurs distants Kubeconfig

      Ensuite, vous allez créer un fichier kubeconfig spécifique pour l’utilisateur sammy. Cela vous permettra de mieux contrôler l’accès de l’utilisateur à votre cluster.

      La première étape de la construction d’un nouveau kubeconfig consiste à faire une copie du fichier kubeconfig actuel. Pour les besoins de ce guide, le nouveau fichier kubeconfig s’appelleraconfig-sammy :

      • cp ~/.kube/config ~/.kube/config-sammy

      Ensuite, modifiez le nouveau fichier :

      • nano ~/.kube/config-sammy

      Conservez les huit premières lignes de ce fichier, car elles contiennent les informations nécessaires à la connexion SSL/TLS avec le cluster. Ensuite, en partant du paramètre utilisateur, remplacez le texte par les lignes surlignées suivantes afin que le fichier ressemble à ce qui suit :

      config-sammy

      apiVersion: v1
      clusters:
      - cluster:
          certificate-authority-data: certificate_data
        name: do-nyc1-do-cluster
      contexts:
      - context:
          cluster: do-nyc1-do-cluster
          user: sammy
        name: do-nyc1-do-cluster
      current-context: do-nyc1-do-cluster
      kind: Config
      preferences: {}
      users:
      - name: sammy
        user:
          client-certificate: /home/your_local_user/certs/sammy.crt
          client-key: /home/your_local_user/certs/sammy.key
      

      Remarque : pour le certificat-client et la clé-client, utilisez le chemin d’accès absolu à l’emplacement du certificat correspondant. Dans le cas contraire, kubectl produira une erreur.

      Enregistrez et quittez le fichier.

      Vous pouvez tester la connexion du nouvel utilisateur en utilisant kubectl cluster-info :

      • kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy cluster-info

      Vous verrez une erreur similaire à celle-ci :

      Output

      To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. Error from server (Forbidden): services is forbidden: User "sammy" cannot list resource "services" in API group "" in the namespace "kube-system"

      Cette erreur est attendue car l’utilisateur sammy n’a pas encore l’autorisation de lister une ressource sur le cluster. L’octroi d’autorisations aux utilisateurs sera abordé dans la prochaine étape. Pour l’instant, le résultat confirme que la connexion SSL/TLS a réussi et que l’API Kubernetes a accepté les références d’authentification sammy.

      Étape 2 – Autorisation des utilisateurs par le biais du contrôle d’accès basé sur les rôles (RBAC)

      Une fois qu’un utilisateur est authentifié, l’API détermine ses autorisations en utilisant le modèle de contrôle d’accès basé sur les rôles (RBAC) intégré à Kubernetes. Le RBAC est une méthode efficace pour restreindre les droits des utilisateurs en fonction du rôle qui leur est attribué. Du point de vue de la sécurité, le RBAC permet de définir des autorisations précises pour limiter l’accès des utilisateurs à des données sensibles ou l’exécution de commandes au niveau du super-utilisateur. Pour des informations plus détaillées sur les rôles des utilisateurs, veuillez consulter la documentation relative à Kubernetes RBAC.

      Dans cette étape, vous utiliserez kubectl pour attribuer le rôle d’édition prédéfini à l’utilisateur sammy dans l’espace de noms par défaut. Dans un environnement de production, vous souhaiterez peut-être utiliser des rôles personnalisés et/ou des liens de rôles personnalisés.

      Accorder des autorisations

      Dans Kubernetes, accorder des autorisations signifie attribuer le rôle souhaité à un utilisateur. Attribuez des droits d'édition à l’utilisateur sammy dans l’espace de noms par défaut en utilisant la commande suivante :

      • kubectl create rolebinding sammy-edit-role --clusterrole=edit --user=sammy --namespace=default

      Cela donnera un résultat similaire à ce qui suit :

      Output

      rolebinding.rbac.authorization.k8s.io/sammy-edit-role created

      Analysons cette commande plus en détail :

      • créer une liaison de rôle sammy-edit-role crée une nouvelle liaison de rôle, dans ce cas appelée sammy-edit-role.
      • --clusterrole=edit attribue le rôle prédéfini d'édition à une portée globale (rôle de cluster).
      • --user=sammy spécifie à quel utilisateur lier le rôle.
      • --namespace=default accorde à l’utilisateur des autorisations de rôle dans l’espace de noms spécifié, dans ce cas par défaut.

      Ensuite, vérifiez les autorisations des utilisateurs en listant les pods dans l’espace de noms par défaut. Vous pouvez savoir si l’autorisation RBAC fonctionne comme prévu si aucune erreur n’est affichée.

      • kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy auth can-i get pods

      Vous aurez le résultat suivant :

      Output

      yes

      Maintenant que vous avez attribué des autorisations à sammy, vous pouvez vous entraîner à les révoquer dans la section suivante.

      Révoquer les autorisations

      La révocation des autorisations dans Kubernetes se fait en supprimant le rôle obligatoire de l’utilisateur.

      Pour ce tutoriel, supprimez le rôle d'édition de l’utilisateur sammy en exécutant la commande suivante :

      • kubectl delete rolebinding sammy-edit-role

      Vous aurez le résultat suivant :

      Output

      rolebinding.rbac.authorization.k8s.io "sammy-edit-role" deleted

      Vérifiez si les autorisations des utilisateurs ont été révoquées comme prévu en listant les pods d’espace de noms par défaut :

      • kubectl --kubeconfig=/home/localuser/.kube/config-sammy --namespace=default get pods

      Vous recevrez l’erreur suivante :

      Output

      Error from server (Forbidden): pods is forbidden: User "sammy" cannot list resource "pods" in API group "" in the namespace "default"

      Cela montre que l’autorisation a été révoquée.

      Du point de vue de la sécurité, le modèle d’autorisation Kubernetes donne aux administrateurs de clusters la flexibilité nécessaire pour modifier les droits des utilisateurs à la demande. De plus, le contrôle d’accès basé sur les rôles n’est pas limité à un utilisateur physique ; vous pouvez également accorder et retirer des autorisations aux services de cluster, comme vous l’apprendrez dans la section suivante.

      Pour plus d’informations sur l’autorisation RBAC et sur la manière de créer des rôles personnalisés, veuillez lire la documentation officielle.

      Étape 3 – Gestion des autorisations de demande à l’aide de comptes de service

      Comme mentionné dans la section précédente, les mécanismes d’autorisation du RBAC s’étendent au-delà des utilisateurs humains. Les utilisateurs de clusters non humains, tels que les applications, services et processus s’exécutant à l’intérieur des pods, s’authentifient auprès du serveur API en utilisant ce que Kubernetes appelle des comptes de service. Lorsqu’un pod est créé dans un espace de noms, vous pouvez soit le laisser utiliser le compte de service par défaut, soit définir un compte de service de votre choix. La possibilité d’affecter des SAS individuels aux demandes et aux processus donne aux administrateurs la liberté d’accorder ou de révoquer des autorisations selon les besoins. En outre, l’affectation de SAS spécifiques à des applications critiques pour la production est considérée comme une meilleure pratique de sécurité. Comme les comptes de service sont utilisés pour l’authentification, et donc pour les contrôles d’autorisation RBAC, les administrateurs de clusters pourraient contenir les menaces de sécurité en modifiant les droits d’accès aux comptes de service et en isolant le processus incriminé.

      Pour démontrer les comptes de service, ce tutoriel utilisera un serveur web Nginx comme exemple d’application.

      Avant d’attribuer une SA particulière à votre application, vous devez créer la SA. Créez un nouveau compte de service appelé nginx-sa dans l’espace de noms par défaut :

      • kubectl create sa nginx-sa

      Vous obtiendrez :

      Output

      serviceaccount/nginx-sa created

      Vérifiez que le compte de service a été créé en exécutant ce qui suit :

      Vous obtiendrez ainsi une liste de vos comptes de service :

      Output

      NAME SECRETS AGE default 1 22h nginx-sa 1 80s

      Vous allez maintenant attribuer un rôle au compte de service nginx-sa. Pour cet exemple, accordez nginx-sa les mêmes permissions que l’utilisateur sammy :

      • kubectl create rolebinding nginx-sa-edit
      • --clusterrole=edit
      • --serviceaccount=default:nginx-sa
      • --namespace=default

      L’exécution de cette opération donnera les résultats suivants :

      Output

      rolebinding.rbac.authorization.k8s.io/nginx-sa-edit created

      Cette commande utilise le même format que pour l’utilisateur sammy, à l’exception du drapeau --serviceaccount=default:nginx-sa, où vous attribuez le compte de service nginx-sa dans l’espace de noms par défaut.

      Vérifiez que la liaison de rôle a réussi à l’aide de cette commande :

      Cela donnera le résultat suivant :

      Output

      NAME AGE nginx-sa-edit 23s

      Une fois que vous avez confirmé que le rôle obligatoire pour le compte de service a été configuré avec succès, vous pouvez affecter le compte de service à une application. L’attribution d’un compte de service particulier à une application vous permettra de gérer ses droits d’accès en temps réel et donc de renforcer la sécurité du cluster.

      Pour les besoins de ce tutoriel, un pod nginx servira d’exemple d’application. Créez le nouveau pod et spécifiez le compte de service nginx-sa avec la commande suivante :

      • kubectl run nginx --image=nginx --port 80 --serviceaccount="nginx-sa"

      La première partie de la commande crée un nouveau pod faisant tourner un serveur web nginx sur le port :80, et la dernière partie --serviceaccount="nginx-sa" indique que ce pod doit utiliser le compte de service nginx-sa et non le SA par défaut.

      Vous obtiendrez ainsi un résultat similaire à celui qui suit :

      Output

      deployment.apps/nginx created

      Vérifiez que la nouvelle demande utilise le compte de service en utilisant kubectl describe : 

      • kubectl describe deployment nginx

      Cela donnera lieu à une longue description des paramètres de déploiement. Sous la section Modèle de Pod, vous verrez un résultat similaire à celui-ci :

      Output

      ... Pod Template: Labels: run=nginx Service Account: nginx-sa ...

      Dans cette section, vous avez créé le compte de service nginx-sa dans l’espace de noms par défaut et l’avez attribué au serveur web nginx. Vous pouvez désormais contrôler les autorisations de nginx en temps réel en modifiant son rôle si besoin est. Vous pouvez également regrouper les demandes en attribuant le même compte de service à chacune d’entre elles, puis apporter des modifications en masse aux autorisations. Enfin, vous pourriez isoler les applications critiques en leur attribuant un SA unique.

      En résumé, l’idée qui sous-tend l’attribution des rôles à vos applications/déploiements est d’affiner les autorisations. Dans les environnements de production du monde réel, vous pouvez avoir plusieurs déploiements nécessitant différentes autorisations allant de la lecture seule à des privilèges administratifs complets. L’utilisation du RBAC vous donne la possibilité de restreindre l’accès au cluster selon vos besoins.

      Ensuite, vous mettrez en place des contrôleurs d’admission pour contrôler les ressources et se prémunir contre les attaques de privation de ressources.

      Étape 4 – Mise en place des contrôleurs d’admission

      Les contrôleurs d’admission Kubernetes sont des plug-ins optionnels qui sont compilés dans le binaire kube-apiserver pour élargir les options de sécurité. Les contrôleurs d’admission interceptent les demandes après qu’elles aient passé la phase d’authentification et d’autorisation. Une fois que la demande est interceptée, les contrôleurs d’admission exécutent le code spécifié juste avant que la demande ne soit appliquée.

      Si le résultat d’un contrôle d’authentification ou d’autorisation est un booléen qui autorise ou refuse la demande, les contrôleurs d’admission peuvent être beaucoup plus divers. Les contrôleurs d’admission peuvent valider les demandes de la même manière que l’authentification, mais ils peuvent également faire muter ou modifier les demandes et modifier les objets avant de les admettre.

      Dans cette étape, vous utiliserez les contrôleurs d’admission ResourceQuota et LimitRange pour protéger votre cluster en faisant muter les demandes qui pourraient contribuer à une pénurie de ressources ou à une attaque par déni de service. Le contrôleur d’admission ResourceQuota permet aux administrateurs de restreindre les ressources informatiques, les ressources de stockage et la quantité de tout objet dans un espace de noms, tandis que le contrôleur d’admission LimitRange limitera le nombre de ressources utilisées par les conteneurs. En utilisant ces deux contrôleurs d’admission ensemble, vous protégerez votre cluster contre les attaques qui rendent vos ressources indisponibles.

      Pour montrer comment fonctionne ResourceQuota, vous allez mettre en place quelques restrictions dans l’espace de noms par défaut. Commencez par créer un nouveau fichier objet ResourceQuota :

      • nano resource-quota-default.yaml

      Ajoutez la définition d’objet suivante pour définir les contraintes de consommation de ressources dans l’espace de noms par défaut. Vous pouvez ajuster les valeurs selon les besoins en fonction des ressources physiques de vos nœuds :

      resource-quota-default.yaml

      apiVersion: v1
      kind: ResourceQuota
      metadata:
        name: resource-quota-default
      spec:
        hard:
          pods: "2"
          requests.cpu: "500m"
          requests.memory: 1Gi
          limits.cpu: "1000m"
          limits.memory: 2Gi
          configmaps: "5"
          persistentvolumeclaims: "2"
          replicationcontrollers: "10"
          secrets: "3"
          services: "4"
          services.loadbalancers: "2"
      

      Cette définition utilise le mot-clé hard pour fixer des contraintes strictes, telles que le nombre maximum de pods, les configmaps, les PersistentVolumeClaims, les ReplicationController, les secrets, les services et les loadbalancers. Cela impose également des contraintes en matière de ressources informatiques, par exemple :

      • requests.cpu, qui fixe la valeur CPU maximale des requêtes en milliCPU, soit un millième d’un noyau CPU.
      • requests.memory, qui fixe la valeur maximale de la mémoire des requêtes en octets.
      • limits.cpu, qui fixe la valeur CPU maximale des limites en milliCPU.
      • limits.memory, qui fixe la valeur maximale de la mémoire des limites en octets.

      Enregistrez et quittez le fichier.

      Maintenant, créez l’objet dans l’espace de noms en exécutant la commande suivante :

      • kubectl create -f resource-quota-default.yaml --namespace=default

      Il en résultera ce qui suit :

      Output

      resourcequota/resource-quota-default created

      Notez que vous utilisez le drapeau -f pour indiquer à Kubernetes l’emplacement du fichier ResourceQuota et le drapeau --namespace pour préciser quel espace de noms sera mis à jour.

      Une fois l’objet créé, votre ResourceQuota sera actif. Vous pouvez vérifier les quotas d’espace de noms par défaut avec le quota de description :

      • kubectl describe quota --namespace=default

      La sortie sera similaire à celle-ci, avec les limites strictes que vous avez définies dans le fichier resource-quota-default.yaml :

      Output

      Name: resource-quota-default Namespace: default Resource Used Hard -------- ---- ---- configmaps 0 5 limits.cpu 0 1 limits.memory 0 2Gi persistentvolumeclaims 0 2 pods 1 2 replicationcontrollers 0 10 requests.cpu 0 500m requests.memory 0 1Gi secrets 2 3 services 1 4 services.loadbalancers 0 2

      Les quotas de ressources sont exprimés en unités absolues, de sorte que l’ajout de nœuds supplémentaires n’augmentera pas automatiquement les valeurs définies ici. Si d’autres nœuds sont ajoutés, vous devrez modifier manuellement les valeurs ici pour proportionner les ressources. Les quotas de ressources peuvent être modifiés aussi souvent que nécessaire, mais ils ne peuvent être supprimés que si l’espace de noms entier est supprimé.

      Si vous devez modifier un quota de ressources particulier, mettez à jour le fichier .yaml correspondant et appliquez les modifications à l’aide de la commande suivante :

      • kubectl apply -f resource-quota-default.yaml --namespace=default

      Pour plus d’informations sur le ResourceQuota Admission Controller, reportez-vous à la documentation officielle.

      Maintenant que votre quota de ressources est configuré, vous allez passer à la configuration du LimitRange Admission Controller. De la même manière que le ResourceQuota fait respecter les limites des espaces de noms, le LimitRange fait respecter les limites déclarées en validant et en faisant muter les conteneurs.

      De la même manière qu’auparavant, commencez par créer le fichier objet :

      • nano limit-range-default.yaml

      Maintenant, vous pouvez utiliser l’objet LimitRange pour restreindre l’utilisation des ressources selon les besoins. Ajoutez le contenu suivant comme exemple d’un cas d’utilisation typique :

      limit-ranges-default.yaml

      apiVersion: v1
      kind: LimitRange
      metadata:
        name: limit-range-default
      spec:
        limits:
        - max:
            cpu: "400m"
            memory: "1Gi"
          min:
            cpu: "100m"
            memory: "100Mi"
          default:
            cpu: "250m"
            memory: "800Mi"
          defaultRequest:
            cpu: "150m"
            memory: "256Mi"
          type: Container
      

      Les valeurs d’échantillon utilisées dans limit-ranges-default.yaml limitent la mémoire du conteneur à un maximum de 1Gi et limitent l’utilisation du CPU à un maximum de 400m, ce qui est une métrique de Kubernetes équivalente à 400 milliCPU, ce qui signifie que le conteneur est limité à utiliser presque la moitié de son cœur.

      Ensuite, déployez l’objet sur le serveur API à l’aide de la commande suivante :

      • kubectl create -f limit-range-default.yaml --namespace=default

      Cela donnera le résultat suivant :

      Output

      limitrange/limit-range-default created

      Vous pouvez maintenant vérifier les nouvelles limites avec la commande suivante :

      • kubectl describe limits --namespace=default

      Votre résultat sera similaire à celui-ci :

      Output

      Name: limit-range-default Namespace: default Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio ---- -------- --- --- --------------- ------------- ----------------------- Container cpu 100m 400m 150m 250m - Container memory 100Mi 1Gi 256Mi 800Mi -

      Pour voir LimitRanger en action, déployez un conteneur nginx standard avec la commande suivante :

      • kubectl run nginx --image=nginx --port=80 --restart=Never

      Cela donnera le résultat suivant :

      Output

      pod/nginx created

      Vérifiez comment le contrôleur d’admission a fait muter le conteneur en exécutant la commande suivante :

      • kubectl get pod nginx -o yaml

      Cela donnera de nombreuses lignes de résultats. Consultez la section sur les spécifications des conteneurs pour trouver les limites de ressources spécifiées dans le LimitRange Admission Controller :

      Output

      ... spec: containers: - image: nginx imagePullPolicy: IfNotPresent name: nginx ports: - containerPort: 80 protocol: TCP resources: limits: cpu: 250m memory: 800Mi requests: cpu: 150m memory: 256Mi ...

      Ce serait la même chose que si vous déclariez manuellement les ressources et les demandes dans la spécification du conteneur.

      Dans cette étape, vous avez utilisé les contrôleurs d’admission ResourceQuota et LimitRange pour vous protéger contre les attaques malveillantes envers les ressources de votre cluster. Pour plus d’informations sur le contrôleur d’admission LimitRange, consultez la documentation officielle.

      Conclusion

      Tout au long de ce guide, vous avez configuré un modèle de sécurité Kubernetes de base. Cela a permis d’établir l’authentification et l’autorisation des utilisateurs, les privilèges des applications et la protection des ressources des clusters. En combinant toutes les suggestions couvertes dans cet article, vous aurez une base solide pour le déploiement du cluster de production Kubernetes. A partir de là, vous pouvez commencer à renforcer les différents aspects de votre cluster en fonction de votre scénario.

      Si vous souhaitez en savoir plus sur Kubernetes, consultez notre page de ressources Kubernetes, ou suivez notre cours autogéré Kubernetes pour les développeurs Full-Stack.



      Source link