Rol de ejecución de Lambda - AWS Lambda

Rol de ejecución de Lambda

Un rol de ejecución de una función de Lambda es un rol de AWS Identity and Access Management (IAM) que concede a la función permiso para acceder a servicios y recursos de AWS. Por ejemplo, puede crear un rol de ejecución que tenga permiso para enviar registros a Amazon CloudWatch y cargar datos de seguimiento en AWS X-Ray. Esta página proporciona información sobre cómo crear, ver y administrar el rol de ejecución de una función de Lambda.

Al crear una función, brinda un rol de ejecución. Cuando invoca su función, Lambda proporciona automáticamente a su función credenciales temporales al asumir este rol. No es necesario que llame a sts:AssumeRole en el código de función.

Para que Lambda asuma correctamente su función de ejecución, la política de confianza del rol debe especificar la entidad principal de servicio de Lambda (lambda.amazonaws.com) como un servicio de confianza.

Para ver el rol de ejecución de una función
  1. Abra la página Funciones de la consola de Lambda.

  2. Elija el nombre de una función.

  3. Elija Configuration (Configuración) y, a continuación, seleccione Permissions (Permisos).

  4. En Resource summary (Resumen de recursos), consulte los servicios y recursos a los que puede acceder la función.

  5. Elija un servicio en el menú desplegable para consultar los permisos relacionados con ese servicio.

Puede añadir o eliminar permisos del rol de ejecución de una función en cualquier momento, o configurar la función para que utilice otro rol. Agregue permisos para los servicios a los que llama la función con el SDK de AWS y para los servicios que Lambda utiliza para habilitar características opcionales.

Cuando agregue permisos a la función, actualice también el código o la configuración. Esto obliga a las instancias en ejecución de su función, cuyas credenciales han expirado, a detenerse y ser sustituidas.

Creación de un rol de ejecución en la consola de IAM

De forma predeterminada, Lambda crea un rol de ejecución con permisos mínimos al crear una función en la consola de Lambda. También puede crear un rol de ejecución en la consola de IAM.

Para crear un rol de ejecución en la consola de IAM
  1. Abra la página Roles en la consola de IAM.

  2. Elija Create role.

  3. En Use case (Caso de uso), elija Lambda.

  4. Elija Next (Siguiente).

  5. Elija las políticas administradas de AWS AWSLambdaBasicExecutionRole y AWSXRayDaemonWriteAccess.

  6. Elija Next (Siguiente).

  7. Introduzca un nombre de rol en el campo Role name y, a continuación, elija Create role.

Para obtener instrucciones, consulte Creación de un rol para un servicio de AWS (consola) en la Guía del usuario de IAM.

Otorgue privilegios de acceso mínimos a su rol de ejecución de Lambda

Cuando crea por primera vez un rol de IAM para su función de Lambda durante la fase de desarrollo, a veces puede conceder permisos más allá de lo necesario. Antes de publicar la función en el entorno de producción, la práctica recomendada consiste en ajustar la política para incluir solo los permisos necesarios. Para obtener más información, consulte Aplicar permisos de privilegio mínimo en la Guía del usuario de IAM.

Utilice IAM Access Analyzer para ayudar a identificar los permisos necesarios para la política de rol de ejecución de IAM. IAM Access Analyzer revisa sus registros de AWS CloudTrail en el intervalo de fechas especificado y genera una plantilla de política con solo los permisos que la función utilizó durante ese tiempo. Puede utilizar la plantilla para crear una política administrada con permisos detallados y, a continuación, adjuntarla al rol de IAM. De esta forma, solo concede los permisos que el rol necesita para interactuar con los recursos de AWS para su caso de uso específico.

Para obtener más información, consulte Generar políticas basadas en la actividad de acceso en la Guía del usuario de IAM.

Administración de roles con la API de IAM

Para crear un rol de ejecución con AWS Command Line Interface (AWS CLI), utilice el comando create-role. Al usar este comando, puede especificar las políticas de confianza en línea. La política de confianza de un rol otorga a la entidad principal especificada permiso para asumir el rol. En el siguiente ejemplo, usted concede a la entidad principal del servicio Lambda el permiso para que asuma su rol. Tenga en cuenta que los requisitos para estar por fuera de las comillas en la cadena JSON pueden variar según su shell.

