Forem: Juan Diego David Melo Alarcon

EKS Cross-Account con Lambda (No Binaries) | Integración Nativa EKS-Lambda entre cuentas

Juan Diego David Melo Alarcon — Tue, 17 Feb 2026 16:35:43 +0000

Spanish version followed by English version.

Recientemente enfrentamos un escenario interesante: necesitábamos que una AWS Lambda interactuara con controladores específicos de Kubernetes en varios clústeres de EKS. Bajo un stack estrictamente limitado a Python, tuvimos que diseñar una solución para gestionar la autenticación IAM y la comunicación con la API de K8s de forma eficiente.

El contexto

Como parte de una de las principales iniciativas de la organización, se debía habilitar la creación y modificación de recursos particulares (CRD) de EKS a demanda desde una función AWS Lambda. La función Lambda y el clúster EKS se encontraban en cuentas de AWS distintas dentro de la organización, lo cual añade una pequeña capa de gestión a la interacción entre cuentas.

La integración con Kubernetes desde Python

El primer desafío a sortear fue sobre la definición de cómo ejecutar operaciones de creación y modificación de Custom Resources en Kubernetes desde Python. Debido a restricciones del área de ciberseguridad de la organización, no estaba permitida la ejecución de comandos bash desde ningún lenguaje de programación (por ejemplo, mediante os o subprocess en Python).

La primera opción que se consideró fue el uso directo de la API REST expuesta por Kubernetes. Sin embargo, si bien esta es una opción viable, el nivel de abstracción de la implementación es bajo, por lo que requeriría un extendido tiempo de implementación para generar el acople con los endpoints requeridos.

Al indagar en la documentación de Kubernetes, se encontró que existe un cliente oficial de Kubernetes para Python. El cliente permite la creación y modificación de Custom Resources mediante los métodos create_namespaced_custom_object, replace_namespaced_custom_object y get_namespaced_custom_object. Estos métodos requieren como parámetros de entrada el group, version y plural que correspondan al Custom Resource Definition en cuestión.

Ej:

from kubernetes import client, config

def manage_custom_resource():
    group = "stable.example.com"
    version = "v1"
    plural = "mycustomresources" # Importante: siempre en plural
    namespace = "default"

    # Inicialización del cliente para Custom Objects
    custom_api = client.CustomObjectsApi()

    # Definición del cuerpo del recurso (manifest)
    resource_body = {
        "apiVersion": f"{group}/{version}",
        "kind": "MyCustomResource",
        "metadata": {"name": "example-instance"},
        "spec": {
            "setting": "value",
            "enabled": True
        }
    }

    try:
        # Ejemplo de creación
        response = custom_api.create_namespaced_custom_object(
            group=group,
            version=version,
            namespace=namespace,
            plural=plural,
            body=resource_body
        )
        print(f"Recurso creado: {response['metadata']['name']}")

    except client.exceptions.ApiException as e:
        print(f"Error interactuando con el API: {e}")

Esta implementación ofrece un nivel de abstracción mucho mayor, que no genera deuda técnica ni incurre en "reinventar la rueda" al momento de integrar la función Lambda con Kubernetes.

La autenticación con IAM

Con la integración con Kubernetes desde Python definida, surgió el siguiente desafío relacionado con la implementación: la autenticación. Dado que el cliente de Kubernetes es agnóstico a cualquier modelo de despliegue de un clúster, no cuenta con la capacidad nativa de tratar con el modelo de autenticación acoplado y propio de AWS IAM.

La implementación de Kubernetes en AWS EKS aplica la autenticación mediante tokens firmados de STS. El cliente nativo de Kubernetes permite establecer tokens de autenticación de la siguiente forma:

from kubernetes import client

def configure_k8s_client(cluster_endpoint, bearer_token):
    # Creamos la instancia de configuración del SDK
    configuration = client.Configuration()

    # URL del API Server obtenida de la consola de EKS o vía Boto3
    configuration.host = cluster_endpoint

    # Inyección del token en el header de Authorization
    configuration.api_key = f'Bearer {bearer_token}'

    # Retornamos el ApiClient configurado para realizar peticiones
    return client.ApiClient(configuration)

