Présentation des fonctionnalités de sécurité

Cette page présente les fonctionnalités de sécurité de Container-Optimized OS exécuté sur Google Cloud.

Sécurité de l'OS

Basé sur Chromium OS, Container-Optimized OS de Google applique plusieurs principes de conception de la sécurité afin de fournir une plate-forme bien configurée pour l'exécution de services de production.

Encombrement minimal de l'OS

Ce principe est au cœur de la sécurité de Container-Optimized OS. Étant donné que ce dernier est conçu pour exécuter les conteneurs et que les conteneurs créent des packages de leurs propres dépendances, nous pouvons supprimer les packages inutiles et minimiser ainsi la surface d'attaque du système d'exploitation.

Système de fichiers racine immuable et démarrage validé

Le système de fichiers racine de Container-Optimized OS est toujours installé en lecture seule. De plus, sa somme de contrôle est calculée au moment de la compilation et vérifiée par le noyau à chaque démarrage. Ce mécanisme empêche les pirates informatiques de "posséder" la machine par le biais de modifications locales permanentes. En outre, plusieurs autres installations ne sont pas exécutables par défaut. Pour en savoir plus, consultez la section Système de fichiers.

Configuration sans état

Bien qu'un système de fichiers racine en lecture seule soit propice à la sécurité, il peut rendre le système difficile à utiliser. Par exemple, nous devons avoir la possibilité de créer et d'ajouter des utilisateurs afin de se connecter au système. Pour résoudre ce problème, le système de fichiers racine est personnalisé de sorte que /etc/ soit accessible en écriture, mais sans état. Cela permet d'écrire les paramètres de configuration au moment de l'exécution, mais ces derniers ne sont pas conservés après les redémarrages. Ainsi, chaque fois qu'un nœud de Container-Optimized OS redémarre, il retourne à son état d'origine. Certaines données telles que les répertoires d'accueil des utilisateurs, les journaux et les images Docker persistent après les redémarrages, car elles ne font pas partie du système de fichiers racine.

Noyau à sécurité renforcée

Container-Optimized OS permet plusieurs fonctionnalités de renforcement de la sécurité du noyau, telles que l'architecture de mesure de l'intégrité (IMA), l'audit, l'isolation de tables de pages noyau (KPTI) et certains modules de sécurité Linux (LSM) de Chromium OS. De plus, Container-Optimized OS est compatible avec des fonctionnalités de sécurité telles que seccomp et AppArmor, qui permettent d'appliquer des règles de sécurité plus précises.

Valeurs par défaut axées sur la sécurité

Container-Optimized OS offre un autre niveau de renforcement de la sécurité en fournissant des valeurs par défaut axées sur la sécurité pour plusieurs fonctionnalités. Cela inclut des éléments tels que les paramètres sysctl qui désactivent la fonction ptrace et les filtres BPF non privilégiés, verrouillent le pare-feu, etc. Lorsqu'elles sont automatiquement appliquées à la flotte d'instances, ces valeurs par défaut permettent de sécuriser l'ensemble du cluster, du projet et de l'organisation.

Mises à jour automatiques

La fonctionnalité de mises à jour automatiques de Container-Optimized OS permet la distribution rapide des correctifs de sécurité aux VM en cours d'exécution. Lorsque Container-Optimized OS est géré par Kubernetes Engine, les mises à niveau automatiques des nœuds établissent un équilibre entre sécurité et stabilité.

Système de fichiers

Vous trouverez ci-dessous la liste des chemins d'accès du système de fichiers dans l'image de nœud Container-Optimized OS, ainsi que leurs propriétés et leur utilisation recommandée :

Chemin Propriétés Objectif
/
  • lecture seule
  • exécutable
Le système de fichiers racine est utilisé en lecture seule pour préserver son intégrité. Le noyau vérifie l'intégrité du système de fichiers racine lors du démarrage et refuse de démarrer en cas d'erreur.
/home
/var
  • accessible en écriture
  • non-exécutable
  • avec état
