Octroi aux fonctions Lambda d’un accès aux ressources d’un Amazon VPC

Avec Amazon Virtual Private Cloud (Amazon VPC), vous pouvez créer des réseaux privés Compte AWS pour héberger des ressources telles que des instances Amazon Elastic Compute Cloud (Amazon EC2), des instances Amazon Relational Database Service (Amazon RDS) et des instances Amazon. ElastiCache Vous pouvez donner à votre fonction Lambda l’accès aux ressources hébergées dans un Amazon VPC en attachant votre fonction au VPC via les sous-réseaux privés qui contiennent les ressources. Suivez les instructions des sections suivantes pour associer une fonction Lambda à un Amazon VPC à l'aide de la console Lambda, du AWS Command Line Interface (AWS CLI) ou. AWS SAM

Autorisations IAM requises

Pour associer une fonction Lambda à un Amazon VPC de votre Compte AWS, Lambda a besoin des autorisations nécessaires pour créer et gérer les interfaces réseau qu'il utilise afin de permettre à votre fonction d'accéder aux ressources du VPC.

Les interfaces réseau créées par Lambda sont interfaces interface réseau Elastic Hyperplane ou ENI Hyperplane. Pour en savoir plus sur ces interfaces réseau, consultez Présentation des interfaces interface réseau Elastic (ENI) Hyperplane.

Vous pouvez accorder à votre fonction les autorisations dont elle a besoin en associant la politique AWS gérée AWSLambdaVPCAccessExecutionRole au rôle d'exécution de votre fonction. Lorsque vous créez une fonction dans la console Lambda et que vous l’associez à un VPC, Lambda ajoute automatiquement cette politique d’autorisations pour vous.

Si vous préférez créer votre propre politique d’autorisations IAM, veillez à inclure toutes les autorisations suivantes et à les autoriser sur toutes les ressources ("Resource": "*") :

Notez que le rôle de votre fonction n’a besoin de ces autorisations que pour créer les interfaces réseau, et non pour invoquer votre fonction. Vous pouvez toujours appeler votre fonction avec succès lorsqu'elle est associée à un Amazon VPC, même si vous supprimez ces autorisations du rôle d'exécution de votre fonction.

Pour associer votre fonction à un VPC, Lambda doit également vérifier les ressources réseau à l’aide de votre rôle d’utilisateur IAM. Veillez à ce que votre rôle d’utilisateur dispose des autorisations IAM suivantes :

Associer des fonctions Lambda à un Amazon VPC dans votre Compte AWS

Associez votre fonction à un Amazon VPC de votre ordinateur à l'aide Compte AWS de la console Lambda, du AWS CLI ou. AWS SAM Si vous utilisez le AWS CLI ou AWS SAM, ou si vous associez une fonction existante à un VPC à l'aide de la console Lambda, assurez-vous que le rôle d'exécution de votre fonction dispose des autorisations nécessaires répertoriées dans la section précédente.

Les fonctions Lambda ne peuvent pas se connecter directement à un VPC avec la location d’instance dédiée. Pour vous connecter à des ressources dans un VPC dédié, associez-les à un deuxième VPC avec une location par défaut.

Accès à Internet en cas d’attachement à un VPC

Par défaut, les fonctions Lambda ont accès à l’Internet public. Lorsque vous attachez votre fonction à un VPC, son accès est limité aux ressources disponibles au sein de ce VPC. Pour accorder à votre fonction l’accès à Internet, vous devez également configurer le VPC pour qu’il dispose d’un accès à Internet. Pour en savoir plus, veuillez consulter la section Activer l'accès à Internet pour les fonctions VPC-connected Lambda.

Prise en charge d’IPv6

Votre fonction peut se connecter à des ressources dans des sous-réseaux VPC à double pile via IPv6. Cette option est désactivée par défaut. Pour autoriser le trafic IPv6 sortant, utilisez la console ou l’option --vpc-config Ipv6AllowedForDualStack=true avec la commande create-function ou update-function-configuration.

Vous pouvez mettre à jour votre code de fonction pour vous connecter explicitement aux ressources du sous-réseau via IPv6. L’exemple Python suivant ouvre un connecteur logiciel et se connecte à un serveur IPv6.

