Aprovisionamiento de roles de IAM con privilegio mínimo mediante la implementación de una solución de máquina expendedora de roles - Recomendaciones de AWS
ResumenRequisitos previos y limitacionesArquitecturaTools (Herramientas)Prácticas recomendadasEpicsResolución de problemasRecursos relacionadosInformación adicional

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Aprovisionamiento de roles de IAM con privilegio mínimo mediante la implementación de una solución de máquina expendedora de roles

Benjamin Morris, Nima Fotouhi, Aman Kaur Gandhi y Chad Moon, Amazon Web Services

Resumen

Los permisos excesivos en los roles de AWS Identity and Access Management (IAM) para las canalizaciones pueden suponer un riesgo innecesario para la organización. A veces, los desarrolladores conceden permisos amplios durante el desarrollo, pero se olvidan de limitarlos después de solucionar problemas con el código. Esto provoca un problema, pues puede que haya roles importantes sin necesidad empresarial y que posiblemente no haya revisado un ingeniero de seguridad.

Este patrón ofrece una solución a este problema: la máquina expendedora de roles (RVM). Mediante un modelo de implementación seguro y centralizado, el RVM demuestra cómo aprovisionar las funciones de IAM con menos privilegios para las canalizaciones de los repositorios individuales con un esfuerzo mínimo por parte de los desarrolladores. GitHub Como la RVM es una solución central, puede configurar sus equipos de seguridad como revisores necesarios para aprobar los cambios. Este enfoque permite al personal de seguridad rechazar las solicitudes de roles de canalizaciones con un exceso de permisos.

La RVM obtiene el código de Terraform como entrada y genera roles de IAM listos para su uso como salida. Las entradas obligatorias son el Cuenta de AWS ID, el nombre del repositorio y la política de permisos. GitHub La RVM usa estas entradas para crear la política de confianza y la política de permisos del rol. La política de confianza resultante permite que el GitHub repositorio especificado asuma la función y la utilice para las operaciones de canalización.

La RVM usa un rol de IAM (configurado durante el arranque). Este rol tiene permisos para asumir un rol role-provisioning-role en cada cuenta de la organización. El rol se configura mediante AWS Control Tower Account Factory for Terraform (AFT) o AWS CloudFormation StackSets. Estas role-provisioning-roles son las funciones que realmente crean las funciones de canalización para los desarrolladores.

Requisitos previos y limitaciones

Requisitos previos 

  • Un activo Cuenta de AWS.

  • Una GitHub organización que se utiliza para implementar la infraestructura como código (IaC) mediante GitHub acciones. (no GitHub Enterprise/Premium/Ultimate son obligatorios).

  • Un AWS entorno con varias cuentas. No es necesario que este entorno forme parte de AWS Organizations.

  • Un mecanismo para implementar una función de IAM en todos Cuentas de AWS (por ejemplo, AFT o CloudFormation StackSets).

  • La versión 1.3 o posterior de Terraform instalada y configurada.

  • Instalación y configuración de Terraform AWS Provider, versión 4 o posterior.

Limitaciones

  • El código de este patrón es específico de GitHub Actions y Terraform. Sin embargo, los conceptos generales del patrón se pueden reutilizar en otros marcos de integración y entrega continuas (CI/CD).

  • Algunos Servicios de AWS no están disponibles en todos Regiones de AWS. Para obtener información sobre la disponibilidad en regiones, consulte AWS Services by Region. Para ver los puntos de conexión específicos, consulte Service endpoints and quotas y elija el enlace del servicio.

Arquitectura

En el siguiente diagrama, se ilustra el flujo de trabajo de este patrón.

Flujo de trabajo para automatizar la creación y el despliegue de funciones de IAM mediante GitHub Actions.

