Blog de Amazon Web Services (AWS)

Cómo federar en AWS desde Azure DevOps mediante OpenID Connect

Por Mathieu Bruneau, arquitecto de soluciones especializado en containers en Amazon Web Services (AWS) Canada.

En este blog post, demostraré cómo utilizar las opciones de OpenID Connect (OIDC) de AWS Toolkit for Azure DevOps, versión 1.15.0+, para federar en cuentas de AWS y obtener credenciales temporales sin tener que gestionar las credenciales estáticas de AWS Identity and Access Management (IAM).

Introducción

Azure DevOps Pipelines permite la creación, las pruebas y la implementación continuas en plataformas y nubes. El AWS Toolkit for Azure DevOps, una extensión gratuita para entornos alojados y on-premises, simplifica la administración de los recursos de AWS. El kit de herramientas se integra con los principales servicios de AWS, como Amazon Simple Storage Service (Amazon S3), AWS CodeDeploy, AWS Lambda, AWS CloudFormation y Amazon SQS.

Azure DevOps ahora admite la federación de identidades de cargas de trabajo. En combinación con las capacidades OIDC del AWS Tookit, los equipos pueden aprovechar la administración de identidades nativa para implementar los recursos de AWS y acceder a ellos mediante los controles estándar de IAM. El proceso utiliza un token proporcionado por Azure DevOps para llamar al AWS Security Token Service (STS), que genera credenciales de seguridad temporales y con privilegios limitados, de conformidad con los principios de seguridad recomendados. En la figura 1 se muestra el proceso de obtención y uso de credenciales del servicio AWS STS mediante la federación.

Cómo federar en AWS desde Azure DevOps mediante OpenID Connect

Figura 1: Credenciales de Azure DevOps mediante el flujo de AWS STS

Descripción general de alto nivel

Nota: Como esta publicación utiliza IAM como parte de la solución, como mínimo se necesitará permiso para createRole, ListOpenIDConnectProviders y createOpenIDConnectProvider. En la mayoría de los casos, tendrías que adjuntar permisos al role, pero no son necesarios en nuestro ejemplo.

  1. Cree un pipeline de YAML en Azure DevOps y recopile el GUID de la organización.
  2. Configure un proveedor de identidades en AWS para la federación de OIDC.
  3. Cree una role de IAM en AWS que pueda asumir el proveedor de identidades.
  4. Ejecute el pipeline de DevOps de Azure para confirmar que la federación se ha realizado correctamente.

Requisitos previos

  1. Una cuenta de AWS con permisos suficientes para crear proveedores de IAM y roles y políticas de IAM
  2. Un proyecto de Azure DevOps con acceso para configurar conexiones de servicio; son conexiones autenticadas entre Azure Pipelines y servicios externos o remotos.
  3. Versión 1.15 o superior del AWS Toolkit for Azure DevOps para ese proyecto. Consulte AWS Toolkit for Azure DevOps en Visual Studio Marketplace para obtener instrucciones de instalación.

Cree un pipeline de YAML en Azure DevOps y recopile el GUID de la organización

Para configurar el proveedor de identidades en AWS, necesitaremos el GUID de la organización de Azure DevOps. En primer lugar, necesitamos crear una conexión de servicio que haga referencia a una role de IAM denominado azdo-federation que crearemos más adelante.

Desde la configuración de su proyecto de Azure DevOps:

  1. En Pipelines, seleccione Service Connections.
  2. Seleccione New service account.
  3. Elija AWS y seleccione Next.
  4. En Role to assume, utilice el ARN del rol. En nuestro ejemplo, utilizaremos un rol denominado azdo-federation, para que el ARN sustituya al ID de su cuenta de AWS de la siguiente manera: arn:aws:iam::123456789012:role/azdo-federation.
  5. (Opcional) El campo Role Session Name, si se deja vacío, pasará a ser aws-vsts-tools de forma predeterminada. Puede introducir otro valor aquí.
    Marque la opción use OIDC.
  6. Para Service Connection Name, utilice aws-oidc-federation.
  7. Seleccione Save.

Obtenga el GUID de la organización de Azure DevOps ejecutando el pipeline

Nota: Como la configuración está incompleta, nuestro pipeline fallará, pero la información necesaria para configurar un proveedor de identidades estará disponible en los registros.

De los pipelines de sus proyectos de Azure DevOps:

  1. Seleccione New pipeline.
  2. Elija Azure Repos Git.
  3. Seleccione Starter Pipeline.
  4. Copie y pegue el siguiente archivo YAML, ajustando AWSCredentials para el nombre de la conexión del servicio y, si es necesario, el nombre de la región.
# Sample pipeline to test connectivity to AWS (adjust service connection name (awsCredentials), and regionName as needed)

trigger:
    - main

