AI Red Teaming Lab — Parte 2

Dónde estamos

En el post anterior definimos la arquitectura completa del lab: CoPyRIT corriendo en Azure Container Apps, con Azure OpenAI como target, protegido por Entra ID. En este post construimos la base: el Resource Group, el Azure Container Registry, y el recurso de Azure OpenAI con GPT-4o desplegado.

Al final de este post tendremos configurado:

• Un Resource Group aislado para todo el lab
• Un Azure Container Registry listo para recibir la imagen de CoPyRIT
• Un endpoint de Azure OpenAI con GPT-4o desplegado y verificado
• Las credenciales necesarias guardadas de forma segura para los posts siguientes

---

Por donde empezamos

Antes de tocar código o Docker, tenemos que tener clara la base de infraestructura. Hay una razón concreta para hacerlo en este orden: Azure OpenAI tiene restricciones de cuota y disponibilidad por región , recomendamos que estén en sweden central ya que en esta región es donde llegan todas las novedades a europa antes que a cualquier otra región.

Prerequisitos

Nos aseguramos de tener esto antes de continuar:

bash

# Azure CLI instalada y sesión activa
az --version       # >= 2.50 recomendado
az account show    # Debe mostrar tu suscripción activa

# Docker instalado (lo necesitaremos en el Post 3)
docker --version

Si no tenemos sesión activa:

bash

az login
# Se abre el navegador para autenticación con tu cuenta Microsoft

Verifica que tu suscripción está activa y es la correcta:

bash

az account list --output table

Deberías ver algo así:

Paso 1: Verificar el provider de Azure OpenAI

Antes de crear cualquier recurso, verificamos que el provider de Cognitive Services (que engloba Azure OpenAI) está registrado en tu suscripción:

bash

az provider show \
  --namespace Microsoft.CognitiveServices \
  --query "registrationState" \
  --output tsv

Output esperado:

Si ves NotRegistered, regístralo y espera ~2 minutos:

bash

az provider register --namespace Microsoft.CognitiveServices

az provider show --namespace Microsoft.CognitiveServices --query "registrationState"

Por qué existe este paso: Azure organiza sus servicios en «providers» ,estos son namespaces que agrupan tipos de recursos relacionados. Por defecto, no todos están registrados en una suscripción nueva. Antes de poder crear cualquier recurso bajo Microsoft.CognitiveServices, el provider tiene que estar activo. Es un paso que se hace una sola vez por suscripción.

Paso 2: Crear el Resource Group

Un Resource Group es un contenedor lógico en Azure que agrupa recursos relacionados. Todo lo que creemos para este lab vive dentro de este RG lo que nos permite ver el coste total de un vistazo, aplicar políticas de forma consistente, y sobre todo, destruirlo todo con un solo comando cuando terminemos o queramos resetear.

bash

az group create --name rg-lab-pyrit --location swedencentral

Output esperado:

json

{
  "id": "/subscriptions/xxxx/resourceGroups/rg-lab-pyrit",
  "location": "swedencentral",
  "name": "rg-lab-pyrit",
  "properties": {
    "provisioningState": "Succeeded"
  }
}

Por qué swedencentral: Esta región tiene disponibilidad de GPT-4o confirmada en el tier de Azure for Students , por otro lado , lo que comentaba , al final todas las novedades normalmente entran primeror en esta región de europa , por lo que para laboratorios es lo que nos interesa , también tiene latencia razonable desde España. Otras opciones viables son eastus o spaincentral. Lo importante es que todos los recursos del lab estén en la misma región para evitar latencia entre servicios y cargos por transferencia de datos entre regiones.

Verificamos que se creó correctamente:

bash

az group show --name rg-lab-pyrit --output table

Paso 3: Crear el Azure Container Registry

Azure Container Registry (ACR) es el registro privado donde almacenaremos la imagen Docker de CoPyRIT. En el Post 3 construiremos esa imagen y la subiremos aquí; hoy creamos el registro.

bash

az acr create --name acrcyberlabpyrit --resource-group rg-lab-pyrit --sku Basic --admin-enabled false

Output esperado (fragmento):

Sobre el nombre del ACR: Los nombres de ACR tienen que ser globalmente únicos en Azure. El nombre solo puede contener letras y números, sin guiones.

Por qué --admin-enabled false: El ACR tiene un modo de administración que genera un usuario/password estático para autenticarse. Deshabilitarlo desde el principio nos fuerza a usar managed identity para que Container Apps acceda al registro que es la forma correcta y segura. Un usuario/password estático para un registro de contenedores es exactamente el tipo de credencial que acaba en un .env commiteado en GitHub.

Por qué SKU Basic: Para un lab personal es más que suficiente. Basic soporta almacenamiento de hasta 10 GB y tiene las funcionalidades que necesitamos. Los tiers Standard y Premium añaden geo-replicación, webhooks avanzados y más throughput ninguno necesario aquí.

Anota el loginServer, lo necesitaremos más adelante:

bash

az acr show --name acrcyberlabpyrit --resource-group rg-lab-pyrit --query "loginServer" --output tsv

Paso 4: Crear el recurso de Azure OpenAI