aws iam create-role --role-name lambda-ex --assume-role-policy-document '{"Version": "2012-10-17","Statement": [{ "Effect": "Allow", "Principal": {"Service": "lambda.amazonaws.com"}, "Action": "sts:AssumeRole"}]}'

También puede definir la política de confianza para el rol con un archivo JSON aparte. En el siguiente ejemplo, trust-policy.json es un archivo que se encuentra en el directorio actual.

ejemplo trust-policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
aws iam create-role --role-name lambda-ex --assume-role-policy-document file://trust-policy.json

Debería ver los siguientes datos de salida:

{ "Role": { "Path": "/", "RoleName": "lambda-ex", "RoleId": "AROAQFOXMPL6TZ6ITKWND", "Arn": "arn:aws:iam::123456789012:role/lambda-ex", "CreateDate": "2020-01-17T23:19:12Z", "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } } }
nota

Lambda asume automáticamente su rol de ejecución cuando invoca su función. Debería evitar llamar a sts:AssumeRole de forma manual en el código de función. Si su caso de uso requiere que el rol se asuma por sí mismo, debe incluir al rol como una entidad principal de confianza en la política de confianza de su rol. Para obtener más información acerca de cómo modificar una política de confianza de roles, consulte Modificación de una política de confianza de rol (consola) en la Guía del usuario de IAM.

Para agregar permisos al rol, use el comando attach-policy-to-role. Comience agregando la política administrada de AWSLambdaBasicExecutionRole.

aws iam attach-role-policy --role-name lambda-ex --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

Duración de sesión para credenciales de seguridad temporales

Lambda asume la función de ejecución asociada a la función para obtener las credenciales de seguridad temporales que estarán disponibles como variables de entorno durante la invocación de una función. Si utiliza estas credenciales temporales fuera de Lambda, por ejemplo, para crear una URL de Amazon S3 prefirmada, no podrá controlar la duración de la sesión. La configuración de duración máxima de la sesión de IAM no se aplica a las sesiones asumidas por los servicios de AWS como Lambda. Use la acción sts:AssumeRole si necesita controlar la duración de la sesión.

Políticas administradas por AWS para características de Lambda

Las siguientes políticas administradas de AWS proporcionan los permisos necesarios para utilizar las características de Lambda.

Cambio Descripción Fecha

AWSLambdaMSKExecutionRole: Lambda ha agregado el permiso kafka:DescribeClusterV2 a esta política.

AWSLambdaMSKExecutionRole concede permisos para leer y acceder a registros de un clúster de Amazon Managed Streaming for Apache Kafka (Amazon MSK), administrar interfaces de red elásticas (ENI) y escribir en CloudWatch Logs.

17 de junio de 2022

AWSLambdaBasicExecutionRole: Lambda comenzó a realizar un seguimiento de los cambios de esta política.

AWSLambdaBasicExecutionRole concede permisos para cargar registros en CloudWatch.

14 de febrero de 2022

AWSLambdaDynamoDBExecutionRole: Lambda comenzó a realizar un seguimiento de los cambios de esta política.

AWSLambdaDynamoDBExecutionRole concede permisos para leer registros de una transmisión de Amazon DynamoDB y escribir en CloudWatch Logs.

14 de febrero de 2022

AWSLambdaKinesisExecutionRole: Lambda comenzó a realizar un seguimiento de los cambios de esta política.

AWSLambdaKinesisExecutionRole concede permisos para leer registros de una transmisión de datos de Amazon Kinesis y escribir en CloudWatch Logs.

14 de febrero de 2022

AWSLambdaMSKExecutionRole: Lambda comenzó a realizar un seguimiento de los cambios de esta política.

AWSLambdaMSKExecutionRole concede permisos para leer y acceder a registros de un clúster de Amazon Managed Streaming for Apache Kafka (Amazon MSK), administrar interfaces de red elásticas (ENI) y escribir en CloudWatch Logs.

14 de febrero de 2022

AWSLambdaSQSQueueExecutionRole: Lambda comenzó a realizar un seguimiento de los cambios de esta política.

AWSLambdaSQSQueueExecutionRole concede permisos para leer un mensaje de una cola de Amazon Simple Queue Service (Amazon SQS) y escribir en CloudWatch Logs.

14 de febrero de 2022

AWSLambdaVPCAccessExecutionRole: Lambda comenzó a realizar un seguimiento de los cambios de esta política.

AWSLambdaVPCAccessExecutionRole concede permisos para administrar ENI dentro de una Amazon VPC y escribir en CloudWatch Logs.

14 de febrero de 2022

AWSXRayDaemonWriteAccess: Lambda comenzó a realizar un seguimiento de los cambios de esta política.

AWSXRayDaemonWriteAccess concede permisos para cargar datos de seguimiento en X-Ray.

14 de febrero de 2022

CloudWatchLambdaInsightsExecutionRolePolicy: Lambda comenzó a realizar un seguimiento de los cambios de esta política.

CloudWatchLambdaInsightsExecutionRolePolicy concede permiso para escribir métricas de tiempo de ejecución en CloudWatch Lambda Insights.

14 de febrero de 2022

AmazonS3ObjectLambdaExecutionRolePolicy: Lambda comenzó a realizar un seguimiento de los cambios de esta política.

AmazonS3ObjectLambdaExecutionRolePolicy concede permisos para interactuar con el objeto Lambda de Amazon Simple Storage Service (Amazon S3) y escribir en CloudWatch Logs.

14 de febrero de 2022

Para algunas características, la consola de Lambda intenta agregar permisos que faltan a su rol de ejecución en una política administrada por el cliente. Estas políticas pueden llegar a ser numerosas. Para evitar la creación de políticas adicionales, agregue las políticas administradas por AWS a su rol de ejecución antes de habilitar las características.

Cuando se utiliza un mapeo de fuente de eventos para invocar la función, Lambda utiliza el rol de ejecución para leer los datos de los eventos. Por ejemplo, un mapeo de fuente de eventos para Kinesis lee los eventos de un flujo de datos y se los envía a la función por lotes.

Cuando un servicio asume un rol en su cuenta, puede incluir las claves de contexto de condición global aws:SourceAccount y aws:SourceArn en la política de confianza de rol para limitar el acceso al rol a solo las solicitudes generadas por los recursos esperados. Para obtener más información, consulte Prevención del suplente confuso entre servicios para AWS Security Token Service.

Es posible utilizar los mapeos de orígenes de eventos con los siguientes servicios:

Además de las políticas administradas por AWS, la consola de Lambda proporciona plantillas para la creación de una política personalizada con permisos para casos de uso adicionales. Cuando crea una función en la consola de Lambda, puede elegir crear un nuevo rol de ejecución con permisos a partir de una o más plantillas. Estas plantillas también se aplican automáticamente cuando se crea una función a partir de un esquema o cuando se configuran opciones que requieren acceso a otros servicios. Existen plantillas de ejemplo en el repositorio de GitHub de esta guía.

Uso de las credenciales del entorno de ejecución de Lambda

Es común que el código de la función de Lambda realice solicitudes de API a otros servicios de AWS. Para realizar estas solicitudes, Lambda genera un conjunto efímero de credenciales al asumir el rol de ejecución de la función. Estas credenciales están disponibles como variables de entorno durante la invocación de la función. Cuando trabaja con el SDK de AWS, no es necesario proporcionar las credenciales de SDK directamente en el código. De forma predeterminada, la cadena de proveedores de credenciales comprueba secuencialmente cada lugar en el que puede configurar las credenciales y elige el primero disponible, normalmente las variables de entorno (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, y AWS_SESSION_TOKEN).

Lambda inyecta el ARN de la función de origen en el contexto de credenciales solo si la solicitud es una solicitud de la API de AWS que proviene de su entorno de ejecución. Lambda también inyecta el ARN de la función de origen para las siguientes solicitudes a la API de AWS que Lambda realiza fuera del entorno de ejecución en su nombre:

Servicio Acción Motivo
Registros de CloudWatch CreateLogGroup, CreateLogStream, PutLogEvents

Para almacenar los registros en un grupo de registro de los registros de CloudWatch

X-Ray PutTraceSegments

Para enviar datos de seguimiento a X-Ray

Amazon EFS ClientMount

Para conectar la función a un sistema de archivos Amazon Elastic File System (Amazon EFS)

Las llamadas a la API de AWS que realiza fuera del entorno de ejecución en su nombre con el mismo rol de ejecución no contienen el ARN de la función de origen. Entre los ejemplos de llamadas a la API fuera del entorno de ejecución se incluyen los siguientes:

  • Llamadas a AWS Key Management Service (AWS KMS) para cifrar y descifrar de forma automática las variables de entorno.

  • Llamadas a Amazon Elastic Compute Cloud (Amazon EC2) para crear interfaces de red elásticas (ENI) para una función con VPC habilitada.

  • Llama a servicios de AWS, como Amazon Simple Queue Service (Amazon SQS), para leer desde un origen de eventos que está configurada como una asignación de orígenes de eventos.

Con el ARN de la función de origen en el contexto de credenciales, puede verificar si una llamada al recurso proviene del código de una función de Lambda específica. Para comprobarlo, utilice la clave de condición lambda:SourceFunctionArn en una política con base en identidad de IAM o política de control de servicio (SCP).

nota

No puede utilizar la clave de condición lambda:SourceFunctionArn en las políticas basadas en recursos.

Con esta clave de condición en las políticas basadas en la identidad o SCP, puede implementar controles de seguridad para las acciones de la API que el código de la función realiza en otros servicios de AWS. Tiene algunas aplicaciones de seguridad clave, como ayudarlo a identificar el origen de una fuga de credenciales.

nota

La clave de condición lambda:SourceFunctionArn es diferente de las claves de condición lambda:FunctionArn y aws:SourceArn. La clave de condición lambda:FunctionArn solo se aplica a asignaciones de orígenes de eventos y ayuda a definir qué funciones puede invocar el origen de eventos. La clave de condición aws:SourceArn se aplica solo a las políticas en las que la función de Lambda es el recurso de destino y ayuda a definir qué otros servicios y los recursos de AWS pueden invocar esa función. La clave de condición lambda:SourceFunctionArn se puede aplicar a cualquier política basada en identidad o SCP para definir las funciones Lambda específicas que tienen permisos para hacer llamadas de la API de AWS a otros recursos.

Para utilizar lambda:SourceFunctionArn en la política, inclúyala como condición en cualquiera de los operadores de condición ARN. El valor de la clave debe ser un ARN válido.

Por ejemplo, suponga que el código de función de Lambda hace una llamada s3:PutObject que está dirigida a un bucket de Amazon S3 específico. Es posible que desee permitir que solo una función de Lambda específica tenga acceso a s3:PutObject de ese bucket. En este caso, el rol de ejecución de la función debe tener una política asociada similar a la siguiente:

ejemplo política que otorga acceso a una función de Lambda específica a un recurso de Amazon S3
{ "Version": "2012-10-17", "Statement": [ { "Sid": "ExampleSourceFunctionArn", "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::lambda_bucket/*", "Condition": { "ArnEquals": { "lambda:SourceFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:source_lambda" } } } ] }

Esta política solo permite el acceso a s3:PutObject si el origen es la función de Lambda con el ARN arn:aws:lambda:us-east-1:123456789012:function:source_lambda. Esta política no permite el acceso a s3:PutObject de ninguna otra identidad de llamada. Esto se aplica incluso aunque una función o entidad diferente haga una llamada s3:PutObject con el mismo rol de ejecución.

nota

La clave de condición lambda:SourceFunctionARN no admite versiones de funciones de Lambda ni alias de funciones. Si usa el ARN para una versión o alias de función en particular, la función no tendrá permiso para realizar la acción que especifique. Asegúrese de utilizar el ARN incompleto para la función sin un sufijo de versión o alias.

También puede usar lambda:SourceFunctionArn en políticas de control de servicios. Por ejemplo, suponga que desea restringir el acceso al bucket a un solo código de la función de Lambda o a llamadas de una instancia específica de Amazon Virtual Private Cloud (VPC). La siguiente SCP ilustra este caso.

ejemplo política que deniega el acceso a Amazon S3 en condiciones específicas
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "s3:*" ], "Resource": "arn:aws:s3:::lambda_bucket/*", "Effect": "Deny", "Condition": { "StringNotEqualsIfExists": { "aws:SourceVpc": [ "vpc-12345678" ] }, "ArnNotEqualsIfExists": { "lambda:SourceFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:source_lambda" } } } ] }

Esta política deniega todas las acciones de S3 a menos que provengan de una función de Lambda específica con el ARN arn:aws:lambda:*:123456789012:function:source_lambda o de la VPC especificada. El operador StringNotEqualsIfExists indica a IAM que procese esta condición solo si la clave aws:SourceVpc está presente en la solicitud. Del mismo modo, IAM considera el operador ArnNotEqualsIfExists solo si lambda:SourceFunctionArn está presente.