def connect_to_server(event, context):
    server_address = event['host']
    server_port = event['port']
    message = event['message']
    run_connect_to_server(server_address, server_port, message)

def run_connect_to_server(server_address, server_port, message):
    sock = socket.socket(socket.AF_INET6, socket.SOCK_STREAM, 0)
    try:
        # Send data
        sock.connect((server_address, int(server_port), 0, 0))
        sock.sendall(message.encode())
        BUFF_SIZE = 4096
        data = b''
        while True:
            segment = sock.recv(BUFF_SIZE)
            data += segment
            # Either 0 or end of data
            if len(segment) < BUFF_SIZE:
                break
        return data
    finally:
        sock.close()

Pratiques exemplaires en matière d’utilisation de Lambda avec les Amazon VPC

Pour vous assurer que votre configuration VPC Lambda est conforme aux pratiques exemplaires en la matière, suivez les conseils des sections suivantes.

Bonnes pratiques de sécurité

Pour associer votre fonction Lambda à un VPC, vous devez attribuer au rôle d'exécution de votre fonction un certain nombre d'autorisations Amazon EC2. Ces autorisations sont nécessaires pour créer les interfaces réseau que votre fonction utilise pour accéder aux ressources du VPC. Cependant, ces autorisations sont également accordées implicitement au code de votre fonction. Cela signifie que le code de votre fonction dispose de l’autorisation d’effectuer ces appels d’API Amazon EC2.

Pour suivre le principe du moindre privilège d'accès, ajoutez une politique de refus comme dans l'exemple suivant au rôle d'exécution de votre fonction. Cette politique empêche le code de votre fonction d’appeler les API Amazon EC2, tout en permettant au service Lambda de gérer les ressources VPC en votre nom. La politique utilise la clé de condition lambda:SourceFunctionArn, qui s’applique uniquement aux appels d’API effectués par le code de votre fonction lors de l’exécution. Pour de plus amples informations, veuillez consulter Utilisation de l’ARN de la fonction source pour contrôler le comportement d’accès aux fonctions.

AWS fournit des groupes de sécurité et des listes de contrôle d'accès (ACL) réseau pour renforcer la sécurité de votre VPC. Les groupes de sécurité contrôlent le trafic entrant et sortant de vos ressources, et les ACL de réseau contrôlent le trafic entrant et sortant de vos sous-réseaux. Les groupes de sécurité offrent un contrôle d’accès suffisant pour la plupart des sous-réseaux. Vous pouvez utiliser les ACL réseau si vous souhaitez ajouter une couche de sécurité supplémentaire à votre VPC. Pour obtenir des directives générales sur les pratiques exemplaires en matière de sécurité lors de l’utilisation d’Amazon VPC, consultez Security best practices for your VPC dans le Guide de l’utilisateur Amazon Virtual Private Cloud.

Bonnes pratiques en matière de performances

Lorsque vous attachez votre fonction à un VPC, Lambda vérifie s’il existe une ressource réseau disponible (ENI Hyperplane) à laquelle elle peut se connecter. Les ENI Hyperplane sont associés à une combinaison particulière de groupes de sécurité et de sous-réseaux VPC. Si vous avez déjà associé une fonction à un VPC, le fait de spécifier les mêmes sous-réseaux et groupes de sécurité lorsque vous attachez une autre fonction signifie que Lambda peut partager les ressources du réseau et éviter d'avoir à créer une nouvelle ENI Hyperplane. Pour plus d’informations sur les ENI Hyperplane et leur cycle de vie, consultez Présentation des interfaces interface réseau Elastic (ENI) Hyperplane.

Présentation des interfaces interface réseau Elastic (ENI) Hyperplane

Une ENI Hyperplane est une ressource gérée qui agit comme une interface réseau entre votre fonction Lambda et les ressources auxquelles vous souhaitez que votre fonction se connecte. Le service Lambda crée et gère ces ENI automatiquement lorsque vous attachez votre fonction à un VPC.

