Potencial riesgo de seguridad usando Azure Devops pipelines con la tarea "Execute oc command" de Openshift

Existe un problema en el módulo "Execute oc command" disponible en pipelines de Azure Devops para realizar tareas en nuestros clusters de Openshift que supone un gran riesgo de seguridad.

Cómo se ejecutan los pipelines

Cuando ejecutamos un pipeline de Azure Devops, se crea un proceso en una máquina virtual configurada como agente. El proceso clona el repositorio en una carpeta "efímera" que será borrada luego de la ejecución. Si se ejecutan múltiples pipelines en el mismo agente, cada ejecución tendrá su propia carpeta.

Qué hace la tarea "Execute oc command"

La tarea "Execute oc command" primero se autentica contra el cluster de Openshift. Para esto hay 3 métodos disponibles:

• Usando una Service Connection
• Indicando el archivo kubeconfig que debe utilizar
• Injectando un kubeconfig "in-line"

Cuando usamos la opción de Service Connection, la tarea utiliza el kubeconfig de la carpeta "home" del agente. Esto significa que, cuando el pipeline termine la ejecución y la carpeta clonada sea borrada, el kubeconfig con las credenciales NO será eliminado.

Riesgos de seguridad

Algunos riezgos potenciales son:

• Se puede crear un pipeline que muestre el contenido de el kubeconfig exponiendo las credenciales de todas las Service Connection que se hayan usado previamente.
• Si dos pipelines inician en paralelo, el segundo pipeline en autenticar contra el cluster de Openshift pisará la configuración del primero haciendo que este utilice credenciales diferentes de las configuradas.
• En el escenario anterior, un pipeline podría comenzar a desplegar recursos en un cluster de Openshift y terminar desplegando en otro.

Cómo mitigar el problema

Ya reporté el problema en el repo de redhat-developer, pero mientras tanto, podemos mitigar el riesgo de dos formas.

No usar Openshift Connection Service

Utilizando las opciones de definir el path del kubeconfig o usar un kubeconfig "in-line" combinado con un secreto de Azure Devops. Para esto debemos crear un secreto para almacenar un kubeconfig creado previamente por nosotros.

De esta forma, el pipeline utilizará un kubeconfig dentro de la carpeta clonada para ejecución de las tareas.

Forzar el uso de un kubeconfig local

Podemos indicarle al comando "oc" la ruta al kubeconfig que debe utilizar configurando la variable de entorno KUBECONFIG. Configurando esta variable de entorno con una ruta que esté dentro de la carpeta clonada, la tarea "Execute oc command" creará un config nuevo que solo contenga las credenciales de la cuenta de servicio deseada. Al ser local, el kubeconfig sólo será utilizado por la presente ejecución y será borrado junto con la carpeta.

Sin embargo, la tarea "Execute oc command" sobrescribe la variable de entorno. Por este motivo, debemos configurar la variable de entorno KUBECONFIG antes de "Execute oc command" y después del mismo.

En los pipelines tenemos una forma para configurar una variable de entorno que luce así:

echo "##vso[task.setvariable variable=MI_VARIABLE;]VALOR"

Y una forma de obtener la carpeta actual que se escribe de esta forma:

$(Build.Repository.LocalPath)

Usando estas 2 herramientas podemos mitigar el problema si creamos las siguientes tareas en el pipeline:

steps:
- bash: |
    echo "##vso[task.setvariable variable=KUBECONFIG;]$(Build.Repository.LocalPath)/kubeconfig"
  displayName: 'configurar variable KUBECONFIG'
- task: oc-cmd@3
  inputs:
    connectionType: 'OpenShift Connection Service'
    openshiftService: OpenshiftCluster-Test
    cmd: 'project'
- bash: |
    echo "##vso[task.setvariable variable=KUBECONFIG;]$(Build.Repository.LocalPath)/kubeconfig"
  displayName: 'volver a configurar variable KUBECONFIG'
- bash: |
    oc get deploy

Esta es una forma de mitigar el potencial riesgo de seguridad hasta tanto Openshift Developers corrija la tarea de Azure Devops.