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.
Antes que nada, debemos crear nuestros grupos de distribución para las notificaciones:
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.
El correo que le llegará a las personas suscritas debe ser muy parecido al siguiente:
Una vez confirmado el correo, cambiará de estatus la suscripción en el tema a Confirmed (confirmado), como se muestra a continuació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:
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:
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 .
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.
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:
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>>» } ] } |
{ «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.
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.
Si se hizo la aprobación, le damos clic en detalles y nos desplegará la siguiente información:
Aquí se muestra el detalle de la aprobación, comentarios e inclusive nos muestra el usuario que realizó la acción:
Si se ha rechazado, mostrará el siguiente estatus
Y de igual forma, nos mostrará el detalle del estatus:
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!