Les ENI Hyperplane ne sont pas directement visibles pour vous et vous n'avez pas besoin de les configurer ou de les gérer. Cependant, le fait de connaître leur fonctionnement peut vous aider à comprendre le comportement de votre fonction lorsque vous l'associez à un VPC.

La première fois que vous attachez une fonction à un VPC à l’aide d’une combinaison particulière de sous-réseau et de groupe de sécurité, Lambda crée une ENI Hyperplane. D’autres fonctions de votre compte qui utilisent la même combinaison de sous-réseau et de groupe de sécurité peuvent également utiliser cette ENI. Dans la mesure du possible, Lambda réutilise les ENI existantes pour optimiser l’utilisation des ressources et minimiser la création d’ENI. Chaque Hyperplane ENI prend en charge jusqu'à 65 connections/ports 000 appareils. Si le nombre de connexions dépasse cette limite, Lambda adapte automatiquement le nombre d’ENI en fonction du trafic réseau et des exigences de simultanéité.

Pour les nouvelles fonctions, pendant que Lambda crée un hyperplan ENI, votre fonction reste dans l'état En attente et vous ne pouvez pas l'invoquer. Votre fonction passe à l’état Actif uniquement lorsque l’ENI Hyperplane est prête, ce qui peut prendre plusieurs minutes. Pour les fonctions existantes, vous ne pouvez pas effectuer d'opérations supplémentaires ciblant la fonction, telles que la création de versions ou la mise à jour du code de la fonction, mais vous pouvez continuer à invoquer les versions précédentes de la fonction.

Dans le cadre de la gestion du cycle de vie des ENI, Lambda peut supprimer et recréer des ENI pour équilibrer la charge du trafic réseau entre les ENI ou pour résoudre les problèmes détectés lors des contrôles de santé des ENI. Par ailleurs, si une fonction Lambda reste inactive pendant 14 jours, Lambda récupère n’importe toutes les ENI Hyperplane inutilisées et définit l’état de la fonction à Inactive. La prochaine tentative d’invocation échouera et la fonction entrera à nouveau dans l’état En attente jusqu’à ce que Lambda termine la création ou l’allocation d’une ENI Hyperplane. Nous vous recommandons de ne pas baser votre conception sur la persistance des ENI.

Lorsque vous mettez à jour une fonction pour supprimer sa configuration VPC, Lambda a besoin d'un maximum de 20 minutes pour supprimer l'ENI Hyperplane attaché. Lambda ne supprime l’ENI que si aucune autre fonction (ou version de fonction publiée) n’utilise cette ENI Hyperplane.

Lambda s’appuie sur les permissions du rôle d’exécution de la fonction pour supprimer l’ENI Hyperplane. Si vous supprimez le rôle d’exécution avant que Lambda ne supprime l’ENI Hyperplane, Lambda ne pourra pas la supprimer. Vous pouvez effectuer la suppression manuellement.

Utilisation des clés de condition IAM pour les paramètres du VPC

Vous pouvez utiliser des clés de Lambda-specific condition pour les paramètres VPC afin de fournir des contrôles d'autorisation supplémentaires pour vos fonctions Lambda. Par exemple, vous pouvez exiger que toutes les fonctions de votre organisation soient connectées à un VPC. Vous pouvez également spécifier les sous-réseaux et les groupes de sécurité que les utilisateurs de la fonction peuvent et ne peuvent pas utiliser.

Lambda prend également en charge les clés de condition suivantes dans les stratégies IAM :

L'API Lambda fonctionne CreateFunction et UpdateFunctionConfiguration prend en charge ces clés de condition. Pour de plus amples informations sur l’utilisation de clés de condition dans des stratégies IAM, consultez Éléments de politique JSON IAM : Condition dans le Guide de l’utilisateur IAM.

Exemple de stratégies avec des clés de condition pour les paramètres du VPC

Les exemples suivants montrent comment utiliser les clés de condition pour les paramètres du VPC. Après avoir créé une instruction de politique avec les restrictions souhaitées, ajoutez l’instruction de politique pour l’utilisateur ou le rôle cible.

Assurez-vous que les utilisateurs ne déploient que VPC-connected des fonctions

Pour garantir que tous les utilisateurs ne déploient que des VPC-connected fonctions, vous pouvez refuser les opérations de création et de mise à jour de fonctions qui n'incluent pas d'identifiant VPC valide.