Pero, ¿cómo generamos ese token teniendo en cuenta que es firmado propiamente con AWS STS? Usualmente, para esta obtención se hace uso del comando de AWS CLI get-token:

aws eks get-token --cluster-name <nombre-del-cluster>

Sin embargo, al no poder invocar binarios externos, debemos replicar la lógica de este comando utilizando el SDK de AWS. La ventaja es que AWS CLI está desarrollado en Python de forma nativa. Revisando el repositorio del código fuente de AWS CLI, encontré la implementación correcta para generar el token de forma nativa desde Python mediante la clase TokenGenerator:

from awscli.customizations.eks.get_token import TokenGenerator, STSClientFactory
from botocore import session

def get_eks_token(cluster_name):
    """
    Genera un token de autenticación para un clúster de EKS
    utilizando la implementación nativa de AWS CLI.
    """
    session_aws = session.get_session()
    sts_client = STSClientFactory(session_aws).get_sts_client()

    return TokenGenerator(sts_client).get_token(cluster_name)

Para que esta implementación funcione es fundamental instalar la librería awscli con pip.

Configuración entre cuentas

Habiendo solventado los desafíos de la integración y la autenticación, falta un único aspecto técnico que se debe abordar: la configuración entre cuentas. Dado que la función Lambda y el clúster EKS se encontraban en cuentas diferentes, se debía establecer una configuración entre cuentas. Para que la función Lambda pueda acceder al clúster de EKS, debe contar con el permiso para ejecutar la acción eks:DescribeCluster. Revisé la lista de servicios que soportan las políticas basadas en recurso para validar la posibilidad de hacer la concesión de este permiso sin crear un rol IAM adicional. Sin embargo, EKS no soporta este tipo de políticas, por lo que se debe crear un rol entre cuentas en la cuenta donde se encuentra el clúster EKS para que sea asumido por la función Lambda. Este rol debe conceder la acción eks:DescribeCluster. A continuación se encuentra el detalle de la política de confianza y la política de permisos para este nuevo rol:

Política de confianza:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<ID_CUENTA_LAMBDA>:role/<NOMBRE_ROL_EJECUCION_LAMBDA>"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Política de Permisos:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks:DescribeCluster"
      ],
      "Resource": "arn:aws:eks:<REGION>:<ID_CUENTA_EKS>:cluster/<NOMBRE_DEL_CLUSTER>"
    }
  ]
}

Arquitectura final

El código para la implementación final es el siguiente:

import os
import boto3
from awscli.customizations.eks.get_token import TokenGenerator, STSClientFactory
from botocore import session
from kubernetes import client

# --- 1. Lógica de Autenticación AWS (Cross-Account) ---

def get_assumed_credentials(role_arn):
    """
    Asume el rol en la cuenta destino para obtener credenciales temporales.
    Utiliza el rol de ejecución de la Lambda como entidad de confianza.
    """
    sts = boto3.client('sts')
    response = sts.assume_role(
        RoleArn=role_arn,
        RoleSessionName="EKS-Lambda-CrossAccount"
    )
    return response['Credentials']

def generate_eks_token(cluster_name, credentials):
    """
    Genera el token de EKS seteando temporalmente variables de entorno del sistema
    para que la clase TokenGenerator de awscli firme correctamente la petición.
    """
    # Seteo de variables de entorno (Estrategia nativa de AWS CLI)
    os.environ['AWS_ACCESS_KEY_ID'] = credentials['AccessKeyId']
    os.environ['AWS_SECRET_ACCESS_KEY'] = credentials['SecretAccessKey']
    os.environ['AWS_SESSION_TOKEN'] = credentials['SessionToken']

    try:
        # Replicamos el comportamiento de 'aws eks get-token'
        session_aws = session.get_session()
        sts_client = STSClientFactory(session_aws).get_sts_client()
        token = TokenGenerator(sts_client).get_token(cluster_name)
    finally:
        # Higiene de seguridad: Eliminamos las credenciales del entorno
        os.environ.pop('AWS_ACCESS_KEY_ID', None)
        os.environ.pop('AWS_SECRET_ACCESS_KEY', None)
        os.environ.pop('AWS_SESSION_TOKEN', None)

    return token