Ces chemins d'accès sont destinés à stocker des données qui sont conservées pendant toute la durée de vie du disque de démarrage. Ils sont installés à partir de /mnt/stateful_partition.
/var/lib/google
/var/lib/docker
/var/lib/toolbox
  • accessible en écriture
  • exécutable
  • avec état
Ces chemins d'accès sont des répertoires de travail pour les packages Compute Engine (par exemple, le service de gestion des comptes), Docker et Toolbox, respectivement.
/var/lib/cloud
  • accessible en écriture
  • exécutable
  • sans état
  • tmpfs
Ce chemin correspond au répertoire de travail du package cloud-init.
/etc
  • accessible en écriture
  • non-exécutable
  • sans état
  • tmpfs
Contient généralement votre configuration (par exemple, les services systemd définis via cloud-init). Il est judicieux d'enregistrer l'état souhaité de vos instances dans cloud-init, car cloud-init est appliqué lors de la création, ainsi que lors du redémarrage d'une instance.
/tmp
  • accessible en écriture
  • non-exécutable
  • sans état
  • tmpfs
Généralement utilisé comme espace de travail et ne doit pas être utilisé pour stocker des données persistantes.
/mnt/disks
  • accessible en écriture
  • exécutable
  • sans état
  • tmpfs
Vous pouvez installer des disques persistants dans des répertoires sous /mnt/disks.

Pare-feu

Par défaut, Container-Optimized OS est configuré pour abandonner toutes les connexions TCP/UDP entrantes, à l'exception de SSH sur le port 22. Reportez-vous à la section Configurer le pare-feu de l'hôte pour savoir comment modifier la valeur par défaut afin d'ouvrir davantage de ports.

Accès à l'instance

Par défaut, Container-Optimized OS ne contient aucun compte utilisateur accessible. Les comptes utilisateur et les clés SSH sont gérés via des métadonnées d'instance ou de projet ou OS Login. OS Login vous permet de gérer l'accès aux instances à l'aide d'IAM. Elle permet un contrôle des accès plus précis (sudo ou non-sudo), des clés SSH identifiables et une stratégie de connexion organisationnelle.

Le daemon SSH est configuré pour interdire l'authentification par mot de passe et les connexions racine. Cependant, cela n'empêche pas les utilisateurs d'obtenir des droits racine avec sudo après la connexion, sauf si le compte utilisateur est géré avec OS Login.

Sécurité de l'infrastructure

En plus des diverses fonctions de renforcement de la sécurité du système d'exploitation propre, l'équipe Container-Optimized OS prend également la chaîne logistique logicielle très au sérieux et donne la priorité à la sécurité de l'infrastructure lors du développement, de la création et du déploiement d'images, grâce aux années d'expérience acquises avec Chromium OS et Google en général.

Création à partir de la source sur Google

Chaque package de Container-Optimized OS y compris le noyau Linux lui-même, est construit à partir des dépôts de code source de Chromium OS. Cela signifie que nous savons exactement ce qui se passe dans l'OS, qui l'a archivé, dans quelle version il a été introduit, etc. Cela nous permet également de rapidement corriger et mettre à jour tout package en cas de découverte d'une faille, à n'importe quel niveau.

Analyse continue des failles (CVE) et intervention

Un système d'analyse CVE nous alerte chaque fois qu'une faille est découverte dans le noyau ou dans un package de l'OS. C'est le même système que celui utilisé pour détecter les failles dans Android et Chromium OS. La création de versions corrigées est une priorité pour l'équipe de Container-Optimized OS. Elle collabore également avec l'équipe de gestion des incidents de Google pour mettre rapidement à disposition des correctifs de sécurité plus étendus dans Container-Optimized OS.

Processus de test et de qualification

Avant de publier une nouvelle image de Container-Optimized OS dans Google Cloud, nous la testons à plusieurs niveaux : test à données aléatoires du noyau par syzkaller, tests Kubernetes au niveau du cluster, tests d'intégration avec les fonctionnalités de Compute Engine et plusieurs tests de performances. Cela garantit la stabilité et la qualité de nos versions.