Skip to content
← Todas las publicaciones
· Delta1 Labs KeyrightAutoalojamientoAir-gappedSeguridadOperaciones

Ejecutar Keyright autoalojado totalmente aislado (air-gapped), sin internet saliente

Keyright autoalojado no necesita internet saliente en tiempo de ejecución. Verifica su propia autolicencia sin conexión contra la clave pública embebida de Delta1 —sin llamar a casa, fail-closed ante manipulación— y las apps de tus clientes validan sin conexión entre activaciones. Aquí tienes cómo instalar la autolicencia como archivo, desactivar la búsqueda GeoIP, llevar la imagen a tu registro privado, ejecutar contra tu propio Postgres y gestionar el licenciamiento medido con bloques de crédito aislados.

Algunas redes nunca tocan internet, por política y por diseño —un enclave clasificado, un sistema de control aislado, la zona de producción segmentada de un banco, una instalación segura donde un oficial de seguridad inspecciona cada byte que cruza en un pendrive USB. Si licencias software hacia esos entornos, “nuestro licenciamiento llama a casa” es inviable de entrada. La buena noticia es que Keyright autoalojado se construyó justo para esto: nada en su ruta de ejecución necesita internet. Este artículo es el cómo concreto —qué significa aislado para cada parte móvil, cómo instalar y renovar la autolicencia como archivo, cómo detener lo único que saldría a la red y cómo funciona el licenciamiento medido a través de la brecha.

Conclusión clave: Keyright autoalojado no necesita internet saliente en tiempo de ejecución. Verifica su propia autolicencia sin conexión contra la clave pública embebida de Delta1 (sin llamar a casa, fail-closed ante manipulación), las apps de tus clientes validan sin conexión entre activaciones, y para el licenciamiento medido mueves bloques de crédito aislados firmados dentro y fuera por archivo. La ejecución offline central funciona en Standard y Pro; los bloques de crédito aislados son una función Enterprise.

Qué significa “aislado” (air-gapped) para las tres partes

Hay tres partes que razonar, y cada una está desconectada de forma independiente.

La instancia de Keyright. Es la imagen ghcr.io/delta1-labs/keyright —un servicio ASP.NET Core sin estado en el puerto 8080, sin base de datos dentro. Al arrancar y en cada escaneo comprueba su propia licencia, y esa comprobación es pura criptografía local contra una clave pública horneada en la compilación. No hay llamada a un servidor de licencias de Delta1, ni apretón de manos de activación, ni telemetría que condicione el tiempo de ejecución. Una vez que la imagen y la clave están dentro de tu red, la instancia nunca necesita salir.

Tu PostgreSQL. Todo el estado —licencias, activaciones, puestos, saldos de crédito y su libro mayor, el registro de auditoría, tus claves de firma cifradas en reposo— vive en una base de datos que ejecutas tú, apuntada con la cadena de conexión KEYRIGHT_DB. Es un Postgres dentro de la red, sobre tu propia infraestructura. No interviene ningún almacén de datos gestionado nuestro; los datos nunca salen de tu perímetro.

Las apps de tus clientes. Como se cubre en la validación de licencias sin conexión explicada, una licencia firmada se verifica localmente contra la clave pública que embebes en el momento de compilar, y una activación en línea devuelve un lease firmado de corta duración que la app cachea y reverifica sin conexión. Así que tus clientes validan sin conexión entre activaciones —y en una flota totalmente desconectada emites archivos offline firmados y te saltas el ida y vuelta de activación por completo, exactamente como expone el licenciamiento para entornos aislados.

En conjunto: la instancia se autolicencia sin conexión, solo habla con una base de datos que alojas tú, y las apps de tus clientes no necesitan alcanzarla para seguir funcionando. Nada en esa ruta cruza la brecha de aire.

La instancia se licencia a sí misma sin conexión, y falla hacia el estado bloqueado

Keyright se licencia con una licencia offline de Keyright corriente, y tu instancia la verifica sin conexión contra la clave pública embebida de Delta1 —sin llamar a casa. Esa misma asimetría que protege a tus clientes protege a tu despliegue: la clave pública puede verificar la autolicencia firmada pero nunca falsificarla, así que la comprobación es matemática local, y manipular cualquier campo rompe la firma.

Es fail-closed. Sin clave, con una clave inválida, una prueba caducada o una licencia de pago pasada su ventana de gracia, la instancia queda bloqueada (gated): cada petición de cliente devuelve 402. Un puñado de endpoints sigue siendo alcanzable para que siempre puedas diagnosticar la parada sin internet —/health, /health/ready, /admin/self-license, /admin/self-diagnostics, /branding y el panel— pero el tiempo de ejecución está apagado hasta que haya una clave válida. En una red aislada eso significa que lo único que debes acertar es la clave, así que trátala con el mismo cuidado que das a la historia de copia de seguridad y recuperación de tu base de datos.

Instalar y renovar la autolicencia como archivo