# --- 2. Lógica de Configuración del Cliente Kubernetes ---

def get_k8s_custom_client(cluster_name, credentials):
    """
    Obtiene los datos del clúster (endpoint) y configura el cliente de K8s 
    usando el CustomObjectsApi para interactuar con CRDs.
    """
    # El cliente de EKS debe usar las credenciales asumidas para describir el clúster
    eks_client = boto3.client(
        'eks',
        aws_access_key_id=credentials['AccessKeyId'],
        aws_secret_access_key=credentials['SecretAccessKey'],
        aws_session_token=credentials['SessionToken'],
        region_name=os.environ.get('AWS_REGION')
    )

    cluster_info = eks_client.describe_cluster(name=cluster_name)
    endpoint = cluster_info['cluster']['endpoint']

    # Generamos el token de acceso seguro
    token = generate_eks_token(cluster_name, credentials)

    # Configuración del SDK de Kubernetes
    k8s_config = client.Configuration()
    k8s_config.host = endpoint
    k8s_config.verify_ssl = False  # Nota: En prod se recomienda usar CA data
    k8s_config.api_key = {'authorization': f'Bearer {token}'}

    api_instance = client.ApiClient(k8s_config)
    return client.CustomObjectsApi(api_instance)

# --- 3. Operación Genérica sobre Custom Resources ---

def get_custom_resource(custom_api, group, version, namespace, plural, name):
    """
    Consulta un Custom Resource genérico. 
    Ideal para gestionar operadores (ej. Strimzi, Argo, etc.)
    """
    try:
        return custom_api.get_namespaced_custom_object(
            group, version, namespace, plural, name
        )
    except client.exceptions.ApiException as e:
        if e.status == 404:
            return None
        raise e

# --- 4. Handler de la Lambda ---

def lambda_handler(event, context):
    # Variables de entorno configuradas en la Lambda
    CLUSTER_NAME = os.environ['CLUSTER_NAME']
    ROLE_ARN_DESTINO = os.environ['CROSS_ACCOUNT_ROLE_ARN']

    # Coordenadas del Custom Resource (pueden venir del evento)
    CR_GROUP = event.get('group')    
    CR_VERSION = event.get('version') 
    CR_PLURAL = event.get('plural')   
    NAME = event.get('name')
    NAMESPACE = event.get('namespace', 'default')

    # Flujo de ejecución: Asumir Rol -> Configurar Cliente -> Ejecutar Operación
    creds = get_assumed_credentials(ROLE_ARN_DESTINO)
    k8s_client = get_k8s_custom_client(CLUSTER_NAME, creds)

    resource = get_custom_resource(
        k8s_client, CR_GROUP, CR_VERSION, NAMESPACE, CR_PLURAL, NAME
    )

    return {
        'statusCode': 200,
        'body': resource if resource else "Resource not found"
    }_key_id=credentials['AccessKeyId'],
        aws_secret

Nota final

Con la implementación anterior, la capa de conectividad y autenticación queda totalmente resuelta. El último paso, común a cualquier integración con Kubernetes, es asegurar que el clúster reconozca la identidad que acabamos de crear.

Para ello, basta con mapear el ARN del rol asumido en la Cuenta B dentro de Kubernetes. Esto se gestiona mediante las EKS Access Entries (o el ConfigMap aws-auth), vinculándolo a los Roles de RBAC necesarios para operar los recursos. Es el procedimiento estándar de seguridad para otorgar permisos granulares una vez establecida la conexión.

Puedes consultar los detalles de esta configuración final en la documentación oficial.

English Version