Este es el componente central del lab desde el punto de vista de la seguridad: el sistema que vamos a evaluar con PyRIT.

bash

az cognitiveservices account create --name openai-cyberlab-cibersecblog --resource-group rg-lab-pyrit --kind OpenAI --sku S0 --location swedencentral

Por qué --kind OpenAI y no AIServices: Azure tiene dos tipos de recursos que pueden hospedar modelos de OpenAI: OpenAI (el recurso clásico, solo para modelos OpenAI) y AIServices (el nuevo recurso unificado que agrupa múltiples servicios de IA). Para este lab usamos OpenAI porque es más explícito en su propósito y la integración con PyRIT está más documentada contra este tipo. En un entorno productivo, AIServices tiene ventajas de consolidación, pero añade complejidad innecesaria aquí.

Por qué --sku S0: Es el único SKU disponible para Azure OpenAI. No hay opciones aquí — todos los recursos de Azure OpenAI son S0.

Paso 5: Desplegar GPT-4o

Crear el recurso de Azure OpenAI no despliega ningún modelo automáticamente — solo crea el «contenedor» del servicio. El modelo hay que desplegarlo explícitamente dentro de ese recurso.

bash

az cognitiveservices account deployment create --name openai-cyberlab-cibersecblog --resource-group rg-lab-pyrit --deployment-name gpt-4o-atacante --model-name gpt-4o --model-version "2024-11-20" --model-format OpenAI --sku-capacity 10 --sku-name "Standard"

Por qué gpt-4o-atacante como nombre del deployment: El nombre del deployment es lo que usarás en el .env de CoPyRIT y en la configuración del target. Nombrarlo con su rol en el lab (el modelo que estamos atacando) hace la configuración más legible. En el Post 6 desplegaremos un segundo modelo (gpt-4o-mini-agente) que actuará como scorer/juez — tener nombres descriptivos evita confusión.

Sobre --sku-capacity 10: Esta es la cuota en unidades de TPM (Tokens Per Minute) × 1000. Con 10 tenemos 10.000 TPM — más que suficiente para un lab. Azure for Students tiene límites de cuota; si el comando falla con un error de cuota, reduce a 5 o incluso 1 (1.000 TPM) para el lab.

Verificamos que el deployment está activo:

bash

az cognitiveservices account deployment list --name openai-cyberlab-cibersecblog --resource-group rg-lab-pyrit --output table

Output esperado:

---

Paso 6: Obtener y guardar las credenciales

Necesitamos el endpoint y la API key del recurso de Azure OpenAI. Estas credenciales irán en el archivo .env de CoPyRIT en el Post 3.

bash

# Endpoint
az cognitiveservices account show --name openai-cyberlab-cibersecblog --resource-group rg-lab-pyrit --query "properties.endpoint" --output tsv

bash

# API Key
az cognitiveservices account keys list \
  --name openai-cyberlab-cibersecblog \
  --resource-group rg-lab-pyrit \
  --query "key1" \
  --output tsv

Crea un archivo local para guardar estas credenciales de forma temporal (fuera de cualquier repositorio):

bash

# Crear el directorio de configuración del lab
mkdir -p ~/.pyrit-lab

# Guardar las credenciales (este archivo NUNCA va a ningún repo)
cat > ~/.pyrit-lab/.env << 'EOF'
AZURE_OPENAI_ENDPOINT=https://openai-cyberlab-cibersecblog.openai.azure.com/
AZURE_OPENAI_KEY=TU_KEY_AQUI
AZURE_OPENAI_DEPLOYMENT=gpt-4o-atacante
AZURE_ACR_LOGIN_SERVER=acrcyberlabpyrit.azurecr.io
AZURE_RESOURCE_GROUP=rg-lab-pyrit
EOF

chmod 600 ~/.pyrit-lab/.env

El chmod 600 restringe el archivo para que solo tu usuario pueda leerlo — buena práctica aunque estés en tu máquina personal.

---

Paso 7: Verificación end-to-end

Antes de cerrar el post, verificamos que el endpoint de Azure OpenAI responde correctamente. Un curl rápido contra la API:

bash

# Cargar las variables del .env
export $(cat ~/.pyrit-lab/.env | xargs)

# Test básico contra el endpoint
curl -s -X POST "${AZURE_OPENAI_ENDPOINT}openai/deployments/${AZURE_OPENAI_DEPLOYMENT}/chat/completions?api-version=2024-02-01" \
  -H "Content-Type: application/json" \
  -H "api-key: ${AZURE_OPENAI_KEY}" \
  -d '{
    "messages": [{"role": "user", "content": "Responde solo con la palabra: FUNCIONA"}],
    "max_tokens": 10
  }' | python3 -m json.tool

---

Resumen de lo que hemos construido

Credenciales guardadas en ~/.pyrit-lab/.env (local, no en ningún repo).

---

---

Siguiente paso

En el Post 3 clonaremos ya por fin el repositorio de PyRIT, analizaremos la estructura del proyecto y el Dockerfile de CoPyRIT, construimos la imagen Docker y la subimos al ACR que acabamos de crear.

El lab empieza a tomar forma.