Politiques IAM basées sur l'identité pour Lambda - AWS Lambda
Développement des fonctionsDéveloppement et utilisation des couchesRôles entre comptes Clés de condition pour les paramètres du VPC

Politiques IAM basées sur l'identité pour Lambda

Vous pouvez utiliser des stratégies basées sur une identité dans AWS Identity and Access Management (IAM) afin d'accorder aux utilisateurs de votre compte l'accès à Lambda. Les stratégies basées sur l'identité peuvent s'appliquer directement aux utilisateurs, ou aux groupes et aux rôles associés à un utilisateur. Vous pouvez également accorder aux utilisateurs d'un autre compte l'autorisation d'endosser un rôle de votre compte et d'accéder à vos ressources Lambda. Cette page montre un exemple de la façon dont les politiques basées sur l'identité peuvent être utilisées pour le développement de fonctions.

Lambda fournit des stratégies gérées par AWS qui accordent l'accès aux actions d'API Lambda et, dans certains cas, l'accès à d'autres services AWS utilisés pour développer et gérer des ressources Lambda. Lambda met à jour ces stratégies gérées si nécessaire pour s'assurer que vos utilisateurs ont accès aux nouvelles fonctionnalités quand elles sont disponibles.

  • AWSLambda_FullAccess – Accorde l'accès complet aux actions Lambda et à d'autres AWS services utilisés afin de développer et maintenir des ressources Lambda. Cette stratégie a été créée en limitant la précédente stratégie AWSlambDaFullAccess.

  • AWSLambda_ReadOnlyAccess – Accorde l'accès en lecture seule aux ressources Lambda. Cette stratégie a été créée en limitant la précédente stratégie AWSlambdaReadOnlyAccess.

  • AWSLambdaRole – Accorde les autorisations requises pour appeler les fonctions Lambda.

Les stratégies gérées par AWS accordent une autorisation sur des actions d'API, sans restreindre les fonctions Lambda ou les couches qu'un utilisateur peut modifier. Pour bénéficier d'un contrôle plus précis, vous pouvez créer vos propres stratégies qui limitent la portée des autorisations d'un utilisateur.

Développement des fonctions

Utilisez des stratégies basées sur une identité pour autoriser des utilisateurs à effectuer des opérations sur des fonctions Lambda.

Note

Pour une fonction définie comme une image de conteneur, l'autorisation utilisateur d'accéder à l'image DOIT être configurée dans le registre de conteneur Amazon Elastic. Pour un exemple, consultez Autorisations Amazon ECR.

Voici un exemple de stratégie d'autorisations avec une portée limitée. Elle permet à un utilisateur de créer et gérer des fonctions Lambda nommées avec un préfixe distinct (intern-) et configurées avec un rôle d'exécution désigné.

Exemple Stratégie de développement des fonctions
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ReadOnlyPermissions",
            "Effect": "Allow", 
            "Action": [
                "lambda:GetAccountSettings",
                "lambda:GetEventSourceMapping",
                "lambda:GetFunction",
                "lambda:GetFunctionConfiguration",           
                "lambda:GetFunctionCodeSigningConfig",
                "lambda:GetFunctionConcurrency",                
                "lambda:ListEventSourceMappings",
                "lambda:ListFunctions",      
                "lambda:ListTags",
                "iam:ListRoles"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DevelopFunctions",
            "Effect": "Allow", 
            "NotAction": [
                "lambda:AddPermission",
                "lambda:PutFunctionConcurrency"
            ],
            "Resource": "arn:aws:lambda:*:*:function:intern-*"
        },
        {
            "Sid": "DevelopEventSourceMappings",
            "Effect": "Allow", 
            "Action": [
                "lambda:DeleteEventSourceMapping",
                "lambda:UpdateEventSourceMapping",
                "lambda:CreateEventSourceMapping"
            ],
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "lambda:FunctionArn": "arn:aws:lambda:*:*:function:intern-*"
                }
            }
        },
        {
            "Sid": "PassExecutionRole",
            "Effect": "Allow", 
            "Action": [
                "iam:ListRolePolicies",
                "iam:ListAttachedRolePolicies",
                "iam:GetRole",
                "iam:GetRolePolicy",
                "iam:PassRole",
                "iam:SimulatePrincipalPolicy"
            ],
            "Resource": "arn:aws:iam::*:role/intern-lambda-execution-role"
        },
        {
            "Sid": "ViewLogs",
            "Effect": "Allow", 
            "Action": [
                "logs:*"
            ],
            "Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/intern-*"
        }
    ]
}