Recently, we faced an interesting scenario: we needed an AWS Lambda to interact with specific Kubernetes controllers in several EKS clusters. Under a strictly Python-limited stack, we had to design a solution to efficiently manage IAM authentication and communication with the K8s API.

The context

As part of one of the organization's main initiatives, the creation and modification of specific EKS Custom Resources (CRDs) had to be enabled on demand from an AWS Lambda function. The Lambda function and the EKS cluster were in different AWS accounts within the organization, which adds a small management layer to the cross-account interaction.

Integrating with Kubernetes from Python

The first challenge to overcome was defining how to execute creation and modification operations for Custom Resources in Kubernetes from Python. Due to organization cybersecurity restrictions, executing bash commands from any programming language (e.g., using osor subprocessin Python) was not allowed.

The first option considered was the direct use of the REST API exposed by Kubernetes. However, while this is a viable option, the implementation's abstraction level is low, requiring extensive implementation time to create the coupling with the required endpoints.

While researching the Kubernetes documentation, an official Kubernetes client for Python was found. The client allows for the creation and modification of Custom Resources through the create_namespaced_custom_object, replace_namespaced_custom_object, and get_namespaced_custom_object methods. These methods require group, version, and plural as input parameters corresponding to the Custom Resource Definition in question.

Ex:

from kubernetes import client, config

def manage_custom_resource():
    group = "stable.example.com"
    version = "v1"
    plural = "mycustomresources" # Important: always plural
    namespace = "default"

    # Custom Objects client initialization
    custom_api = client.CustomObjectsApi()

    # Resource body definition (manifest)
    resource_body = {
        "apiVersion": f"{group}/{version}",
        "kind": "MyCustomResource",
        "metadata": {"name": "example-instance"},
        "spec": {
            "setting": "value",
            "enabled": True
        }
    }

    try:
        # Creation example
        response = custom_api.create_namespaced_custom_object(
            group=group,
            version=version,
            namespace=namespace,
            plural=plural,
            body=resource_body
        )
        print(f"Resource created: {response['metadata']['name']}")

    except client.exceptions.ApiException as e:
        print(f"Error interacting with the API: {e}")

This implementation offers a much higher abstraction level, which does not generate technical debt or incur in "reinventing the wheel" when integrating the Lambda function with Kubernetes.

IAM Authentication

With the Kubernetes integration from Python defined, the next implementation challenge arose: authentication. Since the Kubernetes client is agnostic to any cluster deployment model, it lacks the native capability to handle the coupled authentication model specific to AWS IAM.

The Kubernetes implementation on AWS EKS applies authentication through signed STS tokens. The native Kubernetes client allows setting authentication tokens as follows:

from kubernetes import client

def configure_k8s_client(cluster_endpoint, bearer_token):
    # Create the SDK configuration instance
    configuration = client.Configuration()

    # API Server URL obtained from the EKS console or via Boto3
    configuration.host = cluster_endpoint

    # Injecting the token into the Authorization header
    configuration.api_key = f'Bearer {bearer_token}'

    # Return the configured ApiClient to perform requests
    return client.ApiClient(configuration)

But, how do we generate that token considering it is signed specifically with AWS STS? Usually, this is obtained using the AWS CLI get-token command:

aws eks get-token --cluster-name <cluster-name>

However, since we cannot invoke external binaries, we must replicate the logic of this command using the AWS SDK. The advantage is that AWS CLI is natively developed in Python. Reviewing the AWS CLI source code repository, I found the correct implementation to generate the token natively from Python using the TokenGenerator class:

from awscli.customizations.eks.get_token import TokenGenerator, STSClientFactory
from botocore import session

def get_eks_token(cluster_name):
    """
    Generates an authentication token for an EKS cluster
    using the native AWS CLI implementation.
    """
    session_aws = session.get_session()
    sts_client = STSClientFactory(session_aws).get_sts_client()

    return TokenGenerator(sts_client).get_token(cluster_name)

For this implementation to work, it is essential to install the awscli library with pip.

Cross-account configuration

