AWS FIS: Cómo Escalar de Forma Segura con SCPs en tu organización
Aprende a escalar AWS Fault Injection Service (FIS) de forma segura en tu organización. Usa Service Control Policies (SCPs) como controles de cuenta para habilitar la ingeniería del caos a escala, superando restricciones comunes.
AWS Fault Injection Service y la ingeniería del caos
En el entorno cloud actual, la resiliencia no es un lujo, sino una necesidad fundamental para garantizar la continuidad del negocio y la satisfacción del cliente.
AWS Fault Injection Service (FIS) emerge como una herramienta clave, permitiéndote adoptar la ingeniería del caos —una disciplina esencial para validar proactivamente la robustez de tus sistemas—. Mediante la inyección controlada y realista de fallos (como simular la pérdida de conectividad de red, la terminación de instancias EC2, o la latencia inducida en APIs), FIS te ayuda a descubrir debilidades ocultas antes de que causen impacto en producción. Este enfoque proactivo no solo mejora la fiabilidad técnica, sino que reduce el tiempo medio de recuperación (MTTR), minimiza el impacto financiero de las interrupciones y aumenta la confianza de los equipos en la capacidad de sus aplicaciones para soportar condiciones adversas.
Con los experimentos de AWS FIS, puedes simular eventos disruptivos específicos, como un corte de energía en una Availability Zone (AZ) o una interrupción regional de conectividad, para observar, medir y mejorar la respuesta de tu aplicación.
FIS en Modelos de Red Centralizados
Sin embargo, escalar la ingeniería del caos, especialmente las pruebas que involucran la red, presenta desafíos en organizaciones con modelos operativos maduros. Un patrón común es el modelo de red centralizada, donde un equipo dedicado gestiona la infraestructura de red (VPCs, subredes, tablas de rutas, Network ACLs – NACLs) en cuentas específicas (p.ej., una cuenta de «Network Services»). Este modelo ofrece ventajas en consistencia, seguridad y gestión, pero puede crear un cuello de botella para los equipos de aplicación que necesitan ejecutar experimentos de FIS que interactúan con recursos de red.
Por ejemplo, al ejecutar acciones de fallo de red como aws:network:disrupt-connectivity (que simula la pérdida de conectividad entre subredes o AZs), FIS necesita permisos temporales para modificar recursos de red, típicamente añadiendo o eliminando reglas en las NACLs (requiriendo permisos como ec2:CreateNetworkAcl, ec2:CreateNetworkAclEntry, ec2:DeleteNetworkAclEntry, ec2:DeleteNetworkAcl). En un modelo centralizado, los roles IAM asumidos por los equipos de aplicación normalmente carecen de estos permisos, impidiendo la ejecución de dichos experimentos y limitando la capacidad de validar la resiliencia de la red de forma distribuida.
Barandillas de Seguridad con AWS Organizations y SCPs
Abordaremos cómo superar este desafío definiendo barandillas de seguridad robustas mediante una combinación estratégica de Service Control Policies (SCPs) en AWS Organizations y permisos detallados de AWS Identity and Access Management (IAM). Esto permitirá a tus equipos de aplicación ejecutar experimentos de FIS de forma controlada y segura, sin comprometer la integridad de la red centralizada, ya sea en una sola cuenta, en múltiples cuentas o en varias regiones. Esta primera parte se centra en establecer las bases con SCPs para habilitar acciones de red específicas dentro de un entorno controlado.
AWS Organizations es fundamental para gestionar múltiples cuentas de AWS de forma centralizada. Te permite agrupar cuentas en Unidades Organizativas (OUs) y aplicar políticas de gobernanza. Las Service Control Policies (SCPs) son un tipo clave de política de Organization que define los permisos máximos disponibles para las entidades IAM (usuarios y roles) dentro de las cuentas afectadas. Es crucial entender que las SCPs no conceden permisos por sí solas; actúan como filtros o barandillas. Los permisos efectivos de una entidad IAM son la intersección de lo permitido por las SCPs y lo concedido por sus políticas IAM (basadas en identidad o recursos).
1. Preparación Esencial para los Experimentos de AWS FIS
Antes de inyectar fallos, es vital una preparación cuidadosa:
- Plantillas de Experimento: Los experimentos se definen mediante plantillas reutilizables que especifican las acciones de fallo, los objetivos (recursos a afectar) y las condiciones de parada.
- Seguridad Integrada: La seguridad debe ser primordial. FIS incluye mecanismos intrínsecos como:
- Palancas de Seguridad (Stop Conditions): Condiciones, a menudo basadas en alarmas de Amazon CloudWatch, que detienen automáticamente el experimento si se superan umbrales predefinidos (p.ej., latencia excesiva, tasa de errores alta), limitando el impacto negativo.
- Rol IAM del Experimento: Cada experimento debe ejecutarse asumiendo un rol IAM específico. Este rol debe tener los permisos mínimos necesarios únicamente para ejecutar las acciones de fallo definidas en la plantilla y para interactuar con los servicios de monitorización (como CloudWatch).
Para escalar eficazmente, recomendamos estandarizar los roles IAM utilizados, separando las responsabilidades de creación de plantillas y ejecución de experimentos.
2. Estandarización del Acceso a AWS FIS: Roles y Responsabilidades
Utilizaremos los siguientes perfiles (como se ilustra en el Diagrama A):
- Account Admin (Administrador de la Organización): Responsable de la estructura de OUs y de la creación y asignación de SCPs a nivel de OU o raíz. Define las barandillas generales.
- IAM Admin (Administrador de IAM en Cuentas Miembro): Responsable de crear y gestionar roles y políticas IAM dentro de las cuentas individuales, siempre dentro de los límites establecidos por las SCPs aplicables.
3. Flujo de Configuración:
- Account Admin: Crea SCPs específicas. Una podría habilitar el servicio FIS (
fis:*) solo en OUs designadas (p.ej., OU de Workloads, OU de Sandbox) donde se permite la experimentación. Otra SCP, más específica (como la que detallaremos), controlará los permisos sensibles (p.ej., acciones de red EC2). Estas SCPs se aplican a las OUs apropiadas. - IAM Admin: Dentro de las cuentas miembro bajo las OUs permitidas, crea los roles IAM estandarizados. Estos roles pueden usar políticas gestionadas por AWS para FIS (como
AWSFaultInjectionServiceExperimentRolePolicy) o políticas personalizadas más restrictivas. En esta serie, nos referiremos a dos roles conceptuales clave:AWS-FIS-Experiment-Orchestrator: Rol destinado a ser asumido por usuarios o pipelines de CI/CD para definir y gestionar plantillas de experimento (crear, leer, actualizar, eliminar). No debe tener permisos para ejecutar las acciones de fallo en sí. (Detalles en Parte 2).AWS-FIS-Experiment-Executor: Rol que se asigna directamente a la plantilla de experimento FIS y es asumido únicamente por el servicio FIS durante la ejecución. Este rol contendrá los permisos necesarios para realizar las acciones de fallo sobre los recursos objetivo (p.ej., modificar NACLs, detener instancias EC2). Nunca debe ser asumido directamente por usuarios o roles de usuario.
4. SCPs como Barandillas para el Rol Ejecutor
Las SCPs actúan como la barandilla de seguridad fundamental. Evitan que el rol AWS-FIS-Experiment-Executor, aunque tenga permisos IAM potencialmente amplios para realizar las acciones de fallo, sea utilizado indebidamente fuera del contexto de un experimento FIS controlado. La SCP que implementaremos más adelante limita específicamente las acciones de red sensibles para que solo puedan ser ejecutadas cuando el principal (quien realiza la acción) sea precisamente este rol AWS-FIS-Experiment-Executor. Dado que este rol solo debe ser asumible por el servicio FIS (fis.amazonaws.com), se crea una cadena de confianza segura.
5. Escenario del Mundo Real
Habilitando aws:network:disrupt-connectivity consideraremos el modelo de red centralizada. Un desarrollador en una cuenta de aplicación (dentro de la OU de Workloads) quiere probar cómo responde su aplicación a una interrupción de conectividad entre AZs usando la acción aws:network:disrupt-connectivity de FIS. Sin la configuración adecuada, la llamada de FIS fallará porque el rol AWS-FIS-Experiment-Executor (asumido por FIS) no tendrá permiso para modificar las NACLs gestionadas centralmente, o las SCPs podrían bloquear la acción.
6. Implementación de la SCP
El Account Admin debe crear y aplicar la siguiente SCP a la OU que contiene las cuentas donde se ejecutarán estos experimentos de red (p.ej., OU de Workloads). Esta política utiliza un Deny explícito con una condición ArnNotEquals sobre aws:PrincipalArn. Esto significa: «Deniega estas acciones de red sensibles a cualquier principal (usuario o rol) excepto si es el rol AWS-FIS-Experiment-Executor«. Esta es una práctica de seguridad robusta, asegurando que solo el rol designado, y por extensión, solo el servicio FIS actuando a través de ese rol, pueda realizar estas modificaciones.
{
«Version»: «2012-10-17»,
«Statement»: [
{
«Sid»: «AllowFISNetworkActionsOnlyViaExecutorRole»,
«Effect»: «Deny»,
«Action»: [
«ec2:CreateNetworkAcl»,
«ec2:CreateNetworkAclEntry»,
«ec2:DeleteNetworkAcl»,
«ec2:DeleteNetworkAclEntry», // Añadido para completar el ciclo de vida
«ec2:ReplaceNetworkAclEntry», // Añadido para modificaciones
«ec2:CreateTags», // A menudo necesario para etiquetar recursos temporales creados por FIS
«ec2:DeleteTags», // Limpiar etiquetas
«ec2:DescribeNetworkAcls»,
«ec2:DescribeManagedPrefixLists», // Relevante si se usan Prefix Lists
«ec2:DescribeSubnets»,
«ec2:DescribeVpcs»,
«ec2:ReplaceNetworkAclAssociation»,
«ec2:GetManagedPrefixListEntries» // Relevante si se usan Prefix Lists
],
«Resource»: «*», // Se aplica a todos los recursos, la restricción está en quién puede hacerlo
«Condition»: {
«ArnNotEquals»: {
// Solo permite que el rol Executor realice estas acciones
«aws:PrincipalArn»: [
«arn:aws:iam::*:role/AWS-FIS-Experiment-Executor»
// Puedes añadir otros ARNs de roles de confianza si es estrictamente necesario,
// pero para este caso de uso, limitarlo al Executor es lo ideal.
]
}
// Considera añadir condiciones adicionales si es necesario, como restringir
// por OU de origen o etiquetas específicas, aunque puede complicar la gestión.
}
}
]
}
7. Implementa el Rol Ejecutor
El IAM Admin en cada cuenta miembro relevante (o mediante un despliegue centralizado de roles con StackSets) debe crear el rol AWS-FIS-Experiment-Executor.
Política de Confianza (Trust Policy): Es crucial que este rol solo pueda ser asumido por el servicio FIS.
{
«Version»: «2012-10-17»,
«Statement»: [
{
«Effect»: «Allow»,
«Principal»: {
«Service»: «fis.amazonaws.com»
},
«Action»: «sts:AssumeRole»,
«Condition»: {
// Opcional pero recomendado: Restringir a la cuenta actual
«ArnEquals»: {
«aws:SourceArn»: «arn:aws:fis:*:*:experiment/*»
},
«StringEquals»: {
«aws:SourceAccount»: «${AWS::AccountId}»
}
}
}
]
}
Política de Permisos (Permissions Policy): Esta política debe conceder los permisos necesarios para las acciones de FIS que se ejecutarán usando este rol. Para el ejemplo de aws:network:disrupt-connectivity, necesitaría los permisos ec2:*NetworkAcl*, ec2:Describe*, etc., listados en la SCP. Se puede usar la política gestionada AWSFaultInjectionServiceEC2NetworkAccess o una política personalizada más restrictiva si se conocen exactamente los recursos objetivo.
Próximos pasos
Implementando estos roles estandarizados y SCPs, las organizaciones crean un marco seguro y auditable para la ingeniería del caos. Las SCPs garantizan que las acciones potencialmente disruptivas (como modificar NACLs) solo puedan ser realizadas por el servicio FIS a través de un rol específico y autorizado, previniendo modificaciones accidentales o maliciosas. Visita nuestro repositorio de GitHub para obtener plantillas de CloudFormation o Terraform y ejemplos de políticas más detallados.
Una vez que la SCP está activa y el rol AWS-FIS-Experiment-Executor está correctamente implementado en una cuenta miembro, los propietarios de aplicaciones (o sus pipelines) pueden, asumiendo el rol AWS-FIS-Experiment-Orchestrator (que se detallará en la Parte 2), crear y ejecutar plantillas de experimento que utilicen la acción aws:network:disrupt-connectivity designando el rol AWS-FIS-Experiment-Executor para la ejecución. FIS se encargará de asumir este rol y realizar las modificaciones temporales en las NACLs de forma segura.