pool:
    vmImage: ubuntu-latest

variables:
  aws.rolecredential.maxduration: "3600" # Can be set from 900 - 43200s

steps:
    - task: AWSCLI@1
      displayName: "Running aws-cli get-caller-identity"
      # continueOnError: true # If you need the pipeline to succeed
      inputs:
        awsCredentials: "aws-oidc-federation"
        regionName: 'aws-region-name'
        awsCommand: 'sts'
        awsSubCommand: 'get-caller-identity'
YAML

5. Seleccione Save and run.

Transcurridos unos segundos, el pipeline solicitará permiso para usar la conexión de servicio (Figura 2).

Figura 2 – El pipeline de Azure DevOps requiere permiso para usar la conexión de servicio

Seleccione View y revise la información para conceder el permiso con el botón Permit.

Una vez ejecutado el pipeline, compruebe en los logs de la tarea denominada Running aws-cli get-caller-identity una línea que comience con OIDC Token generated. A partir de ahí, tendrá el issuer, audience y la subject line necesarios para el resto de la configuración (Figura 3).

Figura 3 – Logs de las tareas Running aws-cli get-caller-identity

Con esta información, podemos crear el proveedor de identidad en nuestra cuenta de AWS.

Configure un proveedor de identidades en AWS para la federación de OIDC

En este paso, utilizaremos el issuer obtenido de los registros.

Desde la consola IAM de AWS, siga estos pasos.

  1. En Access management, seleccione Identity providers en el menú de la izquierda.
  2. Seleccione Add Provider.
  3. Elija OpenID Connect como Provider type.
  4. En el Provider URL, utilice la URL del issuer obtenida en la sección anterior. Cada tenant de Azure DevOps tendrá un organizationGUID único; el formato esperado es https://vstoken.dev.azure.com/{organizationGUID}.
  5. En el campo Audience, utilice api://AzureAdTokenExchange. Se trata de un valor fijo para Azure DevOps. También se encontró en los logs de la ejecución del pipeline.
  6. Seleccione Add Provider.
  7. Tome nota del ARN del proveedor recién creado, lo necesitará en el siguiente paso.

Cree un rol de IAM en AWS que pueda asumir el proveedor de identidades

Un rol de IAM es una entidad que le permite asignar permisos específicos. Para controlar quién puede usar esa función y en qué condiciones, utilizamos una política de confianza. Para seguir el principio del mínimo privilegio, añadiremos una condición a la política de confianza para que solo una conexión de servicio específica de Azure DevOps pueda utilizar la role de IAM que estamos creando. Azure DevOps transfiere la conexión de servicio en el campo de asunto de la siguiente manera: “sc://{organizationName}/{ProjectName}/{ServiceConnectionName}”.

Continúe desde la consola de IAM de AWS.

En este paso, utilizaremos el subject que obtuvimos de los logs en la primera ejecución. El formato esperado es:

sc://{OrganizationName}/{ProjectName}/{ServiceConnectionName}.

  1. En Access management, seleccione Roles.
  2. Seleccione Create role.
  3. En el Trusted entity type, seleccione Web Identity.
  4. Seleccione el proveedor de identidad correcto en el menú desplegable, que comienza por vstoken.dev.azure.com/{organizationGUID}.
  5. En el menú desplegable Audience, seleccione api://AzureAdTokenExchange.
  6. Para limitar este rol a una sola conexión de servicio, añadiremos una condición. En Condition, seleccione Add condition y, en Key, seleccione vstoken.dev.azure.com/{organizationGUID}:sub. En Condition, seleccione StringEquals. Para Value, utilice el subject obtenido de los logs. Debe tener este formato: sc://{OrganizationName}/{ProjectName}/{ServiceConnectionName}.
  7. Seleccione Next. Puedes dejar el permiso en blanco, ya que nuestro pipeline solo valida nuestra identidad, pero en un pipeline real, aquí es donde debes adjuntar la política necesaria.
  8. Seleccione Next, introduce azdo-federation como nombre del rol y revisa los detalles. Aquí tienes la política de confianza completa. Sustituya el texto en negrita y cursiva por los identificadores correctos.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/vstoken.dev.azure.com/{OrganizationGUID}"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "vstoken.dev.azure.com/00000000-0000-0000-0000-000000000000:aud": "api://AzureADTokenExchange",
          "vstoken.dev.azure.com/00000000-0000-0000-0000-000000000000:sub": "sc://{OrganizationName}/{ProjectName}/{ServiceConnectionName}"
        }
      }
    }
  ]
}
JSON

9. Seleccione Create role.

Ejecute el pipeline de Azure DevOps para confirmar que la federación se ha realizado correctamente

