Technologies d'isolation Lambda
Pour protéger les workers et les environnements d'exécution, Lambda utilise diverses technologies d'isolation propriétaires et open source. Chaque environnement d'exécution contient une copie dédiée des éléments suivants :
-
Le code de la version de fonction particulière
-
Toutes les couches AWS Lambda sélectionnées pour la version de votre fonction
-
Le composant d'exécution de la fonction choisie (par exemple, Java 11, NodeJS 12, Python 3.8, etc.) ou le composant d'exécution personnalisé de la fonction
-
Un répertoire /tmp accessible en écriture
-
Un espace utilisateur
Linux minimal basé sur Amazon Linux 2
Les environnements d'exécution sont isolés les uns des autres à l'aide de plusieurs technologies de type conteneur intégrées au noyau Linux, ainsi que des technologies d'isolation propriétaires d'AWS. Notamment :
-
cgroups
: technologie utilisée pour restreindre l'accès de la fonction au processeur et à la mémoire. -
espaces de noms
: chaque environnement d'exécution s'exécute dans un espace de noms dédié. Pour ce faire, des ID de processus de groupe uniques, des ID utilisateur, des interfaces réseau et d'autres ressources gérées par le noyau Linux sont en place. -
seccomp-bpf
: permet de limiter les appels système (syscalls) qui peuvent être utilisés depuis l'environnement d'exécution. -
iptables
et tables de routage : permet d'empêcher les communications réseau entrantes et d'isoler les connexions réseau entre les micro-machines virtuelles. -
chroot
: fournit un accès limité au système de fichiers sous-jacent. -
Configuration de Firecracker : permet de limiter le débit du périphérique de stockage en mode bloc et du périphérique réseau.
-
Fonctions de sécurité de Firecracker : pour en savoir plus sur la conception de sécurité actuelle de Firecracker, consultez le dernier document de conception de Firecracker
.
Outre les technologies d'isolation propriétaires d'AWS, ces mécanismes fournissent une isolation solide entre les environnements d'exécution.
Stockage et état
Les environnements d'exécution ne sont jamais réutilisés entre différentes versions de fonction ou différents clients. En revanche, un seul environnement peut être réutilisé entre les appels de la même version de fonction. Cela signifie que les données et l'état peuvent persister entre les appels. Les données et/ou l'état peuvent persister pendant des heures avant d'être détruits dans le cadre de la gestion normale du cycle de vie de l'environnement d'exécution. Pour des raisons de performances, les fonctions peuvent tirer parti de ce comportement afin d'améliorer l'efficacité en conservant et en réutilisant des caches locaux ou des connexions de longue durée entre les appels. Dans un environnement d'exécution, ces appels multiples sont gérés par un seul processus, de sorte que tout état à l'échelle du processus (tel qu'un état statique en Java) peut être disponible pour de futurs appels à réutiliser, si l'appel se produit dans un environnement d'exécution réutilisé.
Chaque environnement d'exécution Lambda inclut également un système de fichiers accessible en écriture, disponible dans /tmp. Les environnements d'exécution n'ont pas accès à ce stockage et ne peuvent pas le partager. De même que pour l'état du processus, les fichiers écrits dans /tmp sont conservés pendant toute la durée de vie de l'environnement d'exécution. Cela permet d'amortir des opérations de transfert coûteuses, telles que le téléchargement de modèles ML (machine learning), sur plusieurs appels. Les fonctions qui ne souhaitent pas conserver les données entre les appels ne doivent pas les écrire dans /tmp ou doivent supprimer leurs fichiers de /tmp entre chaque appel. Le répertoire /tmp est soutenu par un stockage d'instances Amazon EC2 et est chiffré au repos.
Les clients qui souhaitent conserver les données dans le système de fichiers en dehors de l'environnement d'exécution doivent envisager d'utiliser l'intégration de Lambda à Amazon Elastic File System
Si les clients ne souhaitent pas conserver les données ou l'état entre les appels, Lambda leur recommande de ne pas utiliser l'environnement ou le contexte d'exécution pour stocker des données ou un état. S'ils souhaitent empêcher activement les fuites de données ou d'état entre les appels, Lambda leur recommande de créer des fonctions distinctes pour chaque état. Lambda ne recommande pas aux clients d'utiliser ou de stocker les états affectant la sécurité dans l'environnement d'exécution, car ils peuvent subir une mutation entre les appels. Nous vous recommandons plutôt de recalculer l'état à chaque appel.
