Deploy del Connector en AWS

Deploy del Connector

El connector es el componente que hace el puente entre el plano de control de Apono (SaaS) y los recursos de tu infraestructura. Puede desplegarse de diferentes formas, dependiendo del ambiente:

Ambiente	Método de Deploy
Kubernetes	Helm chart o manifiesto YAML
AWS	EC2, ECS o Fargate
Azure	Container Instance o AKS
GCP	GKE o Cloud Run
On-premise	Contenedor Docker

Requisitos

La configuración básica del connector exige solamente:

1. Token de autenticación: Generado en el dashboard de Apono para vincular el connector a la cuenta.
2. Credenciales locales: IAM role (AWS), managed identity (Azure) o service account (GCP) con permisos para gestionar accesos en los recursos deseados.
3. Acceso de salida (outbound): Conectividad HTTPS con el plano de control de Apono.

La arquitectura de connector con comunicación outbound es un patrón ampliamente adoptado en herramientas SaaS que necesitan interactuar con infraestructuras privadas. Este modelo evita la exposición de recursos internos mientras mantiene la conveniencia de una solución gestionada.

Comunicación y Seguridad de Red

El connector nunca recibe conexiones de entrada. Toda la comunicación es iniciada por el connector en dirección al Apono Cloud (outbound). Esto significa que:

• No es necesario abrir puertos de entrada en el firewall o security groups.
• El connector puede ejecutarse en subnets privadas sin acceso directo a internet.
• Basta garantizar acceso HTTPS (puerto 443) de salida para los endpoints de Apono.

Permisos Necesarios

El connector necesita permisos para gestionar accesos en los recursos que controla. Los permisos varían según el proveedor:

• AWS: IAM role con permisos para iam:AttachRolePolicy, iam:DetachRolePolicy, iam:AddUserToGroup, iam:RemoveUserFromGroup y similares, según los recursos gestionados.
• Azure: Managed identity con permisos de User Access Administrator o Role Based Access Control Administrator en los scopes deseados.
• GCP: Service account con permisos de roles/iam.securityAdmin o equivalente en los proyectos gestionados.
• Kubernetes: Service account con permisos para crear y eliminar RoleBindings y ClusterRoleBindings.
• Bases de datos: Credenciales con permiso para crear y revocar usuarios o conceder/eliminar grants.

El principio del menor privilegio se aplica al propio connector: debe tener solo los permisos necesarios para gestionar accesos en los recursos configurados, y nada más allá de eso.

Deploy en AWS

Apono ofrece templates listos de CloudFormation y módulos Terraform oficiales para deploy en AWS. No es necesario montar la infraestructura manualmente — el propio Apono proporciona el paso a paso directamente en el dashboard, con stacks que crean automáticamente todos los recursos necesarios.

El connector se ejecuta como un servicio ECS en Fargate, y el proceso de deploy crea automáticamente:

• Cross Account Role con permisos de lectura para descubrimiento de recursos.
• SNS para notificaciones entre el connector y el plano de control.
• ECS Task en Fargate que ejecuta el connector dentro de la VPC informada.

Prerrequisitos

• Permisos de administrador en la cuenta AWS de destino.
• Una VPC con conectividad de salida (outbound).
• Al menos una subnet dentro de la VPC.
• Para deploy a nivel de Organization: ID de la Organization (o-k012345a67) e ID de la Organization Unit Root (r-1a2b).

Escenarios de Deploy

Apono soporta tres escenarios para AWS:

Escenario	Descripción
Cuenta única	Connector gestiona accesos en una cuenta AWS específica
Organization (Management Account)	Connector instalado en la management account, gestiona todas las cuentas de la Organization
Organization (Delegated)	Connector en una cuenta miembro con permisos delegados a la management account

Deploy vía CloudFormation (Recomendado)

Este deploy instala el connector en la management account — la cuenta raíz que administra la AWS Organization y, típicamente, donde el IAM Identity Center está configurado. Es a partir de esta cuenta que el connector puede asumir roles en las cuentas miembro y gestionar accesos en toda la Organization.

Si tu organización sigue el principio de no ejecutar workloads en la management account (una recomendación común de seguridad de AWS), existe la alternativa de hacer el deploy en una cuenta miembro con permisos delegados. En este modelo, el connector se ejecuta en una cuenta separada (ej: la cuenta de seguridad o de herramientas) y recibe permisos cross-account para actuar en la Organization. Consulta la sección Organization (Delegated Permissions) para el paso a paso de esta configuración.

El método más simple es a través del propio dashboard de Apono, que genera un enlace directo para CloudFormation con los parámetros ya completados.