Les autorisations de la stratégie sont organisées en déclarations reposant sur les ressources et conditions qu'elles prennent en charge.

  • ReadOnlyPermissions – La console Lambda utilise ces autorisations lorsque vous parcourez et affichez les fonctions. Les conditions ou modèles de ressources ne sont pas pris en charge.

    
            "Action": [
                "lambda:GetAccountSettings",
                "lambda:GetEventSourceMapping",
                "lambda:GetFunction",
                "lambda:GetFunctionConfiguration",           
                "lambda:GetFunctionCodeSigningConfig",
                "lambda:GetFunctionConcurrency",                
                "lambda:ListEventSourceMappings",
                "lambda:ListFunctions",      
                "lambda:ListTags",
                "iam:ListRoles"
            ],
            "Resource": "*"

  • DevelopFunctions – Utilisez toute action Lambda qui s'exécute sur des fonctions ayant le préfixe intern-, à l'exception de AddPermission et de PutFunctionConcurrency. AddPermission modifie la stratégie basée sur une ressource de la fonction, ce qui peut avoir des conséquences en matière de sécurité. PutFunctionConcurrency réserve la capacité de mise à l'échelle pour une fonction, et peut retirer de la capacité à d'autres fonctions.

    
            "NotAction": [
                "lambda:AddPermission",
                "lambda:PutFunctionConcurrency"
            ],
            "Resource": "arn:aws:lambda:*:*:function:intern-*"

  • DevelopEventSourceMappings – Gérez les mappages de source d'événement sur les fonctions qui sont préfixées avec intern-. Ces actions s'exécutent sur des mappages de source d'événement, mais vous pouvez les restreindre par fonction à l'aide d'une condition.

    
            "Action": [
                "lambda:DeleteEventSourceMapping",
                "lambda:UpdateEventSourceMapping",
                "lambda:CreateEventSourceMapping"
            ],
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "lambda:FunctionArn": "arn:aws:lambda:*:*:function:intern-*"
                }
            }

  • PassExecutionRole – Affichez et transmettez uniquement un rôle nommé intern-lambda-execution-role, qui doit être créé et géré par un utilisateur avec des autorisations IAM. PassRole est utilisé lorsque vous attribuez un rôle d'exécution à une fonction.

    
            "Action": [
                "iam:ListRolePolicies",
                "iam:ListAttachedRolePolicies",
                "iam:GetRole",
                "iam:GetRolePolicy",
                "iam:PassRole",
                "iam:SimulatePrincipalPolicy"
            ],
            "Resource": "arn:aws:iam::*:role/intern-lambda-execution-role"

  • ViewLogs – Utilisez CloudWatch Logs pour afficher les journaux de fonctions préfixées avec intern-.

    
            "Action": [
                "logs:*"
            ],
            "Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/intern-*"

Cette stratégie permet à un utilisateur de démarrer avec Lambda, sans nuire aux ressources des autres utilisateurs. Elle ne permet pas à un utilisateur de configurer une fonction qui doit être déclenchée par d'autres services AWS ou appeler ces derniers. Pour cela, des autorisations IAM plus étendues sont nécessaires. Elle n'inclut pas non plus d'autorisation pour les services qui ne prennent pas en charge les stratégies de portée limitée, telles que CloudWatch et X-Ray. Pour ces services, utilisez les stratégies en lecture seule afin d'accorder à l'utilisateur l'accès aux métriques et aux données de suivi.