Having solved the integration and authentication challenges, there is one last technical aspect to address: cross-account configuration. Since the Lambda function and the EKS cluster were in different accounts, a cross-account configuration had to be established. For the Lambda function to access the EKS cluster, it must have permission to execute the eks:DescribeCluster action. I reviewed the list of services that support resource-based policies to validate the possibility of granting this permission without creating an additional IAM role. However, EKS does not support these types of policies, so a cross-account role must be created in the account where the EKS cluster resides to be assumed by the Lambda function. This role must grant the eks:DescribeCluster action. Below are the details of the trust policy and the permissions policy for this new role:

Trust Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<LAMBDA_ACCOUNT_ID>:role/<LAMBDA_EXECUTION_ROLE_NAME>"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Permissions Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks:DescribeCluster"
      ],
      "Resource": "arn:aws:eks:<REGION>:<EKS_ACCOUNT_ID>:cluster/<CLUSTER_NAME>"
    }
  ]
}

Final architecture

The code for the final implementation is as follows:

import os
import boto3
from awscli.customizations.eks.get_token import TokenGenerator, STSClientFactory
from botocore import session
from kubernetes import client

# --- 1. AWS Authentication Logic (Cross-Account) ---

def get_assumed_credentials(role_arn):
    """
    Assumes the role in the destination account to obtain temporary credentials.
    Uses the Lambda execution role as the trust entity.
    """
    sts = boto3.client('sts')
    response = sts.assume_role(
        RoleArn=role_arn,
        RoleSessionName="EKS-Lambda-CrossAccount"
    )
    return response['Credentials']

def generate_eks_token(cluster_name, credentials):
    """
    Generates the EKS token by temporarily setting system environment variables
    so that the awscli TokenGenerator class correctly signs the request.
    """
    # Environment variable setting (Native AWS CLI strategy)
    os.environ['AWS_ACCESS_KEY_ID'] = credentials['AccessKeyId']
    os.environ['AWS_SECRET_ACCESS_KEY'] = credentials['SecretAccessKey']
    os.environ['AWS_SESSION_TOKEN'] = credentials['SessionToken']

    try:
        # Replicating the 'aws eks get-token' behavior
        session_aws = session.get_session()
        sts_client = STSClientFactory(session_aws).get_sts_client()
        token = TokenGenerator(sts_client).get_token(cluster_name)
    finally:
        # Security hygiene: Remove credentials from the environment
        os.environ.pop('AWS_ACCESS_KEY_ID', None)
        os.environ.pop('AWS_SECRET_ACCESS_KEY', None)
        os.environ.pop('AWS_SESSION_TOKEN', None)

    return token

# --- 2. Kubernetes Client Configuration Logic ---

def get_k8s_custom_client(cluster_name, credentials):
    """
    Obtains cluster data (endpoint) and configures the K8s client 
    using CustomObjectsApi to interact with CRDs.
    """
    # The EKS client must use the assumed credentials to describe the cluster
    eks_client = boto3.client(
        'eks',
        aws_access_key_id=credentials['AccessKeyId'],
        aws_secret_access_key=credentials['SecretAccessKey'],
        aws_session_token=credentials['SessionToken'],
        region_name=os.environ.get('AWS_REGION')
    )

    cluster_info = eks_client.describe_cluster(name=cluster_name)
    endpoint = cluster_info['cluster']['endpoint']

    # Generating the secure access token
    token = generate_eks_token(cluster_name, credentials)

    # Kubernetes SDK configuration
    k8s_config = client.Configuration()
    k8s_config.host = endpoint
    k8s_config.verify_ssl = False  # Note: In prod, using CA data is recommended
    k8s_config.api_key = {'authorization': f'Bearer {token}'}

    api_instance = client.ApiClient(k8s_config)
    return client.CustomObjectsApi(api_instance)

# --- 3. Generic Operation on Custom Resources ---

