Tecnologias de isolamento do Lambda
O Lambda usa uma variedade de tecnologias de isolamento proprietárias e de código aberto para proteger os operadores e os ambientes de execução. Cada ambiente de execução contém uma cópia dedicada dos seguintes itens:
-
O código da versão da função específica
-
Quaisquer camadas do AWS Lambda selecionadas para sua versão de função
-
O tempo de execução da função escolhida (por exemplo, Java 11, NodeJS 12, Python 3.8 e assim por diante) ou o tempo de execução personalizado da função
-
Um diretório /tmp gravável
-
Um espaço mínimo de usuário
Linux baseado no Amazon Linux 2
Os ambientes de execução são isolados uns dos outros usando várias tecnologias semelhantes a contêineres incorporadas ao kernel do Linux, juntamente com tecnologias de isolamento proprietárias da AWS. Essas tecnologias incluem:
-
cgroups
: usado para restringir o acesso da função à CPU e à memória. -
namespaces
: cada ambiente de execução é executado em um namespace dedicado. Fazemos isso tendo IDs de processo de grupo exclusivos, IDs de usuário, interfaces de rede e outros recursos gerenciados pelo kernel do Linux. -
seccomp-bpf
: para limitar as chamadas do sistema (syscalls) que podem ser usadas de dentro do ambiente de execução. -
iptables
e tabelas de roteamento : para evitar comunicações de rede de entrada e isolar conexões de rede entre MVMs. -
chroot
: fornece acesso com escopo ao sistema de arquivos subjacente. -
Configuração do Firecracker: usada para limitar a taxa de transferência do dispositivo de blocos e do dispositivo de rede.
-
Recursos de segurança do Firecracker: para obter mais informações sobre o design de segurança atual do Firecracker, consulte o documento de design mais recente do Firecracker
.
Usados com as tecnologias de isolamento proprietárias da AWS, esses mecanismos fornecem um forte isolamento entre os ambientes de execução.
Armazenamento e estado
Os ambientes de execução nunca são reutilizados em diferentes versões de função ou clientes, mas um único ambiente pode ser reutilizado entre invocações da mesma versão de função. Isso significa que os dados e o estado podem persistir entre as invocações. Os dados e/ou o estado podem continuar a persistir por horas antes de serem destruídos como parte do gerenciamento normal do ciclo de vida do ambiente de execução. Por motivos de performance, as funções podem tirar proveito desse comportamento para melhorar a eficiência, mantendo e reutilizando caches locais ou conexões de longa duração entre invocações. Dentro de um ambiente de execução, essas várias invocações são manipuladas por um único processo. Portanto, qualquer estado de todo o processo (como um estado estático em Java) pode estar disponível para futuras invocações para reutilização, se a invocação ocorrer em um ambiente de execução reutilizado.
Cada ambiente de execução do Lambda também inclui um sistema de arquivos gravável, disponível em /tmp. Esse armazenamento não é acessível nem compartilhado entre os ambientes de execução. Assim como no estado do processo, os arquivos gravados em /tmp permanecem durante toda a vida útil do ambiente de execução. Isso permite que operações de transferência caras, como o download de modelos de machine learning (ML), sejam amortizadas em várias invocações. As funções que não desejam manter os dados entre invocações não devem gravar em /tmp ou excluir seus arquivos de /tmp entre invocações. O diretório /tmp é apoiado por um armazenamento de instância do Amazon EC2 e é criptografado em repouso.
Os clientes que desejam manter os dados no sistema de arquivos fora do ambiente de execução devem considerar o uso da integração do Lambda com o Amazon Elastic File System
Se os clientes não quiserem manter os dados ou o estado em todas as invocações, o Lambda recomenda que eles não usem o contexto de execução ou o ambiente de execução para armazenar dados ou estado. Se os clientes quiserem impedir ativamente o vazamento de dados ou estado nas invocações, o Lambda recomenda que eles criem funções distintas para cada estado. O Lambda não recomenda que os clientes usem ou armazenem o estado confidencial de segurança no ambiente de execução, pois ele pode sofrer mutação entre invocações. Recomendamos recalcular o estado em cada invocação.