El flujo de trabajo para el uso típico de la máquina expendedora de roles consta de los siguientes pasos:

  1. Un desarrollador envía el código que contiene el código de Terraform para un rol de IAM recién solicitado al repositorio de RVM. GitHub Esta acción activa la canalización de acciones de RVM. GitHub

  2. La canalización utiliza una política de confianza de OpenID Connect (OIDC) para asumir el rol de la RVM.

  3. Conforme se pone en marcha la canalización de la RVM, esta asume el rol de flujo de trabajo de la RVM en la cuenta en la que se aprovisiona el nuevo rol de IAM del desarrollador. (La función de flujo de trabajo de RVM se aprovisionó mediante AFT o.) CloudFormation StackSets

  4. La RVM crea el rol de IAM del desarrollador con la confianza y los permisos adecuados, de modo que otras canalizaciones de la aplicación puedan asumir el rol.

  5. Los desarrolladores de la aplicación pueden configurar las canalizaciones de la aplicación para que asuman este rol aprovisionado por RVM.

El rol creado incluye los permisos solicitados por el desarrollador y una política ReadOnlyAccess. El rol solo lo pueden asumir las canalizaciones que se ponen en marcha en la rama main del repositorio especificado por el desarrollador. Este enfoque permite garantizar que sea necesaria la protección y las revisiones de las ramas para poder utilizar el rol.

Automatización y escala

Los permisos con privilegio mínimo requieren prestar atención a los detalles de cada rol que se aprovisione. Este modelo reduce la complejidad necesaria para crear estos roles, lo que permite a los desarrolladores crear los roles que necesitan sin mucho aprendizaje o esfuerzo adicionales.

Tools (Herramientas)

Servicios de AWS

  • AWS Identity and Access Management (IAM) le ayuda a administrar de forma segura el acceso a sus AWS recursos al controlar quién está autenticado y autorizado a usarlos.

  • AWS Organizationses un servicio de administración de cuentas que le ayuda a consolidar múltiples cuentas Cuentas de AWS en una organización que usted crea y administra de forma centralizada.

Otras herramientas

  • Git es un sistema de control de versiones distribuido y de código abierto. Incluye la posibilidad de crear una cuenta de organización.

  • GitHub Actions es una plataforma de integración y entrega continuas (CI/CD) que está estrechamente integrada con GitHub los repositorios. Puedes usar GitHub Actions para automatizar tu proceso de creación, prueba e implementación.

  • Terraform es una herramienta de infraestructura como código (IaC) HashiCorp que te ayuda a crear y administrar recursos locales y en la nube.

Repositorio de código

El código de este patrón está disponible en el repositorio. GitHub role-vending-machine

Prácticas recomendadas

  • Haga que lo correcto sea fácil y que lo incorrecto sea difícil: procure que hacer lo correcto sea sencillo. Si los desarrolladores tienen dificultades con el proceso de aprovisionamiento de la RVM, podrían intentar crear roles por otros medios, lo que socavaría la naturaleza central de la RVM. Asegúrese de que su equipo de seguridad proporcione una guía clara sobre cómo utilizar la RVM de forma segura y eficaz.

    También debería impedir que los desarrolladores hagan cosas incorrectas. Usa las políticas de control de servicios (SCPs) o los límites de permisos para restringir qué roles pueden crear otros roles. Este enfoque puede ser útil para que solo la RVM y otros orígenes fiables puedan crear roles.

  • Brinde buenos ejemplos: es inevitable que algunos desarrolladores usen los roles existentes en el repositorio de la RVM como plantillas informales para conceder permisos a sus nuevos roles. Si tiene ejemplos de privilegio mínimo para los desarrolladores, puede reducir el riesgo de que soliciten permisos amplios y con muchos caracteres comodín. Si empieza con roles con muchos permisos y muchos comodines, el problema puede multiplicarse con el paso del tiempo.

  • Use condiciones y convenciones de nomenclatura: aunque un desarrollador no conozca todos los nombres de los recursos que va a crear su aplicación, debería limitar los permisos de los roles mediante una convención de nomenclatura. Por ejemplo, si el desarrollador está creando buckets de Amazon S3, el valor de la clave deñ recurso puede ser parecido a arn:aws:s3:::myorg-myapp-dev-* para que el rol no tenga permisos más allá de los buckets que coincidan con ese nombre. Implementar una convención de nomenclatura mediante una política de IAM tiene la ventaja adicional de mejorar el cumplimiento de la convención de nomenclatura. Esta mejora se debe a que no se permitirá la creación de recursos que no coincidan con dicha convención.

  • Exija revisiones mediante solicitudes de extracción (PR): el valor de la solución de RVM es que crea una ubicación central donde se pueden revisar los nuevos roles de canalización. Sin embargo, este diseño solo es útil si hay barreras de protección que permitan garantizar que la RVM reciba código seguro y de alta calidad. Proteja las ramas que se utilizan para implementar código (por ejemplo, main) de las inserciones directas y solicite la aprobación de cualquier solicitud para fusionarlas.

  • Configure los roles de solo lectura: de forma predeterminada, la RVM aprovisiona una versión readonly de cada rol solicitado. Esta función se puede usar en CI/CD canalizaciones que no escriben datos, como un flujo de trabajo de terraform plan canalización. Este enfoque ayuda a evitar cambios no deseados si un flujo de trabajo de solo lectura no funciona correctamente.

    De forma predeterminada, la ReadOnlyAccess política AWS administrada está asociada tanto a las funciones de solo lectura como a las funciones de lectura y escritura. Esta política reduce la necesidad de iteración a la hora de determinar los permisos necesarios, pero puede resultar demasiado permisiva para algunas organizaciones. Si lo desea, puede eliminar la política del código de Terraform.

  • Otorgue permisos mínimos: siga el principio de privilegio mínimo y conceda los permisos mínimos necesarios para llevar a cabo una tarea. Para obtener más información, consulte Otorgar privilegio mínimo y Prácticas recomendadas de seguridad en la documentación de IAM.

