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 au sein de votre 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, de l’AWS Command Line Interface (AWS CLI) ou d’AWS SAM.

Autorisations IAM requises

Pour associer une fonction Lambda à un Amazon VPC au sein de votre Compte AWS, Lambda a besoin d’autorisations pour créer et gérer les interfaces réseau qu’il utilise pour 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 donner à votre fonction les autorisations dont elle a besoin en attachant la politique gérée par AWS 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. Votre fonction peut toujours être invoquée avec succès lorsqu’elle est attachée à un VPC Amazon, 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 :

Attachement de fonctions Lambda à un Amazon VPC dans votre Compte AWS

Associez votre fonction à un Amazon VPC dans votre Compte AWS à l’aide de la console Lambda, de l’AWS CLI ou d’AWS SAM. Si vous utilisez l’AWS CLI ou AWS SAM, ou si vous attachez 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 Activation de l’accès Internet pour les fonctions Lambda connectées à un VPC.

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 octroyer 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 octroyé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 respecter le principe de l’accès au moindre privilège, ajoutez une politique de rejet au rôle d’exécution de votre fonction, comme dans l’exemple suivant. 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, consultez 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 liste de contrôle d’accès (ACL) réseau pour renforcer la sécurité dans 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à attaché 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 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, être au fait de leur fonctionnement peut vous aider à comprendre le comportement de votre fonction lorsque vous l’attachez à 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. Cependant, chaque ENI Hyperplane prend en charge jusqu’à 65 000 connexions/ports. 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 une ENI Hyperplane, votre fonction reste à 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, aucune opération supplémentaire ciblant la fonction ne peut être effectuée, comme la création de versions ou la mise à jour du code de la fonction, mais vous pouvez continuer à invoquer les versions antérieures de la fonction.

Dans le cadre de la gestion du cycle de vie de l’ENI, Lambda peut supprimer et recréer les ENI pour équilibrer la charge du trafic réseau entre les ENI ou résoudre les problèmes détectés lors de la surveillance de l’état 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 peut prendre jusqu’à 20 minutes pour supprimer l’ENI Hyperplane associée. 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 condition spécifiques de Lambda pour les paramètres du 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 :

Les opérations d’API Lambda CreateFunction et UpdateFunctionConfiguration prennent 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 déploient uniquement les fonctions connectées au VPC

Pour vous assurer que tous les utilisateurs déploient uniquement des fonctions connectées au VPC, vous pouvez refuser les opérations de création et de mise à jour de fonctions qui n’incluent pas d’ID de 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.