Crea aprobadores manuales para AWS Pipeline

Por Josué Armando Vázquez, Infrastructure DevOps en Financial Solutions

Cuando realizamos pases productivos, tenemos ciertas limitaciones con respecto a políticas específicas de acceso al repositorio y rama productiva, utilizando las mejores prácticas de Gitflow, podemos lanzar o revisar código al momento de realizar un pull_request , merge o push.

¿Cómo podríamos rectificar que estás acciones son correctas y que no se realizarán más despliegues de los debidos?

En Financial Solutions, tenemos un candado adicional a la hora de desplegar, a esto se le llaman aprobadores manuales; en el momento en que algún pipeline productivo detecta que existe una nueva versión de compilación, esta lanza una notificación a nuestro equipo de QA y a nuestro equipo de Infraestructura, los cuales tienen la obligación de aprobar o rechazar el pase dependiendo el caso.

Nuestros pipelines productivos constan de tres etapas:

  • Source: en esta etapa se identifica que existe un nuevo compilado e inicia las etapas siguientes.
  • Approvals: en esta etapa se lanzan las notificaciones a los equipos correspondientes para que estos a su vez puedan aprobar el despliegue de la nueva versión.
  • Deploy: en esta etapa final se realiza un backup del compilado anterior (en caso de front y back) y posteriormente se realiza el despliegue de la nueva versión.

Imagen1. Etapas del pipeline productivo

En este artículo te guiaremos paso a paso para ayudarte a crear estos aprobadores en tus canalizaciones productivas.

Antes que nada, debemos crear nuestros grupos de distribución para las notificaciones:


Imagen2. Panel de control Amazon SNS
  • En la cintilla superior seleccionamos el botón Create New Topic (Crear un nuevo tema), en Topic Name (Nombre del tema), escribe un nombre para el tema. Para esta guía utilizaremos los nombres de aprobacion_qa o bien aprobacion_infra.
  • De igual forma, utilizaremos un tipo de sns estándar ya que no se requiere de un alto rendimiento y requerimos un protocolo de suscripción para correo electrónico.

Imagen3. Tipo de tema SNS
  • Una vez creado nuestro tema, para el envío de correos, necesitamos suscribir a las personas que estarán encargadas de aprobar o rechazar los pases, para esto seleccionaremos en el menú inferior la pestaña de Create subscription (crear suscripción).
  • A continuación, se elegirá por default el tema que creamos; en el combo de los protocolos, seleccionamos la opción de email y añadimos el correo al que deseamos se le notifique en la opción de endpoint.

Imagen 4. Suscripción tipo email

Una vez creada la suscripción, nos aparecerá el contacto en estado “pendiente por confirmar”, SNS mandará un correo de confirmación a la cuenta que fue suscrita y esta deberá confirmar para poder recibir notificaciones.


Imagen5. Suscripción pendiente de confirmación

El correo que le llegará a las personas suscritas debe ser muy parecido al siguiente:

Imagen5. Correo de confirmación

Una vez confirmado el correo, cambiará de estatus la suscripción en el tema a Confirmed (confirmado), como se muestra a continuación:

Imagen5. Correo para confirmación

Una vez creado nuestro tema de SNS, estamos listos para agregar a nuestra canalización los aprobadores. Lo cual se realiza de la siguiente manera:

  • Nos dirigimos al servicio de CodePipeline en     https://console.aws.amazon.com/codepipeline/.
  • Seleccionamos la canalización a la cual vamos agregar las aprobaciones manuales. Una vez elegida, seleccionamos la opción de editar.

Imagen 8. Cinta de opciones pipeline
  • Nos mostrará este apartado en pantalla, para agregar etapas a nuestra canalización:

Imagen 9. Edición de canalización
  • Al dar clic en agregar etapa, lo primero que nos pedirá será el nombre:

Imagen 10. Nombre de la etapa
  • Una vez agregada la etapa, al dar clic en “agregar grupo de acción”, nos desplegará varias opciones. A nosotros nos interesa agregar un aprobador manual.
Imagen 10. Editar grupo de acciones
  • Al seleccionarlo, cambiará el menú de inmediato para ingresar las opciones de los aprobadores:

Imagen 12. Campos para aprobadores
  • Los cuatro campos que muestra los marca como opcionales, ya que se puede configurar la aprobación, sin necesidad de mandar notificación automática o mandar parámetros adicionales en esas notificaciones.

Dependiendo de las necesidades que se tengan o las obligaciones a cumplir antes de algún pase, se utilizan los campos adicionales que nos proporciona Amazon. A nosotros nos interesa poder notificar a los equipos de trabajo de manera automática, por lo tanto, en el campo SNS topic ARN, seleccionaremos el tema de notificaciones que creamos anteriormente.

Entonces quedaría de la siguiente forma:


Imagen 13. Campos para aprobadores
  • Una vez seleccionado nuestro grupo de notificaciones, aceptaremos la edición; primero de la acción y después de la etapa. Una vez aceptados los cambios es necesario guardar las modificaciones del pipeline.

Imagen 14. Campos para aprobadores
  • Una vez guardados y aceptados los cambios, nos mostrará nuestra nueva etapa, en estatus “Didn’t Run “y la leyenda “No executions yet”, esto es porque esa etapa no se ha ejecutado aún.

Esta se ejecutará la próxima vez que se lance nuestra canalización de manera automática o bien se pueden probar las notificaciones lanzando la canalización de manera manual, para esto dentro de nuestro pipeline con la aprobación, seleccionamos el botón release change .