Epics

TareaDescripciónHabilidades requeridas

Copie el repositorio de muestras en su organización. GitHub

Clona el repositorio de este patrón o bifurca este repositorio a tu GitHub organización para que puedas adaptarlo a tus necesidades.

  • Si elige clonar este repositorio, puede usar el siguiente comando: git clone https://github.com/aws-samples/role-vending-machine

  • Si decides bifurcar el repositorio a tu GitHub organización, puedes usar el siguiente comando:

    gh repo fork aws-samples/role-vending-machine --org YOUR_ORGANIZATION_NAME

DevOps ingeniero

Determine el Cuenta de AWS para el RVM.

Determine qué implementación de infraestructura usar Cuenta de AWS para la RVM. No utilice la cuenta de administración ni la cuenta raíz.

Arquitecto de la nube

(Opcional) Permita que se creen las canalizaciones de la organización. PRs

nota

Este paso solo es necesario si quieres permitir la creación PRs del generate_providers_and_account_vars flujo de trabajo.

Para permitir la creación de las canalizaciones de tu organización PRs, sigue estos pasos:

  1. Vaya a https://github.com/organizations/YOUR_ORG/settings/actions.

  2. Selecciona Permitir GitHub acciones para crear y aprobar solicitudes de extracción.

Para obtener más información, consulte Administrar la configuración de GitHub las acciones de un repositorio en la GitHub documentación.

DevOps ingeniero

Otorgue permisos de solo lectura a la cuenta de la RVM.

Cree una política de delegación en su cuenta de administración que conceda permisos de solo lectura a la cuenta de la RVM. Esto permite que los GitHub flujos de trabajo de RVM obtengan dinámicamente una lista de las cuentas de su AWS organización cuando se ejecute el generate_providers_and_account_vars.py script.

Utilice el siguiente código y <YOUR RVM Account ID> sustitúyalo por el Cuenta de AWS ID que seleccionó en el paso 2:

{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "Statement",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<YOUR RVM Account ID>:root"
      },
      "Action": [
        "organizations:ListAccounts",
        "organizations:DescribeOrganization",
        "organizations:DescribeOrganizationalUnit",
        "organizations:ListRoots",
        "organizations:ListAWSServiceAccessForOrganization",
        "organizations:ListDelegatedAdministrators"
      ],
      "Resource": "*"
    }
  ]
}
Administrador de la nube

Actualice los valores predeterminados del repositorio de ejemplo.