En la práctica, cuando una organización llega al punto de adoptar Apono e invertir en una herramienta paga de gestión de accesos, es porque ya alcanzó un nivel de madurez y escala donde existen múltiples cuentas AWS. Si has seguido las buenas prácticas de AWS, probablemente ya utilizas AWS Organizations, IAM Identity Center y una estructura de cuentas separadas por ambiente (producción, staging, desarrollo, seguridad, etc.). Apono soporta el deploy para una cuenta única, según se describe en la documentación oficial, pero aquí nos enfocaremos en el escenario más común: la Organization completa.

Para organizaciones que utilizan AWS Organizations y quieren gestionar accesos en todas las cuentas de forma centralizada:

1. Acceda al dashboard de Apono (app.apono.io).
2. Navegue hasta Integrations → Catalog.
3. Seleccione AWS en el catálogo de integraciones.
4. Elija el tipo de deploy Organization.
5. Seleccione los tipos de recursos que Apono debe descubrir y gestionar en su Organization (ej: IAM roles, RDS, S3, EC2, EKS, etc.). Esta selección define el alcance del discovery — qué recursos el connector identificará automáticamente en las cuentas de la Organization.
6. Informe el Organization ID y el alcance de cuentas que Apono debe gestionar. Es posible definir el alcance en diferentes niveles:
   • Organization Unit Root (r-1a2b): El connector escanea todas las cuentas de la Organization. Es el escenario más común y recomendado para quienes quieren visibilidad y control total.
   • Organization Unit específica (ou-1a2b-c3d4e5f6): El connector actúa solo en las cuentas que pertenecen a esa OU. Útil para limitar el alcance a un ambiente específico (ej: solo cuentas de producción, solo cuentas de un equipo).
   • Cuenta específica: El connector gestiona accesos en una única cuenta. Puede usarse en un piloto inicial antes de expandir a toda la Organization.
7. Seleccione el nivel de permiso deseado:
   • Full-Access (Manage IAM): El connector tendrá permisos para descubrir recursos y gestionar accesos — es decir, crear y eliminar policies, agregar y eliminar usuarios de grupos, conceder y revocar roles. Este es el modo necesario para que Apono funcione como herramienta de JIT Access, y es lo que usarás en la mayoría de los casos.
   • Read-Only: El connector tendrá permisos solo para descubrir recursos en las cuentas de la Organization, sin capacidad de alterar permisos. Este modo es útil en un enfoque de adopción gradual — primero conectas Apono para visualizar qué recursos existen en tu ambiente, validas el alcance del discovery y después actualizas el connector a Full-Access cuando estés listo para gestionar accesos de hecho.
8. Seleccione CloudFormation como método de instalación y haga clic en Open CloudFormation — será redirigido al console de AWS.
9. En el console de AWS, seleccione la VPC y al menos una subnet, marque el checkbox de acknowledgment para creación de recursos IAM y haga clic en Create Stack.
10. El stack será instalado en la management account (que gestiona el Identity Center de la organización).
11. Espere a que el stack se complete y vuelva al dashboard de Apono — el connector debería aparecer con status Connected (indicación verde).

Verifique que el trusted access esté activado para CloudFormation StackSets en su Organization. Sin esto, el stack no puede propagar los permisos a las cuentas miembro.

Después de que el stack se complete, CloudFormation genera dos valores importantes en las pestañas Outputs y Parameters:

• AponoConnectorRoleArn (Outputs): El ARN del IAM role creado para el connector. Este role es lo que permite al connector asumir permisos en las cuentas de la Organization para hacer discovery y gestionar accesos.
• AponoConnectorId (Parameters): El identificador único del connector en Apono Cloud.

Para el escenario de Organization con Management Account (el que acabamos de configurar), estos valores se generan automáticamente y no necesitan acción adicional — el connector ya está funcional. Sin embargo, guarde estos valores. Son necesarios en los siguientes casos:

• Delegated Permissions: Si en el futuro decides mover el connector a una cuenta miembro en lugar de la management account, necesitarás el AponoConnectorRoleArn y el AponoConnectorId para crear el stack de delegación en la management account (detallado en la sección Organization (Delegated Permissions)).
• Troubleshooting de permisos: Si el connector no puede acceder a recursos en alguna cuenta, el AponoConnectorRoleArn ayuda a diagnosticar problemas de trust policy o permisos insuficientes en el cross-account role.
• Integración con IaC existente: Si gestionas tu infraestructura vía Terraform o CDK y necesitas referenciar el role del connector en otras configuraciones (ej: agregar permisos extras para recursos específicos), el ARN es el identificador necesario.