Imagen 15. Estatus
  • Nuestra etapa se mostrará en color azul, en modo de espera por la aprobación.
  • En este momento la notificación ya fue enviada a los correos que se dieron de alta previamente y queda en espera de la aprobación necesaria.

Si la quisiéramos ver a detalle nos muestra el nombre del pipeline donde se solicita la aprobación, en qué etapa se encuentra, región y la acción que lo requiere, ya que podemos tener varios aprobadores y en la notificación mencionará cual acción es la que le corresponde. Adicionalmente, nos pone una liga directa hacia el pipeline que debemos aprobar.


Imagen 17. Correo de notificación
  • Una vez que tengamos este correo, se requiere que quienes estén asignados para aprobar o rechazar un pipeline tengan un usuario para entrar a la consola, con los debidos permisos, para poder aprobar solo la acción que le corresponde.

Para esto podemos crear grupos de iam, a los cuales asignarle la política correspondiente.  

Nos dirigimos al servicio de IAM https://console.aws.amazon.com/iamv2/home?#/groups , aquí crearemos un grupo llamado aprobadores_infra y asignaremos los usuarios que pertenecen a este grupo:


Imagen 18. Creación de grupo y asignación de usuarios iam
  • Crearemos el grupo sin ninguna política, ya que la asignaremos de manera personalizada y única. Una vez creado, seleccionaremos nuestro grupo de aprobaciones y en la pestaña de permisos agregaremos una política en línea.
Imagen 19. Creación de política en línea
  • En formato JSON, en la política que se muestra debajo, solo debe ser cambiado el nombre del pipeline, la etapa y acción requerida, para negar el permiso de aprobar alguna acción que no le corresponda.

Supongamos que se tienen dos acciones requeridas en las aprobaciones, por un lado, se encuentra la aprobación perteneciente a infraestructura y la aprobación para el equipo de calidad.

Si en la política que estamos creando solo debemos restringir a infraestructura, para que solo pueda modificar lo que te toca, es necesario especificar en el segundo fragmento de la política, que se le prohíbe la manipulación de alguna otra aprobación que no le corresponda (la línea a modificar se muestra subrayada en amarillo).


{
  «Version»: «2012-10-17»,
  «Statement»: [
      {
          «Sid»: «VisualEditor0»,
          «Effect»: «Allow»,
          «Action»: [
              «codepipeline:ListWebhooks»,
              «codepipeline:PutApprovalResult»,
              «codepipeline:ListPipelineExecutions»,
              «codepipeline:ListActionExecutions»,
              «codepipeline:ListPipelines»,
              «codepipeline:GetPipeline»,
              «codepipeline:ListTagsForResource»,
              «codepipeline:GetThirdPartyJobDetails»,
              «codepipeline:GetPipelineState»,
              «codepipeline:GetJobDetails»,
              «codepipeline:GetPipelineExecution»,
              «codepipeline:ListActionTypes»
          ],
          «Resource»: «*»
      },
      {
          «Sid»: «VisualEditor1»,
          «Effect»: «Deny»,
          «Action»: «codepipeline:PutApprovalResult»,
          «Resource»: «arn:aws:codepipeline:*:<<account-number>>:*/<<stage-name >>/<<action-name>>»
      }
   ]
}
  • Entonces de acuerdo con el ejemplo, ese fragmento quedaría de la siguiente manera:
        {
            «Sid»: «VisualEditor1»,
            «Effect»: «Deny»,
            «Action»: «codepipeline:PutApprovalResult»,
            «Resource»: «arn:aws:codepipeline:*:- – – – – – – – -:*/Aprobaciones/aprobacion_qa»
        }

De esta forma se limita para que solo pueda aprobar su acción correspondiente y no pueda manipular la aprobación del equipo de qa. La política para el equipo de calidad deberá ser igual, restringiendo en este fragmento la acción que no deberá manipular.

  • Una vez declaradas las políticas para cada grupo podrá rechazar o aprobar sus acciones correspondientes. Los cuales dependiendo del caso mostrarían approved o rejected . La pantalla de aprobación se muestra de la siguiente manera:
Imagen 20. Pantalla de aprobación

Las dos primeras leyendas, se refieren a comentarios adicionales que se hayan agregado desde la configuración del aprobador, así mismo alguna url que se deba revisar previa a la aceptación de la acción y de esta forma nos permite agregar comentarios adicionales.

  • A continuación, se mostrará como luciría en caso de ser aprobado o rechazado:

Si se hizo la aprobación, le damos clic en detalles y nos desplegará la siguiente información:

Imagen 21. Estatus aprobado.

Aquí se muestra el detalle de la aprobación, comentarios e inclusive nos muestra el usuario que realizó la acción:

Imagen 22. Detalle de aprobación

            Si se ha rechazado, mostrará el siguiente estatus

Imagen 22. Estatus rechazado.

Y de igual forma, nos mostrará el detalle del estatus:  

Imagen 23. Detalle estatus rechazado.

Una vez teniendo aprobadores en nuestra canalización, para que este pueda continuar con las etapas siguientes, debe aprobarse, si se tienen dos aprobadores, ambos deben aceptar el que continúe la canalización, de lo contrario no se ejecutarán las etapas siguientes y pipeline mostrará su estatus como rechazado.

Es de suma importancia considerar tener en nuestras canalizaciones este tipo de aprobadores, ya que solo de esta manera podemos asegurar que no se realicen cambios sin autorización, despliegues no probados o versiones no correspondientes.

¡Cuéntame si te funcionó y comenta qué otros tutoriales te gustarían leer!

Related Post