Skip to main content
La rotación reemplaza una clave de ingesta del proyecto. No cambia el proyecto ni su telemetría guardada. Gestiona las claves con la autenticación de la cuenta. Una clave de ingesta solo puede enviar telemetría. No puede gestionar claves. Antes de empezar, instala la CLI e inicia sesión. Define LOGBREW_PROJECT_ID con el UUID del proyecto. Define LOGBREW_API_URL como https://api.logbrew.co. Los ejemplos usan Bash, curl 7.76.0 o posterior y jq. En una rotación prevista, crea, despliega y prueba la clave nueva antes de revocar la antigua. Define el intervalo de rotación en tu política de seguridad. Si una clave tiene fecha de caducidad, reemplázala antes de esa fecha.
Una clave expuesta es un incidente de seguridad. Revócala de inmediato, incluso antes de desplegar la clave nueva. Las aplicaciones que aún usan una clave revocada no pueden enviar telemetría.
1

Crea la clave nueva

POST /api/projects/{project_id}/ingest-keys acepta un label no vacío de hasta 120 caracteres. kind es cli, sdk, browser, server o artifact. Una clave artifact no puede enviar telemetría. El campo opcional expires_at debe ser una hora RFC3339 futura.Usa el mismo kind que la clave antigua. La CLI usa sdk cuando omites --kind y CLI-created SDK key cuando omites --label. La CLI no tiene una opción de caducidad. Para definir expires_at, usa la API.La CLI guarda el token de un solo uso en un archivo nuevo, fuera del control de versiones, al que solo accede su propietario. Imprime los metadatos, no el token:
Continúa solo cuando el comando termine bien. Define NEW_KEY_ID con el ingest_key.id devuelto.Si el resultado no es seguro, vuelve a ejecutar exactamente el mismo comando. La CLI reutiliza su clave de reintento pendiente. No uses --abandon-retry en este reintento.Un cliente que llama directamente a la API recibe el token una sola vez en la respuesta. Para reintentar, envía el mismo encabezado Idempotency-Key con el mismo cuerpo. Durante 24 horas, ese reintento devuelve la misma clave. Nunca imprimas, confirmes en el repositorio ni compartas el token.
2

Despliega la clave nueva con la antigua todavía activa

Pon el token nuevo en el ajuste protegido del despliegue. Despliega la app. Mantén activa la clave antigua. Mantén los dos tokens fuera del código fuente, de los resultados de compilación y de los logs.
3

Envía un evento sintético

Carga el token nuevo en la variable de shell new_ingest_key. No lo imprimas. Envía un log sintético con la clave nueva y después léelo:
Continúa solo cuando la lectura devuelva este log con el mismo occurred_at. Un log de comprobación de una rotación anterior no demuestra que la clave nueva funcione. Confirma también que la app desplegada envía telemetría. Si un comando falla, detente y lee la respuesta. Mantén activa la clave antigua salvo que esté expuesta.
4

Lista los metadatos de las claves sin secretos

Define LOGBREW_ACCOUNT_BEARER a partir de la autenticación de tu cuenta. Busca el ID de la clave antigua. Confirma que NEW_KEY_ID está active:
La respuesta es un array de metadatos de claves sin tokens. El estado es active, expired o revoked. Una clave está expired cuando ya pasó la hora de su expires_at.
5

Revoca solo la clave antigua

Define OLD_KEY_ID a partir de la lista. El comando revoca la clave antigua solo cuando los dos ID son distintos:
DELETE es idempotente. Devuelve los metadatos de la clave con status: "revoked" y con revoked_at definido. Puedes repetirlo sin riesgo después de una respuesta dudosa.Ejecuta unset new_ingest_key. Gestiona el archivo de la clave según tu política de secretos.

​
Recupérate de forma segura

Si la rotación sigue fallando, informa de un problema. Comparte solo los metadatos de las claves. No incluyas credenciales, encabezados, telemetría sin procesar, datos de clientes, rutas locales ni código fuente.