¿Un Connector o Varios?

Una duda común al planificar el deploy es: ¿vale la pena tener un único connector para toda la Organization o dividir en múltiples connectors?

En la mayoría de los casos, un único connector cubriendo toda la Organization es suficiente. Ya puede escanear todas las cuentas, hacer discovery de recursos y gestionar accesos de forma centralizada. Menos connectors significa menos infraestructura que mantener, menos tokens que gestionar y menos stacks que actualizar.

Sin embargo, existen escenarios donde múltiples connectors tienen sentido:

• Aislamiento de red: Si tu Organization tiene VPCs en regiones diferentes que no se comunican entre sí, cada connector necesita estar en una VPC con acceso de salida. Un connector en us-east-1 no puede gestionar recursos que exigen conectividad de red local en eu-west-1 (como bases de datos en subnets privadas).
• Segregación por ambiente: Organizaciones con requisitos rigurosos de cumplimiento pueden preferir connectors separados para producción y no-producción. Esto garantiza que un problema en el connector de dev/staging no impacte la gestión de accesos en producción.

Escenario	Recomendación
Organization pequeña/mediana, una región principal	Un único connector
Organization multi-región con VPCs aisladas	Un connector por región con recursos de red local
Requisitos de cumplimiento con segregación prod/no-prod	Un connector por ambiente

En caso de duda, comienza con un único connector para toda la Organization. Apono permite agregar connectors adicionales en cualquier momento sin impactar los ya existentes. Escala según la necesidad real — no anticipes complejidad.

Qué Hace el Connector en la Práctica

Después del deploy y la conexión con Apono Cloud, el connector pasa a ejecutar continuamente las siguientes funciones:

• Descubrimiento de recursos: El connector escanea las cuentas de la Organization e identifica automáticamente los recursos disponibles — instancias EC2, bases RDS, buckets S3, clústeres EKS, roles IAM, entre otros. Estos recursos aparecen en el catálogo de Apono y quedan disponibles para configuración de Access Flows. El discovery es continuo: cuando nuevos recursos se crean en AWS, el connector los detecta y actualiza el catálogo automáticamente.
• Aprovisionamiento de accesos: Cuando una solicitud de acceso es aprobada (manual o automáticamente), el connector recibe la instrucción de Apono Cloud y ejecuta la acción en la infraestructura — por ejemplo, agregar un usuario a un grupo IAM, anexar una policy a un role, crear credenciales temporales para una base de datos, o crear un RoleBinding en Kubernetes.
• Revocación automática de accesos: Cuando el tiempo del acceso expira, el connector recibe la instrucción de revocación y elimina el permiso — desanexa la policy, elimina el usuario del grupo, revoca las credenciales de la base. Esta revocación es automática y no depende de intervención humana.
• Polling continuo: El connector no recibe conexiones de entrada. Hace polling periódico a Apono Cloud para verificar si existen acciones pendientes (concesiones o revocaciones). Este modelo garantiza que el connector funcione en subnets privadas sin exposición a internet.
• Reporte de estado: El connector reporta su estado de salud a Apono Cloud. Si el connector se desconecta o tiene problemas de conectividad, el dashboard muestra el status Disconnected, alertando al equipo.

El connector es stateless — no almacena estado localmente. Toda la lógica de decisión (quién puede acceder a qué, por cuánto tiempo, quién aprueba) reside en Apono Cloud. El connector solo ejecuta las acciones en la infraestructura. Esto significa que, si el connector es sustituido o recreado, basta generar un nuevo token y hacer el deploy nuevamente — no hay datos locales que migrar.

Organization (Delegated Permissions)

Para organizaciones que no quieren instalar el connector directamente en la management account, Apono soporta un modelo de permisos delegados — donde el connector se ejecuta en una cuenta miembro, pero recibe permisos para gestionar accesos en toda la Organization. Este modelo es común en organizaciones que restringen workloads en la management account por cuestiones de seguridad.

El proceso involucra dos stacks CloudFormation: uno en la cuenta miembro (donde el connector se ejecuta) y otro en la management account (que delega los permisos).

Paso 1 — Deploy del connector en la cuenta miembro:

1. En el dashboard de Apono, siga los mismos pasos del deploy Organization, pero sin marcar la opción "Install and Connect AWS Account".
2. Después de que el stack se complete en la cuenta miembro, copie dos valores:
   • AponoConnectorId (pestaña Parameters del stack)
   • AponoConnectorRoleArn (pestaña Outputs del stack)

Paso 2 — Delegación de permisos en la management account:

