Políticas de IAM basadas en identidad para Lambda

Puede utilizar las políticas basadas en identidad de AWS Identity and Access Management (IAM) para conceder a los usuarios de su cuenta acceso a Lambda. Las políticas basadas en identidad se pueden aplicar a los usuarios directamente, o a los grupos y roles que están asociados a un usuario. También puede conceder a los usuarios de otra cuenta permiso para asumir un rol de su cuenta y tener acceso a sus recursos de Lambda. Esta página muestra un ejemplo de cómo se pueden utilizar las políticas basadas en identidades para el desarrollo de funciones.

Lambda proporciona a políticas administradas AWS que otorgan acceso a las acciones de la API de Lambda y, en algunos casos, acceso a otros servicios de AWS utilizados para desarrollar y administrar los recursos de Lambda. Lambda actualiza las políticas administradas según sea necesario para garantizar que los usuarios tengan acceso a las características nuevas que se publiquen.

• AWSLambda_FullAccess: concede acceso completo a las acciones de Lambda y a otros servicios AWS que se utilizan para desarrollar y mantener los recursos de Lambda. Esta directiva se creó mediante el alcance de la política anterior AWSLambdaFullAccess.

• AWSLambda_ReadOnlyAccess: concede acceso de solo lectura a los recursos de Lambda. Esta directiva se creó mediante el alcance de la política anterior AWSLambdaReadOnlyAccess.

• AWSLambdaRole: concede permisos para invocar funciones de Lambda.

Las políticas administradas AWS conceden permiso a las acciones de la API sin restringir las funciones de Lambda ni las capas que un usuario puede modificar. Para conseguir un control más preciso, puede crear sus propias políticas que limiten el ámbito de los permisos de un usuario.

Desarrollo de funciones

Utilice políticas basadas en identidad para permitir a los usuarios realizar operaciones en las funciones de Lambda.

nota

Para una función definida como imagen de contenedor, el permiso de usuario para acceder a la imagen DEBE configurarse en el Amazon Elastic Container Registry. Para obtener un ejemplo, consulte Permisos de Amazon ECR.

A continuación, se muestra un ejemplo de una política de permisos con un ámbito limitado. Permite a un usuario crear y administrar funciones de Lambda cuyo nombre tiene un prefijo determinado (intern-) y que están configuradas con un rol de ejecución determinado.

ejemplo Política para el desarrollo de funciones

{
    "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-*"
        }
    ]
}

Los permisos de la política están organizados en instrucciones que se basan en las condiciones y los recursos a los que se aplican.

• ReadOnlyPermissions: la consola de Lambda utiliza estos permisos cuando se buscan y se visualizan las funciones. No admiten patrones de recursos ni condiciones.

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

• DevelopFunctions: usa cualquier acción de Lambda que opera sobre las funciones cuyo nombre tiene el prefijo intern-, excepto AddPermission y PutFunctionConcurrency. AddPermission modifica la política basada en recursos de la función y puede afectar a la seguridad. PutFunctionConcurrency reserva capacidad de escalado para una función y puede restar capacidad a las otras funciones.

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

• DevelopEventSourceMappings: permite administrar las asignaciones de orígenes de eventos en las funciones cuyo nombre tenga el prefijo intern-. Estas acciones operan sobre los mapeos de orígenes de eventos, pero es posible restringirlas para las distintas funciones utilizando una condición.

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

• PassExecutionRole: permite ver y pasar únicamente un rol denominado intern-lambda-execution-role, que debe crear y administrar un usuario con permisos de IAM. PassRole se utiliza cuando se asigna un rol de ejecución a una función.

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

• ViewLogs: permite utilizar CloudWatch Logs para ver los registros de las funciones cuyo nombre tiene el prefijo intern-.

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

Esta política permite a un usuario comenzar a utilizar Lambda sin poner en peligro los recursos de los demás usuarios. No permite a un usuario configurar una función que llame a o que se active por otros servicios de AWS, lo cual requiere permisos de IAM más amplios. Tampoco incluye permiso para los servicios que no admiten políticas de ámbito limitado, como CloudWatch y X-Ray. Utilice las políticas de solo lectura para estos servicios con objeto de dar a los usuarios acceso a las métricas y los datos de rastreo.

Al configurar triggers para una función, se necesita acceso para utilizar el servicio AWS que invoca la función. Por ejemplo, si desea configurar un desencadenador de Amazon S3, necesita permiso para poder utilizar las acciones de Amazon S3 que permiten administrar notificaciones de buckets. Muchos de estos permisos están incluidos en la política administrada AWSLambdaFullAccess. Existen políticas de ejemplo en el repositorio de GitHub de esta guía.

Desarrollo y uso de capas

La siguiente política concede a un usuario permiso para crear capas y usarlas con las funciones. Los patrones de recursos permiten al usuario trabajar en cualquier región AWS y con cualquier versión de capa, siempre y cuando el nombre de la capa comience con test-.

ejemplo Política de desarrollo de capas

{
    "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-*:*"
        }
    ]
}

También puede hacer obligatorio el uso de capas durante la creación y configuración de funciones con la condición lambda:Layer. Por ejemplo, puede impedir que los usuarios utilicen capas publicados por otras cuentas. La siguiente política añade una condición a las acciones CreateFunction y UpdateFunctionConfiguration para exigir que las capas especificadas procedan de la cuenta 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:*:*"
                    ]
                }
            }
        }
    ]
}

Para asegurarse de que se aplica la condición, compruebe que ninguna otra instrucción conceda al usuario permiso para estas acciones.

Roles entre cuentas

Puede aplicar cualquiera de las instrucciones y políticas anteriores a un rol que luego puede compartir con otra cuenta para que esta tenga acceso a sus recursos de Lambda. A diferencia de un usuario, un rol no tiene credenciales para la autenticación. En lugar de ello, tiene una política de confianza que especifica quién puede asumir el rol y utilizar sus permisos.

Puede utilizar roles entre cuentas para conceder acceso a las acciones y los recursos de Lambda a las cuentas en las que confía. Si solo desea conceder permiso para invocar una función o utilizar una capa, utilice las políticas basadas en recursos en su lugar.

Para obtener más información, consulte Roles de IAM en la Guía del usuario de IAM.

Claves de condición para la configuración de la VPC

Puede utilizar claves de condición para la configuración de la VPC para proporcionar controles de permisos adicionales para sus funciones de Lambda. Por ejemplo, puede exigir que todas las funciones de Lambda de la organización estén conectadas a una VPC. También puede especificar las subredes y los grupos de seguridad que las funciones pueden utilizar o a los que se les deniega el uso.

Para obtener más información, consulte Uso de claves de condición de IAM para la configuración de la VPC.