Aquí está la parte que hace tropezar a quien espera una subida web: no hay endpoint de “subir licencia”. Proporcionas la clave por configuración y (re)inicias. Eso es una ventaja en una red aislada —la clave llega igual que todo lo demás, como un archivo en tu canal de transferencia aprobado.

Dos formas de suministrarla:

  • Como archivo (el valor por defecto aislado): pon KEYRIGHT_SELF_LICENSE_FILE a una ruta dentro del contenedor y monta ahí el JSON de la licencia. En Kubernetes es un Secret con --set-file secrets.selfLicense=license.json.
  • Inline: pon KEYRIGHT_SELF_LICENSE al JSON de la licencia en una sola línea (compáctalo si tu copia tiene saltos de línea) —lo más simple para un único host de Compose.

Una renovación o un cambio de edición es el mismo gesto: cambiar el archivo y reiniciar. Sin redespliegue, sin migración, sin endpoint que llamar. Luego confirma que surtió efecto:

curl -H "X-Admin-Token: $KEYRIGHT_ADMIN_TOKEN" http://localhost:8080/admin/self-license

/admin/self-license informa de tu edition, isTrial, phase (active / expiring / grace / gated), daysUntilExpiry y si el tiempo de ejecución está bloqueado —y es uno de los pocos endpoints que responden incluso cuando la instancia está bloqueada. Conecta su cuenta atrás de caducidad a tu propia monitorización, porque en una red desconectada ningún correo de renovación va a encontrarte; la instancia avisa en el panel, pero deberías vigilar la fase tú mismo. El ciclo de vida completo del estado de la clave está en la referencia de licenciamiento.

Desactiva la única llamada saliente: GeoIP

El panel tiene una búsqueda opcional de ubicación de máquina que resuelve las IP de activación a una ubicación aproximada. Eso es lo único en una configuración de fábrica que intentaría una petición saliente. Desactívalo para una ejecución aislada dejándolo vacío:

KEYRIGHT_GEOIP_URL=

Con eso sin definir, el panel simplemente omite la columna de ubicación y no intenta nada saliente. Todo lo demás —activación, validación, puestos, créditos, el portal— ya era local.

Llevar la imagen a tu registro privado

La imagen vive en un registro público que no puedes alcanzar desde dentro de la brecha, así que muévela como mueves cualquier artefacto: descárgala en un host conectado, expórtala y cárgala al otro lado.

# En un host conectado:
docker save ghcr.io/delta1-labs/keyright:2.2.2 -o keyright-2.2.2.tar
# (guarda también postgres:16 si usas la BD incluida para una instalación pequeña)

# Lleva el tarball por tu canal aprobado, y luego dentro de la red:
docker load -i keyright-2.2.2.tar

Reetiqueta y empuja a tu propio registro dentro de la red si ejecutas uno, y fija la versión (image.tag=2.2.2 en Helm) para que los despliegues sean reproducibles. Apunta KEYRIGHT_DB a tu PostgreSQL dentro de la red —una base de datos en tu propia infraestructura, con TLS requerido— y la instancia crea y migra su esquema en el primer arranque sin SQL que ejecutar a mano. Las actualizaciones son el mismo importar-y-reiniciar, con las migraciones aplicándose automáticamente al arrancar.

Licenciamiento medido a través de la brecha: bloques de crédito aislados

Si vendes por créditos o por uso, la conectividad suele ser cómo reconcilias el gasto —y eso es justo lo que una red aislada no puede ofrecer. Los bloques de crédito aislados lo resuelven con la misma confianza de firma que una licencia. Emites un bloque firmado de crédito para una máquina desconectada, se canjea allí sin conexión, y reconcilias el uso cuando el bloque vuelve a cruzar la brecha. Como cada bloque está firmado por la clave de tu instancia y se verifica localmente, ningún paso necesita la red —el licenciamiento por crédito funciona enteramente moviendo archivos dentro y fuera.

Los bloques de crédito aislados son una función Enterprise. El resto de este artículo —verificación de la autolicencia, validación offline del cliente, ejecución con cero tráfico saliente— funciona en Standard y Pro igual de bien; solo la capacidad de bloques de crédito está reservada a Enterprise.

Qué edición, y dónde encaja

Keyright autoalojado se licencia por despliegue entre Standard, Pro y Enterprise. La ejecución totalmente offline descrita aquí no es una función de edición —es cómo funciona el producto en todos los niveles. Standard cubre un único nodo de producción; Pro y Enterprise cubren hasta tres (útil si tu red aislada también quiere alta disponibilidad); y Enterprise añade SSO, marca de etiqueta blanca y los bloques de crédito aislados de arriba. Consulta los precios para las cifras actuales.

Como Keyright es un solo producto en ambos modos de despliegue, nada de tu integración cambia entre una evaluación en portátil y un enclave de producción sellado. Cuando estés listo para levantar uno tras la brecha, la guía de operaciones tiene la lista de verificación aislada, los comandos para mover la imagen y la disciplina de copias de seguridad que convierten una instancia en marcha en una en la que puedes confiar sin forma alguna de llamar al exterior.

Prueba Nebula.NET

Endurece tu código .NET en minutos — empieza con la edición gratuita.