1. Abra el CloudFormation en la management account. Apono proporciona un enlace directo para la página de creación rápida de stack.

2. En Parameters, complete los siguientes campos:

   • AponoConnectorId: El valor copiado en el paso anterior.
   • ConnectorRoleArn: El ARN copiado en el paso anterior.
   • OrganizationId: El ID de la Organization (o-k012345a67).
   • OrganizationUnitId: El ID de la OU root (r-1a2b) o de la OU específica que desea gestionar.

3. En el menú Permissions, seleccione Full-Access (Manage IAM).

4. En Resources, marque el checkbox "Confirmo que AWS CloudFormation puede crear recursos de IAM con nombres personalizados".

5. Haga clic en Create Stack.

6. (Opcional) En la pestaña Outputs, copie el valor de ManagementAccountRoleArnOutput — este ARN puede ser útil para referencia futura o integración con otras herramientas de IaC.

Después de que ambos stacks se completen, el connector en la cuenta miembro tendrá permisos delegados por la management account para gestionar accesos en toda la Organization. El status en el dashboard de Apono debería cambiar a Connected.

La principal ventaja del modelo delegado es que la management account no ejecuta ningún workload — solo concede los permisos necesarios al connector vía cross-account role. Esto sigue la recomendación de AWS de mantener la management account limpia y restringida.

Qué Crea CloudFormation en Tu Cuenta

Después del deploy, es importante entender qué recursos IAM creó CloudFormation y cuál es el papel de cada uno. Esto facilita troubleshooting, auditorías de seguridad y revisiones de permisos.

Roles en las Cuentas Miembro (Todas las Cuentas de la Organization)

En cada cuenta miembro de la Organization, el StackSet crea un role cross-account con el nombre:

apono-cross-account-role-AwsIntegrationConnector-xxx

Este role es lo que permite al connector acceder a los recursos de cada cuenta remotamente. Contiene:

• Permisos de lectura para los tipos de recursos seleccionados durante el deploy (EC2, RDS, S3, EKS, IAM, etc.) — usados para el discovery.
• Permisos de escritura (si Full-Access fue seleccionado) para gestionar accesos — como iam:AttachRolePolicy, iam:AddUserToGroup, etc.
• Trust policy que permite al role del connector en la management account (o en la cuenta delegada) asumir este role vía sts:AssumeRole.

Si agregas nuevas cuentas a la Organization posteriormente, el StackSet propaga automáticamente este role a las nuevas cuentas — siempre que el trusted access para CloudFormation StackSets esté activo.

Roles en la Cuenta de Gestión (Management Account)

En la management account, CloudFormation crea dos roles principales:

Role	Service Principal	Función
apono-connector-role-xxxxxxxx-xxxx-...	ecs-tasks.amazonaws.com	Role asumido por la ECS Task de Fargate que ejecuta el connector. Es la identidad del connector dentro de AWS — permite que haga sts:AssumeRole en los cross-account roles de las cuentas miembro.
apono-oidc-role-xxxxxxxx-xxxx-...	lambda.amazonaws.com	Role usado por una función Lambda auxiliar que Apono utiliza para operaciones de autenticación OIDC y validación de tokens entre el connector y Apono Cloud.

El role del connector (apono-connector-role) es el más importante — es la "identidad" del connector en AWS. Cuando el connector necesita hacer discovery o gestionar accesos en una cuenta miembro, usa este role para asumir el cross-account role de esa cuenta vía sts:AssumeRole. La cadena de confianza funciona así:

Nunca modifiques o elimines estos roles manualmente. Si necesitas actualizar permisos, usa el proceso de actualización del stack CloudFormation para garantizar consistencia. Cambios manuales pueden romper la cadena de trust y desconectar el connector.

La Función Lambda (OIDC)

El apono-oidc-role está asociado a una función Lambda que CloudFormation también crea en la management account. Esta Lambda es responsable de establecer la autenticación entre el connector y Apono Cloud usando el protocolo OIDC (OpenID Connect).

En la práctica, el problema que resuelve es: ¿cómo el connector prueba su identidad ante Apono Cloud de forma segura, sin almacenar credenciales estáticas (como API keys o secrets) en el ambiente del cliente?

La respuesta es vía tokens OIDC de corta duración. El flujo funciona así:

1. El connector necesita autenticarse con Apono Cloud para hacer polling de acciones pendientes.
2. La Lambda actúa como un token endpoint — genera tokens OIDC firmados que identifican al connector.
3. El connector presenta ese token a Apono Cloud, que valida la firma y confirma la identidad.
4. El token tiene vida corta — si es comprometido, expira rápidamente y no puede reutilizarse.