En este punto, si volvemos a ejecutar el pipeline que hemos creado, la federación debería funcionar correctamente y proporcionarnos un resultado similar al obtenido en el log de tareas (Figura 4).

Figura 4 – Output de la tarea aws-cli get-caller-identity

Cambios necesarios en las pipelines o tareas actuales existentes

Acabas de aprender a usar el OIDC en tus pipelines. La opción no requiere cambios en tareas actuales. Para actualizar sus pipelines, debe volver a configurar la conexión del servicio para habilitar la opción de use OIDC, el rol que debe asumir y eliminar las access/secret keys estáticas (si están definidas). Consulte este comentario de GitHub para saber cómo hacer esto a través de CLI o API. La tarea probará primero con el método de asumir roles, garantizando un cambio mínimo en el pipeline existente.

Uso de la federación con otras herramientas

Si bien el AWS Toolkit for Azure DevOps proporciona tareas para muchos servicios de AWS, no cubre todos los casos de uso. Esta técnica de federación se puede utilizar con cualquier herramienta de terceros, ya que proporciona credenciales temporales, como las del proveedor básico estandarizado de los SDKs de AWS.

Este es un ejemplo del uso de Terraform. Con la tarea AWSShellScript, configuraremos las credenciales de AWS para que las puedan utilizar las herramientas en proceso. Además, si tiene procesos de larga ejecución, puede ajustar la variable aws.rolecredential.maxduration en su proceso para garantizar que sus credenciales sean válidas durante toda la tarea (de 900 a 43200 segundos).

Este es un ejemplo de un pipeline para lograr este objetivo con Terraform:

# Sample pipeline that pass AWS credential to another task

trigger:
- main

variables:
  aws.rolecredential.maxduration: "3600" # Duration in seconds of the temporary credentials, can be set from 900 - 43200

pool:
  vmImage: ubuntu-latest

steps:
- task: AWSShellScript@1
  continueOnError: true
  displayName: "Running aws-cli get-caller-identity"
  inputs:
    awsCredentials: "aws-oidc-federation"
    regionName: "aws-region-name"
    scriptType: inline
    inlineScript: |
      terraform init
      terraform apply -auto-approve
YAML

Y el output correspondiente que llama al proveedor de datos aws_caller_identity data source (Figura 5).

Figura 5 – Output de la tarea terraform utilizando la fuente de datos aws_caller_identity

Si necesita ayuda para configurar el terraform state para usar un bucket de Amazon S3, puede consultar la documentación de Terraform sobre el back-end storage de S3.

¡Limpieza!

En su cuenta de AWS, elimine el rol de IAM y el proveedor de identidades que se crearon para eliminar cualquier derecho de acceso de Azure DevOps. En Azure DevOps, elimine la conexión de servicio, el pipeline creado y los archivos que hizo commit en el repositorio.

Conclusión
Con esta nueva función, que forma parte del AWS Toolkit for Azure DevOps, ahora puede confiar en las mejores prácticas de usar credenciales temporales y no tener que aprovisionar ni rotar claves estáticas o usuarios de IAM. Esto le permitirá utilizar una role de IAM con credenciales temporales, lo que minimizará la necesidad de rotación de credenciales y reducirá las necesidades operativas. Puede controlar la duración de la sesión de las credenciales, lo que le permite obtener la máxima flexibilidad a la hora de proteger su entorno.

Enlaces:
AWS Toolkit for Azure DevOps Marketplace

Este artículo se publicó originalmente en inglés en el blog de AWS (enlace aquí).

Autor

Mathieu Bruneau es arquitecto de soluciones especializado en containers en Amazon Web Services (AWS) Canada. Antes de que se popularizara el término DevOps, se dedicó a crear puentes entre los equipos de operaciones y desarrolladores. Math vive en Montreal (Canadá) y disfruta pasar tiempo con su esposa y sus tres hijos, ya sea jugando videojuegos o lanzando frisbees.

Traductores

Luciano Bernardes actualmente trabaja como Arquitecto de Soluciones Sr. en AWS, especializándose en cargas de trabajo de Microsoft. Con 18 años de experiencia en el mercado, trabajó principalmente en consultoría técnica especializada en Microsoft, para clientes de diversas verticales, con demandas enfocadas en infraestructura on-premise y cloud. Como SA, trabaja en estrecha colaboración con clientes y socios consultores en EE. UU. y LATAM, para apoyarlos en la toma de decisiones y la revisión de la arquitectura de las cargas de trabajo de Microsoft en la nube de AWS.
JuanMa Silva quien es arquitecto de soluciones con especialidad en containers para México y MCO. Cuenta con 16 años de experiencia en la industria de IT, en posiciones de Sysadmin, consultor para ayudar a migrar clientes a la nube y modernización de aplicaciones, soporte aplicaciones de misión crítica basados en tecnologías de containers.