def get_custom_resource(custom_api, group, version, namespace, plural, name):
    """
    Queries a generic Custom Resource. 
    Ideal for managing operators (e.g., Strimzi, Argo, etc.)
    """
    try:
        return custom_api.get_namespaced_custom_object(
            group, version, namespace, plural, name
        )
    except client.exceptions.ApiException as e:
        if e.status == 404:
            return None
        raise e

# --- 4. Lambda Handler ---

def lambda_handler(event, context):
    # Environment variables configured in the Lambda
    CLUSTER_NAME = os.environ['CLUSTER_NAME']
    ROLE_ARN_DESTINO = os.environ['CROSS_ACCOUNT_ROLE_ARN']

    # Custom Resource coordinates (may come from the event)
    CR_GROUP = event.get('group')    
    CR_VERSION = event.get('version') 
    CR_PLURAL = event.get('plural')   
    NAME = event.get('name')
    NAMESPACE = event.get('namespace', 'default')

    # Execution flow: Assume Role -> Configure Client -> Execute Operation
    creds = get_assumed_credentials(ROLE_ARN_DESTINO)
    k8s_client = get_k8s_custom_client(CLUSTER_NAME, creds)

    resource = get_custom_resource(
        k8s_client, CR_GROUP, CR_VERSION, NAMESPACE, CR_PLURAL, NAME
    )

    return {
        'statusCode': 200,
        'body': resource if resource else "Resource not found"
    }

Final note

With the previous implementation, the connectivity and authentication layer is fully resolved. The last step, common to any Kubernetes integration, is to ensure the cluster recognizes the identity we just created.

To do this, simply map the assumed role's ARN in Account B within Kubernetes. This is managed through EKS Access Entries (or the aws-auth ConfigMap), linking it to the required RBAC Roles to operate the resources. This is the standard security procedure for granting granular permissions once the connection is established.

You can check the details of this final configuration in the official documentation.

[Boost]

Juan Diego David Melo Alarcon — Mon, 12 Jan 2026 16:44:15 +0000

Asegurar un rol de servicio para AWS Lambda - Secure the service role used by AWS Lambda

Juan Diego David Melo Alarcon ・ Jan 12

#aws #lambda #iam #security

Asegurar un rol de servicio para AWS Lambda - Secure the service role used by AWS Lambda

Juan Diego David Melo Alarcon — Mon, 12 Jan 2026 16:41:59 +0000

Spanish version followed by English version.

Durante el diseño de una solución crítica basada en AWS Lambda, surgió una pregunta poco habitual: ¿es posible garantizar que un rol de servicio para pueda ser utilizado por una única función, incluso dentro de la misma cuenta de AWS?
En este artículo analizo el problema y presentó una solución basada en políticas de confianza que respeta el comportamiento interno de AWS Lambda, incluyendo escenarios con configuración de VPC.
Voy a desglosar el contexto técnico y de arquitectura que derivó en la necesidad.

El contexto

Dentro de la organización hay una arquitectura empresarial que define una gran cantidad de cuentas de AWS por área y ambiente. Debido al enorme tamaño de la organización, una gran cantidad de equipos tiene acceso para desplegar recursos dentro de una misma cuenta.
La función lambda en cuestión tiene como objetivo realizar diversas operaciones administrativas; estas operaciones se ejecutan sobre una plataforma de uso transversal dentro de toda organización, por lo que se vuelve una solución bastante crítica y sensible.
Los permisos administrativos sobre la plataforma transversal se otorgan mediante el rol de servicio IAM de la función lambda. Debido a que otros equipos pueden desplegar recursos en la misma cuenta, se podría hacer uso indebido de este rol con accesos privilegiados.

Recordemos como se ve la política de confianza de un rol de servicio estándar de AWS Lambda

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      }
  ]
}

Esta política de confianza de un rol IAM permite que cualquier función lambda dentro de la misma cuenta de AWS pueda hacer uso del mismo.

Primer intento: Denegación explícita

