# Administrar permisos en AWS Lambda
Puede utilizar AWS Identity and Access Management (IAM) para administrar permisos en AWS Lambda. Hay dos categorías principales de permisos que debe tener en cuenta al trabajar con funciones de Lambda:
+ Permisos que las funciones de Lambda necesitan para realizar las acciones de la API y acceder a otros recursos de AWS.
+ Permisos que otros usuarios y entidades de AWS necesitan para acceder a las funciones de Lambda
Las funciones de Lambda a menudo necesitan acceder a otros recursos de AWS y realizar diversas operaciones de la API en esos recursos. Por ejemplo, puede tener una función de Lambda que responda a un evento actualizando las entradas de una base de datos de Amazon DynamoDB. En este caso, la función necesita permisos para acceder a la base de datos, así como permisos para colocar o actualizar elementos en esa base de datos.
Usted define los permisos que necesita la función de Lambda se definen en un rol de IAM especial llamado [rol de ejecución](lambda-intro-execution-role.md). En este rol, puede adjuntar una política que defina los permisos que la función necesita para acceder a otros recursos de AWS y leer desde orígenes de eventos. Cada función de Lambda debe tener un rol de ejecución. Como mínimo, su rol de ejecución debe tener acceso a Amazon CloudWatch, ya que las funciones de Lambda se registran en Registros de CloudWatch de forma predeterminada. Puede adjuntar la [política administrada `AWSLambdaBasicExecutionRole`](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html) a su rol de ejecución para cumplir con este requisito.
Para conceder permisos para que otras Cuentas de AWS, organizaciones y servicios accedan a sus recursos de Lambda, tiene varias opciones:
+ Puede utilizar [políticas basadas en identidades](access-control-identity-based.md) para conceder acceso a otros usuarios a sus recursos de 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.
+ Puede usar las [políticas basadas en recursos](access-control-resource-based.md) para darles permiso a otras cuentas y Servicios de AWS para acceder a los recursos de Lambda. Cuando un usuario intenta acceder a un recurso de Lambda, este servicio tiene en cuenta tanto las políticas basadas en identidades como la política basada en recursos del recurso. Cuando un servicio de AWS, como Amazon Simple Storage Service (Amazon S3), llama a la función de Lambda, el servicio considera solo la política basada en recursos.
+ Puede utilizar un modelo de [control de acceso basado en atributos (ABAC)](attribute-based-access-control.md) para controlar el acceso a las funciones de Lambda. Con ABAC, puede adjuntar etiquetas a una función de Lambda, pasarlas en determinadas solicitudes de la API o adjuntarlas a la entidad principal de IAM que realiza la solicitud. Especifique las mismas etiquetas en el elemento de condición de una política de IAM para controlar el acceso a la función.
EnAWS, se recomienda conceder solo los permisos necesarios para realizar una tarea (permisos de [privilegios mínimos](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)). Para implementar esto en Lambda, recomendamos comenzar con una política [administrada de AWS](permissions-managed-policies.md). Puede utilizar estas políticas administradas tal como están, o como punto de partida para escribir sus propias políticas más restrictivas.
Para ayudarlo a ajustar sus permisos para el acceso con privilegios mínimos, Lambda proporciona algunas condiciones adicionales que puede incluir en sus políticas. Para obtener más información, consulte [Afinar las secciones de recursos y condiciones de las políticas](lambda-api-permissions-ref.md).
Para obtener más información acerca de IAM, consulte la *[Guía del usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)*.
# Definición de permisos de funciones de Lambda con un rol de ejecución
Un rol de ejecución de una función de Lambda es un rol de (IAM) AWS Identity and Access Management que concede a la función permiso para acceder a los Servicios de AWS y los recursos. 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.
Lambda asume automáticamente su rol de ejecución cuando invoca su función. Debería evitar llamar de forma manual a `sts:AssumeRole` para que asuma el rol de ejecución 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)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-managingrole_edit-trust-policy) en la Guía del usuario de IAM.
Para que Lambda asuma correctamente su rol de ejecución, la [política de confianza](#permissions-executionrole-api) del rol debe especificar la entidad principal de servicio de Lambda (`lambda.amazonaws.com`) como un servicio de confianza.
**Topics**
+ [Creación de un rol de ejecución en la consola de IAM](#permissions-executionrole-console)
+ [Creación y administración de roles con la AWS CLI](#permissions-executionrole-api)
+ [Otorgue privilegios de acceso mínimos a su rol de ejecución de Lambda](#permissions-executionrole-least-privilege)
+ [Visualización y actualización de permisos en el rol de ejecución](permissions-executionrole-update.md)
+ [Trabajo con políticas administradas de AWS en el rol de ejecución](permissions-managed-policies.md)
+ [Uso del ARN de la función de origen para controlar el comportamiento de acceso a la función](permissions-source-function-arn.md)
## 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](getting-started.md#getting-started-create-function). En concreto, este rol de ejecución incluye la [política administrada `AWSLambdaBasicExecutionRole`](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html), que otorga a su función permisos básicos para registrar eventos de registro en Registros de Amazon CloudWatch. Puede seleccionar **Crear rol predeterminado** en la sección **Permisos**.
Puede elegir un rol existente seleccionando **Usar otro rol** en la sección **Permisos**. Si su función de Lambda necesita permisos adicionales para realizar tareas como actualizar entradas en una base de datos Amazon DynamoDB en respuesta a eventos, puede crear un rol de ejecución personalizado con los permisos necesarios. Para hacerlo, seleccione **Usar otro rol** en la sección **Permisos** y se abrirá un panel donde puede personalizar los permisos.
**Para configurar un rol de ejecución desde la consola**
1. Introduzca un **nombre de rol** en la sección Detalles del rol.
1. En la sección **Política**, seleccione **Usar política existente**.
1. Seleccione las políticas administradas de AWS que desee adjuntar a su rol. Por ejemplo, si la función necesita acceder a DynamoDB, seleccione la política administrada **AWSLambdaDynamoDBExecutionRole**.
1. Elija **Crear rol**.
Como alternativa, cuando [crea una función en la consola de Lambda](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function), puede adjuntar a la función cualquier rol de ejecución que haya creado previamente. Si desea adjuntar un nuevo rol de ejecución a una función existente, siga los pasos que se indican en [Actualizar el rol de ejecución de una función](permissions-executionrole-update.md).
## Creación y administración de roles con la AWS CLI
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.
**Example 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
```
Para agregar permisos al rol, use el comando **attach-policy-to-role**. Los comandos siguientes agregan la política administrada `AWSLambdaBasicExecutionRole` al rol de ejecución `lambda-ex`.
```
aws iam attach-role-policy --role-name lambda-ex --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
Después de crear su rol de ejecución, adjúntelo a su función. Cuando [crea una función en la consola de Lambda](getting-started.md#getting-started-create-function), puede adjuntar a la función cualquier rol de ejecución que haya creado previamente. Si desea adjuntar un nuevo rol de ejecución a una función existente, siga los pasos que se indican en [Actualizar el rol de ejecución de una función](permissions-executionrole-update.md#update-execution-role).
## 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_generate-policy.html) en la *Guía del usuario de IAM*.
# Visualización y actualización de permisos en el rol de ejecución
En este tema se explica cómo ver y actualizar el [rol de ejecución de la función](lambda-intro-execution-role.md).
**Topics**
+ [Ver el rol de ejecución de una función](#view-execution-role)
+ [Actualizar el rol de ejecución de una función](#update-execution-role)
## Ver el rol de ejecución de una función
Para ver el rol de ejecución de una función, utilice la consola de Lambda.
**Cómo ver el rol de ejecución de una función (consola)**
1. Abra la página de [Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Elija el nombre de una función.
1. Elija **Configuration** (Configuración) y, a continuación, seleccione **Permissions** (Permisos).
1. En **Rol de ejecución**, puede ver el rol que se utiliza actualmente como rol de ejecución de la función. Para mayor comodidad, puede ver todos los recursos y acciones a los que puede acceder la función en la sección de **resumen de recursos**. También puede elegir un servicio de la lista del menú desplegable para consultar los permisos relacionados con ese servicio.
## Actualizar el rol de ejecución de una función
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. Si su función necesita acceder a otros servicios o recursos, debe agregar los permisos necesarios al rol de ejecución.
Cuando agregue permisos a su función, actualice también su código o configuración. Esto obliga a las instancias en ejecución de su función, cuyas credenciales han expirado, a detenerse y ser sustituidas.
Para actualizar el rol de ejecución de una función, puede utilizar la consola de Lambda.
**Para configurar el rol de ejecución de la función (consola)**
1. Abra la página de [Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Elija el nombre de una función.
1. Elija **Configuration** (Configuración) y, a continuación, seleccione **Permissions** (Permisos).
1. En **Rol de ejecución**, elija **Editar**.
1. Si desea actualizar su función para usar un rol diferente como rol de ejecución, elija el nuevo rol en el menú desplegable bajo el rol **existente**.
**nota**
Si desea actualizar los permisos de un rol de ejecución existente, solo puede hacerlo en la consola de AWS Identity and Access Management (IAM).
Si desea crear un nuevo rol para usarlo como rol de ejecución, elija **Crear un nuevo rol a partir de plantillas de AWS políticas** en el **rol de ejecución**. A continuación, introduzca un nombre para el rol nuevo en **Nombre del rol** y especifique las políticas que desee adjuntar al rol nuevo en **Plantillas de políticas**.
1. Seleccione **Guardar**.
# Trabajo con políticas administradas de AWS en el rol de ejecución
Las siguientes políticas administradas de AWS proporcionan los permisos necesarios para utilizar las características de Lambda.
| Cambio | Descripción | Fecha |
| --- | --- | --- |
| **[AWSLambdaMSKExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaMSKExecutionRole)**: Lambda ha agregado el permiso [kafka:DescribeClusterV2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters-clusterarn.html#v2-clusters-clusterarnget) 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](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/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](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/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](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/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](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/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](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/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](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/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](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/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](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/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](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/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](invocation-eventsourcemapping.md) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html#cross-service-confused-deputy-prevention).
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](https://github.com/awsdocs/aws-lambda-developer-guide/tree/master/iam-policies) de esta guía.
# Uso del ARN de la función de origen para controlar el comportamiento de acceso a la función
Es común que el código de la función de Lambda realice solicitudes de la 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 AWS SDK, 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 | Action | 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 los 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](invocation-eventsourcemapping.md).
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)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).
**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](invocation-eventsourcemapping.md) 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 de AWS y recursos 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_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:
**Example 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 se puede usar `lambda:SourceFunctionArn` en SCP. 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.
**Example 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"
]
}
}
},
{
"Action": [
"s3:*"
],
"Resource": "arn:aws:s3:::lambda_bucket/*",
"Effect": "Deny",
"Condition": {
"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.
# Otorgar acceso a otras entidades de AWS a sus funciones de Lambda
Para conceder permisos para que otras Cuentas de AWS, organizaciones y servicios accedan a sus recursos de Lambda, tiene varias opciones:
+ Puede utilizar [políticas basadas en identidades](access-control-identity-based.md) para conceder acceso a otros usuarios a sus recursos de 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.
+ Puede usar las [políticas basadas en recursos](access-control-resource-based.md) para darles permiso a otras cuentas y Servicios de AWS para acceder a los recursos de Lambda. Cuando un usuario intenta acceder a un recurso de Lambda, este servicio tiene en cuenta tanto las políticas basadas en identidades como la política basada en recursos del recurso. Cuando un servicio de AWS, como Amazon Simple Storage Service (Amazon S3), llama a la función de Lambda, el servicio considera solo la política basada en recursos.
+ Puede utilizar un modelo de [control de acceso basado en atributos (ABAC)](attribute-based-access-control.md) para controlar el acceso a las funciones de Lambda. Con ABAC, puede adjuntar etiquetas a una función de Lambda, pasarlas en determinadas solicitudes de la API o adjuntarlas a la entidad principal de IAM que realiza la solicitud. Especifique las mismas etiquetas en el elemento de condición de una política de IAM para controlar el acceso a la función.
Para ayudarlo a ajustar sus permisos para el acceso con privilegios mínimos, Lambda proporciona algunas condiciones adicionales que puede incluir en sus políticas. Para obtener más información, consulte [Afinar las secciones de recursos y condiciones de las políticas](lambda-api-permissions-ref.md).
# 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 usuarios, grupos de usuarios o roles. 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.
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\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html): concede acceso completo a las acciones de Lambda y a otros servicios AWS que se utilizan para desarrollar y mantener los recursos de Lambda.
+ [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html): concede acceso de solo lectura a los recursos de Lambda.
+ [AWSLambdaRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html): concede permisos para invocar funciones de Lambda.
AWSLas políticas administradas 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.
**Topics**
+ [Concesión de acceso a una función de Lambda a los usuarios](permissions-user-function.md)
+ [Conceder a los usuarios acceso a una capa de Lambda](permissions-user-layer.md)
# Concesión de acceso a una función de Lambda a los usuarios
Utilice [políticas basadas en identidad](access-control-identity-based.md) para permitir a los usuarios, los grupos de usuarios o los roles 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 Amazon Elastic Container Registry (Amazon ECR). Para ver un ejemplo, consulte [Políticas de repositorios de Amazon ECR](images-create.md#configuration-images-permissions).
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.
**Example 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": {
"ArnLike": {
"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](lambda-api-permissions-ref.md) 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](access-control-resource-based.md) de la función y puede afectar a la seguridad. `PutFunctionConcurrency` reserva capacidad de escalado para una función y puede quitar 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 se incluyen en la política administrada [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html).
# Conceder a los usuarios acceso a una capa de Lambda
Utilice [políticas basadas en identidad](access-control-identity-based.md) para permitir a los usuarios realizar operaciones en las funciones de Lambda. 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 de AWS y con cualquier versión de capa, siempre y cuando el nombre de la capa comience con `test-`.
**Example 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`.
------
#### [ JSON ]
****
```
{
"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.
# Ver políticas de IAM basadas en recursos en Lambda
Lambda admite políticas de permisos basadas en recursos para las funciones y capas de Lambda. Puede usar políticas basadas en recursos para conceder acceso a otras [cuentas de AWS](permissions-function-cross-account.md), [organizaciones](permissions-function-organization.md) o [servicios.](permissions-function-services.md) Las políticas basadas en recursos se aplican a una sola función, versión, alias o versión de capa.
------
#### [ Console ]
**Visualización de la política basada en recursos de una función**
1. Abra la [página de Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Elija una función.
1. Elija **Configuración** y, a continuación, seleccione **Permisos**.
1. Desplácese hacia abajo hasta **Directiva basada en recursos** y, a continuación, elija **Ver documento de directiva**. La política basada en recursos muestra los permisos que se aplican cuando otra cuenta o servicio de AWS intenta acceder a la función. En el ejemplo siguiente se muestra una instrucción que permite a Amazon S3 invocar una función denominada `my-function` para un bucket denominado `amzn-s3-demo-bucket` en la cuenta `123456789012`.
**Example política basada en recursos**
****
```
{
"Version":"2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "lambda-allow-s3-my-function",
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:123456789012:function:my-function",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "123456789012"
},
"ArnLike": {
"AWS:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket"
}
}
}
]
}
```
------
#### [ AWS CLI ]
Para ver la política basada en recursos de una función, utilice el comando `get-policy`.
```
aws lambda get-policy \
--function-name my-function \
--output text
```
Debería ver los siguientes datos de salida:
****
```
{"Version":"2012-10-17", "Id":"default","Statement":[{"Sid":"sns","Effect":"Allow","Principal":{"Service":"s3.amazonaws.com"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-2:123456789012:function:my-function","Condition":{"ArnLike":{"AWS:SourceArn":"arn:aws:sns:us-east-2:123456789012:lambda*"}}}]}
```
Para las versiones y los alias, añada el número de versión o el alias al nombre de la función.
```
aws lambda get-policy --function-name my-function:PROD
```
Para eliminar permisos de una función, utilice `remove-permission`.
```
aws lambda remove-permission \
--function-name example \
--statement-id sns
```
Utilice el comando `get-layer-version-policy` para ver los permisos de una capa.
```
aws lambda get-layer-version-policy \
--layer-name my-layer \
--version-number 3 \
--output text
```
Debería ver los siguientes datos de salida:
```
b0cd9796-d4eb-4564-939f-de7fe0b42236 {"Sid":"engineering-org","Effect":"Allow","Principal":"*","Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-west-2:123456789012:layer:my-layer:3","Condition":{"StringEquals":{"aws:PrincipalOrgID":"o-t194hfs8cz"}}}"
```
Se utiliza `remove-layer-version-permission` para quitar instrucciones de la política.
```
aws lambda remove-layer-version-permission --layer-name my-layer --version-number 3 --statement-id engineering-org
```
------
## Acciones de la API admitidas
Las siguientes acciones de la API de Lambda admiten las políticas basadas en recursos:
+ [CreateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_CreateAlias.html)
+ [DeleteAlias](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteAlias.html)
+ [DeleteFunction](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html)
+ [DeleteFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionConcurrency.html)
+ [DeleteFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionEventInvokeConfig.html)
+ [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html)
+ [GetAlias](https://docs.aws.amazon.com/lambda/latest/api/API_GetAlias.html)
+ [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html)
+ [GetFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConcurrency.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [GetFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionEventInvokeConfig.html)
+ [GetPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetPolicy.html)
+ [GetProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetProvisionedConcurrencyConfig.html)
+ [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html)
+ [InvokeFunctionUrl](urls-auth.md) (solo con permiso)
+ [ListAliases](https://docs.aws.amazon.com/lambda/latest/api/API_ListAliases.html)
+ [ListFunctionEventInvokeConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctionEventInvokeConfigs.html)
+ [ListProvisionedConcurrencyConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListProvisionedConcurrencyConfigs.html)
+ [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html)
+ [ListVersionsByFunction](https://docs.aws.amazon.com/lambda/latest/api/API_ListVersionsByFunction.html)
+ [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html)
+ [PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)
+ [PutFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionEventInvokeConfig.html)
+ [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html)
+ [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html)
+ [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html)
+ [UpdateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateAlias.html)
+ [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)
+ [UpdateFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionEventInvokeConfig.html)
# Concesión de acceso a la función de Lambda a Servicios de AWS
Cuando se [utiliza un servicio de AWS para invocar una función](lambda-services.md), se debe conceder permiso en una instrucción de una política basada en recursos. Puede aplicar la instrucción a toda la función, o bien, puede limitar la instrucción a una sola versión o alias.
**nota**
Cuando se añade un desencadenador a la función con la consola de Lambda, esta actualiza la política basada en recursos de la función para permitir al servicio que la invoque. Para conceder permisos a otras cuentas o servicios que no están disponibles en la consola de Lambda, puede utilizar la AWS CLI.
Agregue una instrucción con el comando [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html). La instrucción más sencilla de una política basada en recursos permite un servicio invocar una función. El siguiente comando concede a Amazon Simple Notification Service permiso para invocar una función denominada `my-function`.
```
aws lambda add-permission \
--function-name my-function \
--action lambda:InvokeFunction \
--statement-id sns \
--principal sns.amazonaws.com \
--output text
```
Debería ver los siguientes datos de salida:
```
{"Sid":"sns","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-2:123456789012:function:my-function"}
```
De este modo, Amazon SNS podrá llamar la acción [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) de la API para la función, pero no se restringirá el tema de Amazon SNS que activa la invocación. Para asegurarse de que la función solo la invocada un recurso determinado, especifique el nombre de recurso de Amazon (ARN) del recurso con la opción `source-arn`. El siguiente comando solo permite a Amazon SNS invocar la función para las suscripciones a un tema denominado `my-topic`.
```
aws lambda add-permission \
--function-name my-function \
--action lambda:InvokeFunction \
--statement-id sns-my-topic \
--principal sns.amazonaws.com \
--source-arn arn:aws:sns:us-east-2:123456789012:my-topic
```
Algunos servicios pueden invocar funciones de otras cuentas. Esto no es un problema cuando se especifica un ARN de origen que incluye el ID de la cuenta. Sin embargo, para Amazon S3, la fuente es un bucket cuyo ARN no incluye el ID de la cuenta. Es posible que usted elimine el bucket y que otra cuenta cree un bucket con el mismo nombre. Utilice la opción `source-account` con el ID de la cuenta para garantizar que solo los recursos de la cuenta pueden invocar la función.
```
aws lambda add-permission \
--function-name my-function \
--action lambda:InvokeFunction \
--statement-id s3-account \
--principal s3.amazonaws.com \
--source-arn arn:aws:s3:::amzn-s3-demo-bucket \
--source-account 123456789012
```
# Concesión de acceso a las funciones a una organización
Para conceder permisos a una organización definida en [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html), especifique el ID de la organización como el `principal-org-id`. El siguiente comando [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) concede acceso de invocación a todos los usuarios de la organización `o-a1b2c3d4e5f`.
```
aws lambda add-permission \
--function-name example \
--statement-id PrincipalOrgIDExample \
--action lambda:InvokeFunction \
--principal * \
--principal-org-id o-a1b2c3d4e5f
```
**nota**
En este comando, `Principal` es `*`. Esto significa que todos los usuarios de la organización `o-a1b2c3d4e5f`obtener permisos de invocación de funciones. Si especifica una Cuenta de AWS o un rol como `Principal`, entonces solo esa entidad principal obtiene permisos de invocación de funciones, pero solo si también forman parte de la organización `o-a1b2c3d4e5f`.
Este comando crea una política basada en recursos que tiene el siguiente aspecto:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PrincipalOrgIDExample",
"Effect": "Allow",
"Principal": "*",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:123456789012:function:example",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "o-a1b2c3d4e5f"
}
}
}
]
}
```
------
Para obtener más información, consulte [aws:PrincipalOrgID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) en la *Guía del usuario de IAM*.
# Concesión de acceso a las funciones de Lambda a otras cuentas
Para compartir una función con otra Cuenta de AWS, agregue una declaración de permisos entre cuentas a la [política basada en los recursos](access-control-resource-based.md) de la función. Ejecute el comando [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) y especifique el ID de la cuenta como `principal`. En el siguiente ejemplo, se concede permiso a la cuenta `111122223333` para invocar `my-function` con el alias `prod`.
```
aws lambda add-permission \
--function-name my-function:prod \
--statement-id xaccount \
--action lambda:InvokeFunction \
--principal 111122223333 \
--output text
```
Debería ver los siguientes datos de salida:
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-1:123456789012:function:my-function"}
```
La política basada en recursos concede permiso a la otra cuenta para obtener acceso a la función, pero no permite a los usuarios de esa cuenta superar sus permisos. Los usuarios de la otra cuenta deben tener los [permisos de usuario](access-control-identity-based.md) correspondientes para utilizar la API de Lambda.
Para limitar el acceso a un usuario o función de otra cuenta, especifique el ARN completo de la identidad como el principal. Por ejemplo, `arn:aws:iam::123456789012:user/developer`.
El [alias](configuration-aliases.md) limita la versión que puede invocar la otra cuenta. Requiere que la otra cuenta incluya el alias en el ARN de la función.
```
aws lambda invoke \
--function-name arn:aws:lambda:us-east-2:123456789012:function:my-function:prod out
```
Debería ver los siguientes datos de salida:
```
{
"StatusCode": 200,
"ExecutedVersion": "1"
}
```
El propietario de la función puede actualizar el alias para que apunte a una nueva versión sin que el autor de la llamada tenga que cambiar la forma en que invoca la función. De este modo, no es necesario que la otra cuenta cambie su código para utilizar la nueva versión y se garantiza que solo tiene permiso para invocar la versión de la función asociada al alias.
Puede conceder acceso entre cuentas para la mayoría de acciones de la API que operen con una función existente. Por ejemplo, puede conceder acceso a `lambda:ListAliases` para permitir que una cuenta obtenga una lista de alias o a `lambda:GetFunction` para permitirles que descarguen el código de la función. Añada cada permiso por separado o utilice `lambda:*` para conceder acceso a todas las acciones para la función especificada.
Si desea conceder a otras cuentas permiso sobre varias funciones o sobre acciones que no pueden utilizarse con una función, le recomendamos que utilice los [roles de IAM](access-control-identity-based.md).
# Concesión de acceso a las capas de Lambda a otras cuentas
Para compartir una capa con otra Cuenta de AWS, agregue una instrucción de permisos para varias cuentas a la [política basada en los recursos](access-control-resource-based.md) de la capa. Ejecute el comando [add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html) y especifique el ID de la cuenta como `principal`. En cada instrucción, puede conceder permiso a una única cuenta, a todas las cuentas o a una organización en [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html).
El siguiente ejemplo concede a la cuenta 111122223333 acceso a la versión 2 de la capa `bash-runtime`.
```
aws lambda add-layer-version-permission \
--layer-name bash-runtime \
--version-number 2 \
--statement-id xaccount \
--action lambda:GetLayerVersion \
--principal 111122223333 \
--output text
```
Debería ver una salida similar a esta:
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"}
```
Los permisos solo se aplican a una única versión de una capa. Repita el proceso cada vez que cree una nueva versión de la capa.
Para conceder permiso a todas las cuentas en una organización de [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html), utilice la opción `organization-id`. En el siguiente ejemplo, se concede a todas las cuentas de una organización `o-t194hfs8cz` permiso para utilizar la versión 3 de `my-layer`.
```
aws lambda add-layer-version-permission \
--layer-name my-layer \
--version-number 3 \
--statement-id engineering-org \
--principal '*' \
--action lambda:GetLayerVersion \
--organization-id o-t194hfs8cz \
--output text
```
Debería ver los siguientes datos de salida:
```
{"Sid":"engineering-org","Effect":"Allow","Principal":"*","Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-2:123456789012:layer:my-layer:3","Condition":{"StringEquals":{"aws:PrincipalOrgID":"o-t194hfs8cz"}}}"
```
Para conceder permisos a diferentes cuentas u organizaciones, tendrá que agregar varias instrucciones.
# Control de acceso basado en atributos para Lambda
Con el [control de acceso basado en atributos (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html), puede utilizar etiquetas para controlar el acceso a los recursos de Lambda. Puede adjuntar etiquetas a determinados recursos de Lambda, adjuntarlas a determinadas solicitudes de API o adjuntarlas a la entidad principal de AWS Identity and Access Management (IAM) que lleva a cabo la solicitud. Para obtener más información sobre cómo AWS concede el acceso basado en atributos, consulte [Controlar el acceso a los recursos de AWS mediante etiquetas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) en la *Guía del usuario de IAM*.
Puede usar ABAC para [conceder el privilegio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) sin especificar un nombre de recurso de Amazon (ARN) o un patrón de ARN en la política de IAM. En su lugar, puede especificar una etiqueta en el [elemento de condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) de una política de IAM para controlar el acceso. El escalado es más fácil con ABAC porque no tiene que actualizar las políticas de IAM cuando crea nuevos recursos. En cambio, agregue etiquetas a los nuevos recursos para controlar el acceso.
En Lambda, las etiquetas funcionan con los siguientes recursos:
+ Funciones: para obtener más información sobre el etiquetado de funciones, consulte [Uso de etiquetas en funciones de Lambda](configuration-tags.md).
+ Configuraciones de firma de código: para obtener más información sobre el etiquetado de configuraciones de firma de código, consulte [Uso de etiquetas en configuraciones de firma de código](tags-csc.md).
+ Asignaciones de orígenes de eventos: para obtener más información sobre el etiquetado de las asignaciones de orígenes de eventos, consulte [Uso de etiquetas en asignaciones de orígenes de eventos](tags-esm.md).
Las etiquetas no son compatibles con capas.
Puede utilizar las siguientes claves de condición para escribir reglas de política de IAM basadas en etiquetas:
+ [aws:ResourceTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag): controle el acceso en función de las etiquetas que se adjuntan a un recurso de Lambda.
+ [aws:RequestTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag): solicite que las etiquetas estén presentes en una solicitud, por ejemplo, al crear una nueva función.
+ [aws:PrincipalTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag): controle lo que la entidad principal de IAM (la persona que hace la solicitud) está autorizada a hacer en función de las etiquetas que se adjuntan a su [usuario](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags_users.html) o [rol](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags_roles.html) de IAM.
+ [aws:TagKeys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tagkeys): controle si se pueden utilizar claves de etiquetas específicas en una solicitud.
Solo puede especificar las condiciones para las acciones que las respalden. Para obtener una lista de condiciones que admite cada acción de Lambda, consulte [Acciones, recursos y claves de condición para AWS Lambda](https://docs.aws.amazon.com//service-authorization/latest/reference/list_awslambda.html) en la Referencia de autorizaciones de servicio. Para obtener información sobre la compatibilidad con **aws:ResourceTag/tag-key**, consulte “Tipos de recursos definidos por AWS Lambda”. Para obtener información sobre la compatibilidad con **aws:RequestTag/tag-key** y **aws:TagKeys**, consulte la sección “Acciones definidas por AWS Lambda”.
**Topics**
+ [Protección de las funciones por etiqueta](attribute-based-access-control-example.md)
# Protección de las funciones por etiqueta
Los siguientes pasos muestran una forma de configurar permisos para funciones mediante ABAC. En este escenario de ejemplo, creará cuatro políticas de permisos de IAM. A continuación, adjuntará estas políticas a un nuevo rol de IAM. Por último, creará un usuario de IAM y le concederá permiso para que asuma el nuevo rol.
**Topics**
+ [Requisitos previos](#abac-prerequisites)
+ [Paso 1: solicitar etiquetas en las nuevas funciones](#require-tag-on-create)
+ [Paso 2: permitir acciones basadas en etiquetas adjuntas a una función de Lambda y a una entidad principal de IAM](#restrict-actions-function-tags)
+ [Paso 3: conceder permisos de lista](#abac-list-permissions)
+ [Paso 4: conceder permisos de IAM](#abac-iam-permissions)
+ [Paso 5: crear el rol de IAM](#abac-create-role)
+ [Paso 6: crear el usuario de IAM](#abac-create-user)
+ [Paso 7: probar los permisos](#abac-test)
+ [Paso 8: Eliminar los recursos](#abac-clean-up)
## Requisitos previos
Asegúrese de que tiene un [rol de ejecución de Lambda](lambda-intro-execution-role.md). Utilizará este rol al conceder permisos de IAM y al crear una función de Lambda.
## Paso 1: solicitar etiquetas en las nuevas funciones
Cuando se usa ABAC con Lambda, es una práctica recomendada solicitar que todas las funciones tengan etiquetas. Esto ayuda a garantizar que las políticas de permisos de ABAC funcionen según lo esperado.
[Cree una política de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor) similar al siguiente ejemplo: Esta política utiliza las claves de condición [aws:RequestTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag), [aws:ResourceTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) y [aws:TagKeys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tagkeys) para exigir que las funciones nuevas y la entidad principal de IAM que crea las funciones tengan la etiqueta `project`. El modificador `ForAllValues` garantiza que `project` sea la única etiqueta permitida. Si no incluye el modificador `ForAllValues`, los usuarios pueden agregar otras etiquetas a la función siempre que también pasen `project`.
**Example — Solicitar etiquetas en las nuevas funciones**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"lambda:CreateFunction",
"lambda:TagResource"
],
"Resource": "arn:aws:lambda:*:*:function:*",
"Condition": {
"StringEquals": {
"aws:RequestTag/project": "${aws:PrincipalTag/project}",
"aws:ResourceTag/project": "${aws:PrincipalTag/project}"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": "project"
}
}
}
}
```
## Paso 2: permitir acciones basadas en etiquetas adjuntas a una función de Lambda y a una entidad principal de IAM
Describa cómo crear una segunda política de IAM mediante la clave de condición [aws:ResourceTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) para solicitar que la etiqueta de la entidad principal coincida con la etiqueta adjunta a la función. El siguiente ejemplo de política permite a las entidades principales con la etiqueta `project` invocar funciones con la etiqueta `project`. Si una función tiene otras etiquetas, se deniega la acción.
**Example — Solicitar etiquetas coincidentes en la función y la entidad principal de IAM**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction",
"lambda:GetFunction"
],
"Resource": "arn:aws:lambda:*:*:function:*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/project": "${aws:PrincipalTag/project}"
}
}
}
]
}
```
## Paso 3: conceder permisos de lista
Cree una política que permita a la entidad principal enumerar las funciones de Lambda y los roles de IAM. Esto permite a la entidad principal ver todas las funciones de Lambda y los roles de IAM en la consola y cuando llama a las acciones de la API.
**Example — Conceder permisos de lista de Lambda e IAM**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllResourcesLambdaNoTags",
"Effect": "Allow",
"Action": [
"lambda:GetAccountSettings",
"lambda:ListFunctions",
"iam:ListRoles"
],
"Resource": "*"
}
]
}
```
## Paso 4: conceder permisos de IAM
Cree una política que permita **iam:PassRole**. Este permiso es necesario al asignar un rol de ejecución a una función. En la siguiente política de ejemplo, reemplace el ARN de ejemplo por el ARN del rol de ejecución de Lambda.
**nota**
No utilice la clave de condición de `ResourceTag` en una política con la acción `iam:PassRole`. No puede utilizar la etiqueta en un rol de IAM para controlar el acceso a quién puede pasar ese rol. Para obtener más información sobre los permisos necesarios a fin de pasar un rol a un servicio, consulte [Concesión de permisos a un usuario para pasar un rol a un servicio de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html).
**Example — Conceder permiso para pasar el rol de ejecución**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/lambda-ex"
}
]
}
```
## Paso 5: crear el rol de IAM
Es una práctica recomendada [utilizar roles para delegar permisos](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#delegate-using-roles). [Cree un rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html#roles-creatingrole-user-console) denominado `abac-project-role`:
+ En **Step 1: Select trusted entity** (Paso 1: Seleccionar una entidad de confianza): seleccione **AWS account** (Cuenta de ) y luego **This account** (Esta cuenta).
+ En **Step 2: Add permissions** (Paso 2: agregar permisos): adjunte las cuatro políticas de IAM que creó en los pasos anteriores.
+ En **Step 3: Name, review, and create** (Paso 3: nombrar, revisar y crear): elija **Add tag** (Agregar etiqueta). En **Clave**, escriba `project`. No ingrese nada en **Value** (Valor).
## Paso 6: crear el usuario de IAM
[Cree un usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) denominado `abac-test-user`. En la sección **Set permissions** (Establecer permisos), elija **Attach existing policies directly** (Adjuntar directamente las políticas existentes) y, a continuación, **Create policy** (Crear política). Escriba la siguiente definición de política. Reemplace *111122223333* por su [ID de cuenta de AWS](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingYourAccountIdentifiers). Esta política permite al `abac-test-user` asumir el `abac-project-role`.
**Example — Permitir que el usuario de IAM asuma el rol de ABAC**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/abac-project-role"
}
}
```
------
## Paso 7: probar los permisos
1. Inicie sesión en la consola de AWS como `abac-test-user`. Para obtener más información, consulte [Iniciar sesión como usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/console.html#user-sign-in-page).
1. Cambie al rol `abac-project-role`. Para obtener más información, consulte [Cambiar a un rol (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html).
1. [Cree una función de Lambda](configuration-tags.md#using-tags-with-the-console):
+ En **Permissions** (Permisos), elija **Change default execution role** (Cambiar rol de ejecución predeterminado) y, a continuación, en **Execution role** (Rol de ejecución), elija **Use an existing role** (Usar un rol existente). Elija el mismo rol de ejecución que utilizó en [Paso 4: conceder permisos de IAM](#abac-iam-permissions).
+ En **Advanced settings** (Configuración avanzada), elija **Enable tags** (Habilitar etiquetas) y, a continuación, **Add new tag** (Agregar nueva etiqueta). En **Clave**, escriba `project`. No ingrese nada en **Value** (Valor).
1. [Pruebe la función](testing-functions.md).
1. Cree una segunda función de Lambda y agregue una etiqueta diferente, como `environment`. Esta operación puede fallar porque la política de ABAC que creó en [Paso 1: solicitar etiquetas en las nuevas funciones](#require-tag-on-create) solo permite a la entidad principal crear funciones con la etiqueta `project`.
1. Cree una tercera función sin etiquetas. Esta operación puede fallar porque la política de ABAC que creó en [Paso 1: solicitar etiquetas en las nuevas funciones](#require-tag-on-create) solo permite a la entidad principal crear funciones sin etiquetas.
Esta estrategia de autorización permite controlar el acceso sin crear nuevas políticas para cada usuario nuevo. Para conceder acceso a los nuevos usuarios, basta con darles permiso a fin de que asuman el rol que corresponde a su proyecto asignado.
## Paso 8: Eliminar los recursos
**Para eliminar el rol de IAM**
1. Abra la [página Roles](https://console.aws.amazon.com/iam/home#/roles) en la consola de IAM.
1. Seleccione el rol que creó en el [paso 5](#abac-create-role).
1. Elija **Eliminar**.
1. Para confirmar la eliminación, escriba el nombre del rol en el campo de entrada de texto.
1. Elija **Eliminar**.
**Cómo eliminar el usuario de IAM**
1. Abra la [página Users](https://console.aws.amazon.com/iam/home#/users) en la consola de IAM;.
1. Seleccione el usuario de IAM que ha creado en el [paso 6](#abac-create-user).
1. Elija **Eliminar**.
1. Para confirmar la eliminación, escriba el nombre del usuario en el campo de entrada de texto.
1. Elija **Eliminar usuario**.
**Cómo eliminar la función de Lambda**
1. Abra la [página de Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Seleccione la función que ha creado.
1. Elija **Acciones**, **Eliminar**.
1. Escriba **confirm** en el campo de entrada de texto y seleccione **Delete** (Eliminar).
# Afinar las secciones de recursos y condiciones de las políticas
Puede restringir el ámbito de los permisos de un usuario mediante la especificación de recursos y condiciones en una política de AWS Identity and Access Management (IAM). Todas las acciones en una política admiten una combinación de tipos de recursos y condiciones que varía en función del comportamiento de la acción.
Cada instrucción de una política de IAM concede permiso para realizar una acción en un recurso. Cuando la acción no actúa sobre un recurso nombrado, o cuando se concede permiso para realizar la acción sobre todos los recursos, el valor del recurso en la política es un comodín (`*`). Para muchas acciones, puede restringir los recursos que un usuario puede modificar si especifica el nombre de recurso de Amazon (ARN) de un recurso o un patrón de ARN que coincida con varios recursos.
Por tipo de recurso, el diseño general de cómo restringir el alcance de una acción es el siguiente:
+ Funciones: las acciones que operan sobre una función se pueden restringir a una función específica por ARN de función, versión o alias.
+ Asignaciones de orígenes de eventos: el ARN puede restringir las acciones a recursos de asignación de orígenes de eventos específicos. Las asignaciones de orígenes de eventos siempre están asociadas a una función. También puede usar la condición `lambda:FunctionArn` para restringir acciones por función asociada.
+ Capas: las acciones relacionadas con el uso y los permisos de capa actúan sobre una versión de una capa.
+ Configuración de firma de código: el ARN puede restringir las acciones a recursos de configuración de firma de código específicos.
+ Etiquetas: utilice condiciones de etiqueta estándar. Para obtener más información, consulte [Control de acceso basado en atributos para Lambda](attribute-based-access-control.md).
Para restringir los permisos por recurso, especifique el recurso por ARN.
**Formato de ARN de recurso de Lambda**
+ Función: – `arn:aws:lambda:us-west-2:123456789012:function:my-function`
+ Versión de la función: – `arn:aws:lambda:us-west-2:123456789012:function:my-function:1`
+ Alias de la función: – `arn:aws:lambda:us-west-2:123456789012:function:my-function:TEST`
+ Asignación de origen de eventos: – `arn:aws:lambda:us-west-2:123456789012:event-source-mapping:fa123456-14a1-4fd2-9fec-83de64ad683de6d47`
+ Capa: – `arn:aws:lambda:us-west-2:123456789012:layer:my-layer`
+ Versión de la capa: – `arn:aws:lambda:us-west-2:123456789012:layer:my-layer:1`
+ Configuración de firma de código: `arn:aws:lambda:us-west-2:123456789012:code-signing-config:my-csc`
Por ejemplo, la siguiente política permite que un usuario en una Cuenta de AWS `123456789012` invoque una función denominada `my-function` en la región de AWS Oeste de EE. UU. (Oregón).
**Example invocar política de función**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Invoke",
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction"
],
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:my-function"
}
]
}
```
Se trata de un caso especial donde el identificador de la acción (`lambda:InvokeFunction`) difiere de la operación de la API ([Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html)). Para otras acciones, el identificador de la acción es el nombre de la operación con el prefijo `lambda:`.
**Topics**
+ [Comprensión de la sección de condiciones de las políticas](#authorization-conditions)
+ [Hacer referencia a las funciones en la sección de recursos de las políticas](#function-resources)
+ [Acciones y comportamientos de funciones de IAM compatibles](#permissions-resources)
## Comprensión de la sección de condiciones de las políticas
Las condiciones son un elemento opcional de la política que aplica lógica adicional para determinar si se permite o no una acción. Además de las [condiciones](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) comunes que admiten todas las acciones, Lambda define tipos de condiciones que puede utilizar para restringir los valores de parámetros adicionales en algunas acciones.
Por ejemplo, la condición `lambda:Principal` permite restringir el servicio o la cuenta a los que un usuario puede conceder acceso de invocación en la [política basada en recursos](access-control-resource-based.md) de una función. La siguiente política permite a un usuario conceder permiso a los temas de Amazon Simple Notification Service (Amazon SNS) para invocar una función denominada `test`.
**Example administrar permisos de una política de función**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ManageFunctionPolicy",
"Effect": "Allow",
"Action": [
"lambda:AddPermission",
"lambda:RemovePermission"
],
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:test:*",
"Condition": {
"StringEquals": {
"lambda:Principal": "sns.amazonaws.com"
}
}
}
]
}
```
La condición requiere que el principal sea Amazon SNS y no otro servicio o cuenta. El patrón de recursos requiere que el nombre de la función sea `test` e incluye un número de versión o alias. Por ejemplo, `test:v1`.
Para obtener más información sobre los recursos y las condiciones para Lambda y otros servicios de AWS, consulte [Acciones, recursos y claves de condición para los servicios de AWS](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html) en la *Referencia de autorización de servicios*.
## Hacer referencia a las funciones en la sección de recursos de las políticas
Puede hacer referencia a una función de Lambda en la instrucción de una política con un nombre de recurso de Amazon (ARN). El formato de un ARN de función depende de si se hace referencia a toda la función (incompleto), o a la [versión](configuration-versions.md) o el [alias](configuration-aliases.md) de la función (completo).
Cuando realizan llamadas a la API de Lambda, los usuarios pueden especificar una versión o un alias al pasar el ARN de la versión o el alias en el parámetro [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html) de `FunctionName`, o al establecer un valor en el parámetro [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html) de `Qualifier`. Lambda toma decisiones de autorización comparando el elemento de recurso de la política de IAM con el `FunctionName` y el `Qualifier` pasado en las llamadas a la API. Si hay un error de coincidencia, Lambda deniega la solicitud.
Tanto si permite o deniega una acción en la función, debe utilizar los tipos de ARN de función correctos en la instrucción de la política para obtener los resultados esperados. Por ejemplo, si su política hace referencia al ARN incompleto, Lambda acepta las solicitudes que hacen referencia al ARN incompleto, pero deniega las solicitudes que hacen referencia a un ARN completo.
**nota**
No se puede utilizar un carácter comodín (\$1) para que coincida con el ID de cuenta. Para obtener más información sobre la sintaxis aceptada, consulte la [referencia de la política JSON de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) en la *Guía del usuario de IAM*.
**Example permitir la invocación de un ARN incompleto**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction"
}
]
}
```
Si su política hace referencia a un ARN completo específico, Lambda acepta las solicitudes que hacen referencia al ARN, pero deniega las solicitudes que hagan referencia a un ARN incompleto o a otro ARN completo, como ., `myFunction:2`.
**Example permitir la invocación de un ARN completo específico**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction:1"
}
]
}
```
Si su política hace referencia a cualquier ARN completo mediante `:*`, Lambda acepta cualquier ARN completo, pero deniega las solicitudes que hagan referencia a un ARN incompleto.
**Example permitir la invocación de cualquier ARN completo**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction:*"
}
]
}
```
Si su política hace referencia a cualquier ARN mediante `*`, Lambda acepta cualquier ARN completo o incompleto.
**Example permitir la invocación de cualquier ARN completo o incompleto**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction*"
}
]
}
```
## Acciones y comportamientos de funciones de IAM compatibles
Las acciones definen lo que se puede permitir mediante las políticas de IAM. Para obtener una lista de acciones admitidas en Lambda, consulte [Acciones, recursos y claves de condición para AWS Lambda](https://docs.aws.amazon.com//service-authorization/latest/reference/list_awslambda.html) en la Referencia de autorizaciones de servicio. En la mayoría de los casos, cuando una acción de IAM permite una acción de la API de Lambda, el nombre de la acción de IAM es el mismo que el nombre de la acción de la API de Lambda, con las siguientes excepciones:
| Acción de la API | Acción de IAM |
| --- | --- |
| [Invoke](https://docs.aws.amazon.com//lambda/latest/api/API_Invoke.html) | lambda:InvokeFunction |
| [GetLayerVersion](https://docs.aws.amazon.com//lambda/latest/api/API_GetLayerVersion.html) [GetLayerVersionByArn](https://docs.aws.amazon.com//lambda/latest/api/API_GetLayerVersionByArn.html) | lambda:GetLayerVersion |
Además de los recursos y condiciones definidos en la [referencia de autorizaciones de servicio](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awslambda.html), Lambda admite los siguientes recursos y condiciones para determinadas acciones. Muchos de ellos están relacionados con las funciones de referencia en la sección de recursos de las políticas. Las acciones que operan sobre una función se pueden restringir a una función específica por ARN de función, versión o alias, tal y como se describe en la siguiente tabla.
| Action | Recurso | Condición |
| --- | --- | --- |
| [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html) [RemovePermission](https://docs.aws.amazon.com/lambda/latest/api/API_RemovePermission.html) [Invocar](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) (**permiso:** `lambda:InvokeFunction`) | Versión de función Alias de función | N/A |
| [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) | N/A | `lambda:CodeSigningConfigArn` |
| [CreateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html) [DeleteFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionUrlConfig.html) [GetFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionUrlConfig.html) [UpdateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionUrlConfig.html) | Alias de función | N/A |