Lorsque vous configurez des déclencheurs pour votre fonction, vous devez être autorisé à utiliser le service AWS qui appelle votre fonction. Par exemple, pour configurer un déclencheur Amazon S3, vous vous devez être autorisé à utiliser les actions Amazon S3 qui gèrent les notifications de compartiment. Plusieurs de ces autorisations sont incluses dans la stratégie gérée AWSLambdaFullAccess. Vous trouverez des exemples de stratégies dans le référentiel GitHub de ce guide.

Développement et utilisation des couches

La stratégie suivante accorde à un utilisateur l'autorisation de créer des couches et de les utiliser avec des fonctions. Les modèles de ressources permettent à l'utilisateur de travailler dans n'importe quelle région AWS et avec n'importe quelle version de couche, tant que le nom de la couche commence par test-.

Exemple stratégie de développement des couches
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublishLayers",
            "Effect": "Allow",
            "Action": [
                "lambda:PublishLayerVersion"
            ],
            "Resource": "arn:aws:lambda:*:*:layer:test-*"
        },
        {
            "Sid": "ManageLayerVersions",
            "Effect": "Allow",
            "Action": [
                "lambda:GetLayerVersion",
                "lambda:DeleteLayerVersion"
            ],
            "Resource": "arn:aws:lambda:*:*:layer:test-*:*"
        }
    ]
}

Vous pouvez également appliquer l'utilisation des couches durant la création et la configuration de la fonction avec la condition lambda:Layer. Par exemple, vous pouvez empêcher les utilisateurs d'utiliser les couches publiées par d'autres comptes. La stratégie ci-dessous ajoute une condition aux actions CreateFunction et UpdateFunctionConfiguration afin d'exiger que toutes les couches spécifiées proviennent du compte 123456789012.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ConfigureFunctions",
            "Effect": "Allow",
            "Action": [
                "lambda:CreateFunction",
                "lambda:UpdateFunctionConfiguration"
            ],
            "Resource": "*",
            "Condition": {
                "ForAllValues:StringLike": {
                    "lambda:Layer": [
                        "arn:aws:lambda:*:123456789012:layer:*:*"
                    ]
                }
            }
        }
    ]
}

Pour que la condition s'applique, vérifiez qu'aucune autre déclaration n'accorde d'autorisation utilisateur à ces actions.

Rôles entre comptes

Vous pouvez appliquer n'importe laquelle des stratégies et déclarations précédentes à un rôle, que vous pouvez ensuite partager avec un autre compte pour lui donner accès à vos ressources Lambda. Contrairement à un utilisateur, un rôle ne dispose pas d'informations d'identification pour l'authentification. En revanche, il dispose d'une stratégie d'approbation qui spécifie qui peut endosser le rôle et utiliser ses autorisations.

Vous pouvez utiliser des rôles entre comptes pour donner à des comptes de confiance l'accès à des actions et ressources Lambda. Si vous souhaitez simplement accorder l'autorisation d'appeler une fonction ou d'utiliser une couche, utilisez plutôt des stratégies basées sur les ressources.

Pour de plus amples informations, veuillez consulter Rôles IAM dans le Guide de l'utilisateur IAM.

Clés de condition pour les paramètres du VPC

Vous pouvez utiliser des clés de condition pour les paramètres du VPC afin de fournir des contrôles d'autorisation supplémentaires pour vos fonctions Lambda. Par exemple, vous pouvez imposer que toutes les fonctions Lambda au sein 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 fonctions sont autorisées à utiliser ou ne peuvent pas utiliser.

Pour de plus amples informations, veuillez consulter Utilisation des clés de condition IAM pour les paramètres du VPC.