¿Cómo asegurar el rol para que no pueda ser usado por otra función dentro de la misma cuenta? Lo primero que se me ocurrió fue colocar una declaración adicional a la política de confianza que aplicará una denegación explícita a la acción assumeRole a todas las entidades de AWS, excepto a la autorizada. Use el operador ArnNotEquals dentro de una condición para lograr esto. El efecto final esperado es que se deniegue la acción para asumir el rol a cualquier entidad, recordemos que una denegación explícita prevalece sobre cualquier permiso concedido explícitamente, excepto a la función lambda autorizada.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Sid": "ExplicitDenyForAllExceptAuthorizedLambda",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnNotEquals": {
          "aws:SourceArn": "arn:aws:lambda:REGION:ACCOUNT_ID:function:AUTHORIZED_LAMBDA_NAME"
        }
      }
    }
  ]
}

una vez se desplegó el rol con esta nueva política de confianza la función lambda no tuvo ningún inconveniente para usar el rol de servicio y a su vez, cuando cualquier otra función lambda se intentaba desplegar asociando ese mismo rol de servicio, Obtenía un error al momento de desplegar por falta de permisos. En resumen se logró el comportamiento esperado

El problema de VPC

Hasta ese punto todo bien ¿verdad? Resulta que por aspectos técnicos de la plataforma transversal, sobre la cual la función debe ejecutar operaciones, la función debía desplegarse con configuración de VPC para desplegarse en la red interna de la cuenta de AWS. Resulta que al añadir la configuración de VPC a la función lambda, se presentó un error en el despliegue relacionado a la falta de permisos para asumir el rol.

Entonces ¿Qué sucedió? resulta que al agregar una configuración de VPC a la función Lambda. El servicio ejecuta una serie de acciones de forma subyacente, estas acciones deben hacer uso del service rol de la lambda para crear las interfaces de red, asignar IPs y demás; Estas acciones son ejecutadas por recursos administrados por AWS, recursos que están incluidos en la definición de servicio: "Service": "lambda.amazonaws.com".

Sin embargo, la declaración que aplica la denegación sólo excluye la ARN de la función Lambda. Se necesita que el rol pueda ser usado por recursos adicionales de VPC asociados al servicio de AWS Lambda. Investigando cómo ajustar una condición que haga esto posible, encontré la jerarquía de operadores lógicos que se aplican en una condición IAM compuesta. Resulta que cuando se hace uso de múltiples operadores (ArnEquals, ArnNotequals, StringLike) dentro de una misma condición, la condición aplica una cadena de operación logica que aplica un AND para cada uno de los operadores.

ArnEquals(value) AND ArnNotequals(value) AND StringLike(value)

Solución final

Bajo esta premisa construí una condición que se adapta a la necesidad de restringir el uso de un rol para una única función lambda dentro de la misma cuenta.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Sid": "DenyAllOtherLambdasExceptAuthorizedOne",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnLike": {
          "aws:PrincipalArn": "arn:aws:lambda:*:*:function:*"
        },
        "ArnNotEquals": {
          "aws:PrincipalArn": "arn:aws:lambda:<REGION>:<ACCOUNT_ID>:function:<AUTHORIZED_LAMBDA_NAME>"
        }
      }
    }
  ]
}

Desglose de esta política de confianza:

La declaración que aplica un Allow es la estándar para un rol de servicio de AWS Lambda
La segunda declaración aplica un Deny es la que solventa la necesidad correctamente
Al tener dos operadores: ArnLike y ArnNotEquals, estos dos deben cumplirse para que la denegación sea efectiva
ArnLike: lo primero que se valida es que la entidad que trata de hacer uso del rol corresponda a la ARN de una función lambda, de esta manera no se deja inutilizable el rol en caso de que se use para una función con configuración VPC
ArnNotEquals: Aquí se valida que la función lambda que esté haciendo uso del rol no corresponda a la función autorizada, de esta manera una función diferente desplegada por otro equipo no podrá hacer uso indebido de el rol privilegiado.

Aplicando esta política de confianza al rol se logra el comportamiento esperado, el rol de servicio sólo puede ser usado por una única función lambda dentro de la cuenta de AWS.

English Version

