Durante años, permisar una función de Lambda fue el punto ciego de cualquier arquitectura serverless bien gobernada: se hacía principal por principal, con un AddPermission por cada servicio que necesitara invocarla. AWS acaba de cerrar ese hueco y habilitó políticas resource-based de IAM completas en Lambda, disponibles en todas las regiones comerciales y sin costo adicional.
Qué pasó
El 25 de agosto AWS anunció que las funciones de Lambda ya soportan políticas resource-based de IAM completas: un solo documento de política puede definir permisos para múltiples principals y múltiples acciones, y usar todo el catálogo de condition keys de IAM.
Hasta ahora el modelo era otro. Lambda mantenía una política de recurso degradada donde cada permiso se agregaba de forma individual por principal, típicamente con lambda:AddPermission. El resultado, en cuentas grandes, era un archivo de statements inflado, difícil de auditar y prácticamente imposible de expresar como código limpio. Quien haya intentado revisar quién puede invocar 300 funciones repartidas en 12 cuentas sabe exactamente de qué tamaño era el problema.
El mismo día, y en la misma dirección, AWS movió otra pieza de plomería de seguridad: Secrets Manager extendió su capacidad de managed external secrets a las API keys de Cisco Security Platform (Security Cloud Control) y a los tokens de API de Netskope. Se suman a la lista que ya incluía BigID, Confluent Cloud, Datadog, GitLab, Jenkins, MongoDB Atlas, Okta, Paddle, Salesforce, Snowflake y SonarQube.
Por qué importa
Los dos anuncios cuentan la misma historia: AWS está absorbiendo hacia servicios administrados el trabajo de identidad y credenciales que hasta ahora vivía en scripts caseros de cada equipo.
En el caso de Lambda, el cambio no agrega una feature vistosa; corrige una asimetría. S3, SQS, KMS y compañía siempre tuvieron políticas de recurso de verdad. Lambda, que es el pegamento de media arquitectura event-driven, no. Eso obligaba a los equipos de plataforma a compensar con automatización propia o a permisar de más "porque así sí funciona" — el camino directo a un Principal: "*" mal acotado.
Para quien opera multi-cuenta el beneficio es inmediato: una política, varios principals, condition keys reales. Se puede restringir invocación por aws:SourceIp, por aws:PrincipalTag, por aws:SourceArn, y expresarlo en un solo documento que un revisor humano puede leer de corrido y que una herramienta de postura puede evaluar sin adivinar.
En el caso de Secrets Manager, el detalle interesante es que ahora el rotador de credenciales de tus herramientas de seguridad es el cloud provider. Las integraciones son self-authenticating: la credencial guardada autoriza su propia rotación, así que no hace falta una credencial de administrador aparte. Para Cisco, Secrets Manager rota el refresh token del API key siguiendo el patrón OAuth estándar y captura el nuevo que Cisco reemite periódicamente; para Netskope, rota tokens de service account RBACv3 vía la API SCIM y valida el token nuevo antes de dar la rotación por concluida.
El detalle técnico
Lo relevante de la política completa de Lambda es qué se vuelve expresable. Antes, cada permiso era un statement generado por la API, con un Sid autoasignado y un solo principal. Ahora se edita el documento entero en un paso: desde el editor JSON de la consola, el CLI, el SDK, o infraestructura como código con CloudFormation y SAM.
El patrón que más va a cambiar es el de "varios servicios invocan la misma función". Un API Gateway, un EventBridge y un par de roles de otra cuenta dejan de ser tres o cuatro statements acumulados por llamadas sucesivas y pasan a ser un bloque con una lista de principals y sus condiciones. La diferencia operativa es la auditabilidad: un diff en el repo muestra el cambio de permisos completo, no el efecto lateral de un comando ejecutado hace ocho meses.
Sobre la rotación validada de Netskope, vale subrayar el paso que muchos rotadores caseros omiten: verificar que el token nuevo funcione antes de descartar el anterior. Es la diferencia entre una rotación y un outage programado a las 3 de la mañana.
Qué hacer
- Inventaría antes de migrar. Saca las políticas de recurso actuales de tus funciones (
lambda:GetPolicy) y revisa cuántos statements acumulados hay. Es normal encontrar permisos de integraciones que ya no existen. - Consolida con condiciones, no solo con principals. Al reescribir, aprovecha para meter
aws:SourceArnyaws:SourceAccounten las invocaciones cross-service. Si vas a tocar la política de todas formas, cierra el confused deputy de una vez. - Llévalo a IaC. El valor real del cambio es que la política vive en el repo y no en el estado mutable de la cuenta. Si sigues permisando con
AddPermissiondesde un pipeline, no ganaste nada. - Si usas Cisco Security Cloud Control o Netskope en AWS, evalúa mover esa credencial a managed external secrets y jubila el Lambda de rotación que alguien escribió en 2023 y nadie ha vuelto a leer.
- Revisa tu tooling de postura. Las herramientas que parsean políticas de recurso de Lambda asumiendo un statement por principal van a necesitar actualizarse.
Fuentes
- AWS Lambda functions now support full IAM resource-based policies — AWS What's New, 25 ago 2026
- AWS Secrets Manager adds managed external secrets support for Cisco Security Platform and Netskope — AWS What's New, 25 ago 2026
- Lambda resource-based policy examples — AWS Lambda Developer Guide