Este modelo sigue el patrón de IAM OIDC Federation de AWS — en lugar de intercambiar credenciales estáticas entre el connector y el SaaS, toda la autenticación se basa en tokens temporales. Es el mismo principio usado por GitHub Actions y GitLab CI para autenticarse con AWS sin almacenar access keys.

La Lambda OIDC es un componente interno de Apono y no requiere configuración o mantenimiento manual. Es creada y gestionada automáticamente por el stack CloudFormation. No necesitas invocarla directamente — el connector la utiliza de forma transparente.

Recursos ECS (El Connector en Sí)

Además de los roles IAM y la Lambda, CloudFormation crea toda la infraestructura necesaria para ejecutar el connector como un servicio gestionado en ECS Fargate:

Recurso	Función
ECS Cluster	Clúster dedicado para el connector. Ejecuta exclusivamente la task de Apono — no comparte recursos con otros servicios.
ECS Task Definition	Define el contenedor del connector: imagen Docker de Apono, variables de ambiente (token, connector ID), límites de CPU/memoria y el IAM role asociado (apono-connector-role).
ECS Service	Garantiza que la task esté siempre ejecutándose. Si el contenedor falla o es terminado, ECS reinicia automáticamente una nueva instancia.
Security Group	Controla el tráfico de red de la task. Permite solo tráfico de salida (outbound) — el connector no recibe conexiones de entrada, solo hace polling a Apono Cloud.
CloudWatch Log Group	Almacena los logs del contenedor del connector. Útil para troubleshooting cuando el connector presenta problemas de conectividad o errores de permisos.

El connector se ejecuta en Fargate — lo que significa que no hay instancias EC2 que gestionar. AWS se encarga de la infraestructura computacional, y pagas solo por el tiempo de ejecución del contenedor. Como el connector es ligero (bajo consumo de CPU y memoria), el costo operacional es mínimo.

La task se despliega en la VPC y subnet que seleccionaste durante el deploy. El único requisito de red es que la subnet tenga acceso de salida a internet (vía NAT Gateway o Internet Gateway) para que el connector pueda comunicarse con Apono Cloud. No es necesario abrir ningún puerto de entrada.

Si necesitas verificar los logs del connector, accede a CloudWatch en la cuenta donde el stack fue creado y busca el log group con prefijo apono. Los logs muestran eventos de discovery, polling, concesión y revocación de accesos — y son el primer lugar para investigar cuando algo no funciona como se esperaba.

Deploy vía Terraform

Documentación Oficial Terraform

Si deseas mantener todo este deploy vía Terraform es posible utilizando el enlace anterior. En realidad aplica un CloudFormation vía Terraform.

Usaremos Terraform más adelante, pero no para el conector, sino para definir nuestros flows. Apono ofrece un provider para Terraform que exploraremos más adelante.

Deploy vía EKS

Para organizaciones que prefieren ejecutar el connector en Kubernetes en lugar de ECS, Apono también ofrece un template CloudFormation específico para EKS. El flujo es similar al de ECS — seleccionando la opción EKS en el dashboard de Apono durante la configuración, pero no veo muchas ventajas en esto. En mi opinión es agregar más capas de control innecesarias para un elemento tan simple.

Actualizando el Connector

Para actualizar un connector ya desplegado, Apono proporciona un template actualizado que puede aplicarse sobre el stack existente:

# Actualizar el stack CloudFormation con el template más reciente
aws cloudformation update-stack \
  --stack-name apono-connector \
  --template-url <url-del-template-actualizado> \
  --parameters \
    ParameterKey=VpcId,UsePreviousValue=true \
    ParameterKey=SubnetIds,UsePreviousValue=true \
    ParameterKey=AponoToken,UsePreviousValue=true \
  --capabilities CAPABILITY_NAMED_IAM

Después de la actualización, verifica en la pestaña Stack Info de CloudFormation si el status cambió a UPDATE_COMPLETE.

Verificando el Deploy

Después del deploy, verifica que el connector está funcionando:

1. En el dashboard de Apono, navega hasta Integration en la pestaña connectors.
2. El connector debería aparecer con status Connected (indicación verde).
3. Si el status es Disconnected, verifica:
   • El stack de CloudFormation se completó sin errores.
   • La subnet tiene acceso de salida a internet (NAT Gateway o Internet Gateway).
   • El token es correcto y no ha expirado.

Después de la conexión exitosa, puedes crear Access Flows para recursos AWS como IAM roles, RDS, S3, EC2 (vía SSM) y otros. Cada recurso adicional puede conectarse individualmente a través del catálogo de integraciones de Apono.