During the design of a critical solution based on AWS Lambda, an unusual question arose: is it possible to guarantee that a service role can only be used by one specific function, even within the same AWS account?

In this article, I analyze this problem and present a solution based on trust policies that respects AWS Lambda's internal behavior, including scenarios with VPC configurations. I will break down the technical and architectural context that led to this requirement.

The Context

Within the organization, there is an enterprise architecture that defines a large number of AWS accounts per area and environment. Due to the massive size of the organization, many teams have access to deploy resources within the same account.

The Lambda function in question aims to perform various administrative operations; these operations run on a cross-cutting platform used throughout the organization, making it a critical and sensitive solution.

Administrative permissions on this platform are granted through the Lambda function's IAM service role. Since other teams can deploy resources in the same account, this privileged role could potentially be misused.

Let’s recall what a standard AWS Lambda service role trust policy looks like:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      }
  ]
}

This IAM role trust policy allows any Lambda function within the same AWS account to use it.

The First Attempt: Explicit Deny

How can we secure the role so it cannot be used by another function in the same account? My first thought was to add an additional statement to the trust policy to apply an explicit deny on the AssumeRole action for all AWS entities except the authorized one. I used the ArnNotEquals operator within a condition to achieve this.

The expected result is to deny the role assumption for any entity—remembering that an explicit deny overrides any explicitly granted permission—except for the authorized Lambda function.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Sid": "ExplicitDenyForAllExceptAuthorizedLambda",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnNotEquals": {
          "aws:SourceArn": "arn:aws:lambda:REGION:ACCOUNT_ID:function:AUTHORIZED_LAMBDA_NAME"
        }
      }
    }
  ]
}

Once the role was deployed with this new trust policy, the Lambda function had no issues using the service role. Simultaneously, when any other Lambda function tried to deploy while associating this same service role, it triggered a deployment error due to a lack of permissions. In short, the expected behavior was achieved.

The VPC Challenge

Everything looked good so far, right? However, due to technical requirements of the platform the function interacts with, the Lambda had to be deployed with a VPC configuration to access the internal network.

As soon as the VPC configuration was added, a deployment error appeared regarding the lack of permissions to assume the role.

So, what happened? When you add a VPC configuration to a Lambda function, the service executes several underlying actions. These actions must use the Lambda's service role to create Elastic Network Interfaces (ENIs), assign IPs, and perform other management tasks. These actions are performed by AWS-managed resources included in the service definition: "Service": "lambda.amazonaws.com".

The problem was that the statement applying the deny only excluded the specific Lambda function ARN. The role also needs to be usable by the additional VPC-related resources associated with the AWS Lambda service.

While researching how to adjust the condition, I looked into the hierarchy of logical operators in composite IAM conditions. It turns out that when using multiple operators (such as ArnLike and ArnNotEquals) within the same condition block, IAM applies a logical AND between them.

ArnLike(value) AND ArnNotEquals(value)

The Final Solution

Based on this premise, I constructed a condition that restricts the role to a single Lambda function while still allowing the service to perform its background operations.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Sid": "DenyAllOtherLambdasExceptAuthorizedOne",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnLike": {
          "aws:PrincipalArn": "arn:aws:lambda:*:*:function:*"
        },
        "ArnNotEquals": {
          "aws:PrincipalArn": "arn:aws:lambda:<REGION>:<ACCOUNT_ID>:function:<AUTHORIZED_LAMBDA_NAME>"
        }
      }
    }
  ]
}

Breaking down this policy:

The Allow statement: Standard for an AWS Lambda service role.

The Deny statement: This correctly solves the requirement. Since we use two operators, both must be true for the denial to trigger:
- ArnLike: First, it validates if the entity attempting to use the role matches a Lambda function ARN pattern. This prevents the role from becoming unusable when background VPC-related processes (which don't match this specific ARN pattern) need to act.
- ArnNotEquals: It then checks if the Lambda function using the role is not the authorized one.

By applying this trust policy, the service role is successfully locked down to a single Lambda function within the AWS account, even when using VPC configurations.