Notez que l’ID de VPC n’est pas un paramètre d’entrée pour la demande CreateFunction ou UpdateFunctionConfiguration. Lambda récupère la valeur de l’ID de VPC en fonction des paramètres du sous-réseau et du groupe de sécurité.

Refuser aux utilisateurs l’accès à des VPC, des sous-réseaux ou des groupes de sécurité spécifiques

Pour refuser aux utilisateurs l’accès à des VPC spécifiques, utilisez StringEquals pour vérifier la valeur de la condition lambda:VpcIds. L’exemple suivant refuse aux utilisateurs l’accès à vpc-1 et vpc-2.

Pour refuser aux utilisateurs l’accès à des sous-réseaux spécifiques, utilisez StringEquals pour vérifier la valeur de la condition lambda:SubnetIds. L’exemple suivant refuse aux utilisateurs l’accès à subnet-1 et subnet-2.

{
      "Sid": "EnforceOutOfSubnet",
      "Action": [
          "lambda:CreateFunction",
          "lambda:UpdateFunctionConfiguration"
       ],
      "Effect": "Deny",
      "Resource": "*",
      "Condition": {
        "ForAnyValue:StringEquals": {
            "lambda:SubnetIds": ["subnet-1", "subnet-2"]
        }
      }
    }
       

Pour refuser aux utilisateurs l’accès à des groupes de sécurité spécifiques, utilisez StringEquals pour vérifier la valeur de la condition lambda:SecurityGroupIds. L’exemple suivant refuse aux utilisateurs l’accès à sg-1 et sg-2.

{
      "Sid": "EnforceOutOfSecurityGroups",
      "Action": [
          "lambda:CreateFunction",
          "lambda:UpdateFunctionConfiguration"
       ],
      "Effect": "Deny",
      "Resource": "*",
      "Condition": {
        "ForAnyValue:StringEquals": {
            "lambda:SecurityGroupIds": ["sg-1", "sg-2"]
        }
      }
    }
  ]
}
        

Autoriser les utilisateurs à créer et à mettre à jour des fonctions avec des paramètres VPC spécifiques

Pour permettre aux utilisateurs d’accéder à des VPC spécifiques, utilisez StringEquals pour vérifier la valeur de la condition lambda:VpcIds. L’exemple suivant permet aux utilisateurs d’accéder à vpc-1 et vpc-2.

Pour permettre aux utilisateurs d’accéder à des sous-réseaux spécifiques, utilisez StringEquals pour vérifier la valeur de la condition lambda:SubnetIds. L’exemple suivant permet aux utilisateurs d’accéder à subnet-1 et subnet-2.

{
      "Sid": "EnforceStayInSpecificSubnets",
      "Action": [
          "lambda:CreateFunction",
          "lambda:UpdateFunctionConfiguration"
       ],
      "Effect": "Allow",
      "Resource": "*",
      "Condition": {
        "ForAllValues:StringEquals": {
            "lambda:SubnetIds": ["subnet-1", "subnet-2"]
        }
      }
    }
      

Pour permettre aux utilisateurs d’accéder à des groupes de sécurité spécifiques, utilisez StringEquals pour vérifier la valeur de la condition lambda:SecurityGroupIds. L’exemple suivant permet aux utilisateurs d’accéder à sg-1 et sg-2.

{
      "Sid": "EnforceStayInSpecificSecurityGroup",
      "Action": [
          "lambda:CreateFunction",
          "lambda:UpdateFunctionConfiguration"
       ],
      "Effect": "Allow",
      "Resource": "*",
      "Condition": {
        "ForAllValues:StringEquals": {
            "lambda:SecurityGroupIds": ["sg-1", "sg-2"]
        }
      }
    }
  ]
} 
        

Didacticiels de VPC

Dans les didacticiels suivants, vous connectez une fonction Lambda à des ressources dans votre VPC.

Pour connecter votre fonction aux ressources d'un VPC appartenant à un autre Compte AWS, consultezOctroi aux fonctions Lambda d’un accès à une ressource dans un Amazon VPC d’un autre compte.