Para configurar el RVM para que funcione en su entorno específico Región de AWS, haga lo siguiente:

  1. Actualice scripts/generate_providers_and_account_vars.py y otros archivos (como la carpeta bootstrap) con la región correspondiente en la que opera.

  2. Actualice el .github/workflows/.env archivo con el Cuenta de AWS ID, la región y cualquier otra variable que desee especificar.

DevOps ingeniero
TareaDescripciónHabilidades requeridas

Inicie el repositorio de la RVM.

Este paso es necesario para crear los roles de IAM y la política de confianza de OIDC que utiliza la propia canalización de la RVM, de modo que pueda empezar a operar y ofrecer otros roles.

En la cuenta de la RVM, ponga en marcha manualmente un comando terraform apply desde el directorio scripts/bootstrap. Proporcione los valores necesarios en función de la documentación de las variables.

DevOps ingeniero
TareaDescripciónHabilidades requeridas

Implemente los roles github-workflow-rvm y github-workflow-rvm-readonly en todas las cuentas.

Elija un método de implementación que se adapte a las prácticas de su organización, como AFT o StackSets. Utilice ese método para implementar las dos roles de IAM del archivo scripts/assumed_role/main.tf (nombres predeterminados github-workflow-rvm y github-workflow-rvm-readonly) en cada cuenta en la que desee que la RVM pueda crear roles de canalización.

Estos roles de IAM tienen políticas de confianza que permiten que el rol de asunción de roles de la cuenta de la RVM (o su readonly equivalente) los asuma. Los roles también tienen políticas de permisos de IAM que les permiten leer roles y escribir (a menos que usen el rol readonly) en ellos, siempre que coincidan con github-workflow-role-*.

Administrador de AWS

Ponga en marcha el flujo de trabajo generate_providers_and_account_vars.

Para configurar su RVM de forma que esté lista para crear roles de canalización, haga lo siguiente:

  1. Ponga en marcha el flujo de trabajo generate_providers_and_account_vars mediante workflow_dispatch.

  2. Fusione la solicitud de extracción que crea el flujo de trabajo.

Una vez finalizado el flujo de trabajo, la RVM está listo para hacer lo siguiente:

  • Aceptar solicitudes de nuevos roles de canalización.

  • Crear roles de solo lectura o de lectura y escritura según se solicite.

  • Despliegue las funciones según lo especificado Cuentas de AWS.

DevOps ingeniero

Resolución de problemas

ProblemaSolución

He creado un rol mediante el RVM, pero GitHub no puedo asumirlo.

Compruebe que el nombre del GitHub repositorio coincide con el nombre proporcionado al github_workflow_roles módulo. El alcance de los roles solo permite que un único repositorio pueda asumirlos.

Del mismo modo, compruebe que la rama utilizada en la GitHub canalización coincida con el nombre de la rama proporcionada al github_workflow_roles módulo. Por lo general, los roles creados por la RVM con permisos de escritura solo los pueden usar los flujos de trabajo relacionados con la rama main (es decir, las implementaciones provenientes de main).

Mi rol de solo lectura no puede poner en marcha su canalización porque carece de permisos para leer un recurso específico.

Si bien la ReadOnlyAccess política proporciona amplios permisos de solo lectura, no incluye algunas acciones de lectura (por ejemplo, determinadas AWS Security Hub CSPM acciones).

Puede agregar permisos de acciones específicas mediante el parámetro inline_policy_readonly del módulo github-workflow-roles.

Recursos relacionados

Información adicional

Uso de GitHub entornos

GitHub Los entornos son un enfoque alternativo a las restricciones basadas en las sucursales para el acceso a los roles. Si prefiere utilizar un GitHub entorno, a continuación se muestra un ejemplo de la sintaxis de una condición adicional de la política de confianza de IAM. Esta sintaxis especifica que el rol solo se puede usar cuando la GitHub acción se ejecuta en el Production entorno.

"StringLike": {
    "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:environment:Production"
}

La sintaxis de ejemplo usa los siguientes valores de marcador de posición:

  • octo-orges el nombre GitHub de la organización.

  • octo-repo es el nombre del repositorio.

  • Productiones el nombre del GitHub entorno específico.