Un experimento para llevar un agente de IA al terreno donde me siento cómodo: contenedores, OpenShift, seguridad por defecto y operación reproducible.

Hace algún tiempo empecé a jugar con agentes de IA. No me refiero solamente a usar un chatbot desde el navegador, sino a ejecutar un agente real, persistente, con estado, credenciales, canales de entrada y salida, y la posibilidad de dejarlo en ejecución como un servicio.

Ahí apareció OpenClaw.

OpenClaw me pareció interesante porque no lo vi solo como otra herramienta para probar prompts. Lo vi como una pieza que podía convertirse en algo más parecido a una aplicación de plataforma: un agente que corre todo el tiempo, recibe mensajes, mantiene la configuración, se conecta a modelos externos y puede integrarse con canales como Telegram.

Pero apenas uno sale del modo demo, aparece la pregunta incómoda: ¿cómo se opera esto de verdad?

Muchos proyectos de este tipo nacen en el mundo del npm install, del docker run, del servidor personal o del tutorial que funciona perfecto mientras todo vive en la laptop del autor. Eso está bien para empezar. De hecho, casi todo lo interesante empieza así. Pero no es la forma en que normalmente pienso sobre la operación de software.

Trabajo todos los días con Linux, contenedores, OpenShift, seguridad, automatización, GitOps y plataformas empresariales. Entonces mi pregunta fue bastante natural: ¿qué pasaría si tratara a OpenClaw como trataría a cualquier otra aplicación que quiero operar en OpenShift?

De ahí nació ShiftClaw.

El repositorio está aquí:

https://github.com/rarguello/shiftclaw

La idea del proyecto

ShiftClaw es mi empaquetado de OpenClaw para correrlo en OpenShift u OKD. No es un fork conceptual de OpenClaw ni pretende reinventar el agente. La idea es construir, alrededor de OpenClaw, las piezas que faltan para operarlo de forma más parecida a la producción.

Eso significa tener una imagen basada en Red Hat UBI 10, construirla con GitHub Actions, publicarla en GHCR, desplegarla con manifiestos de Kubernetes/OpenShift, darle almacenamiento persistente, manejar credenciales con Secrets, sembrar la configuración inicial con ConfigMaps, endurecer el security context y limitar la red con NetworkPolicy.

Dicho de otra forma: ShiftClaw no es solo “metí OpenClaw en un contenedor”. Es el ejercicio de preguntarme cómo debería verse un agente de IA cuando deja de ser un experimento local y empieza a comportarse como una carga de trabajo seria.

Por qué OpenShift

Podría haber dejado todo en un docker run, y de hecho el proyecto también permite correrlo localmente con Podman porque eso es útil para desarrollo y pruebas. Pero mi principal interés era OpenShift.

Un agente persistente se parece más a una aplicación de plataforma que a un script. Tiene estado. Tiene credenciales. Tiene conectividad externa. Tiene lifecycle. Necesita reiniciarse, actualizarse, leer la configuración, escribir datos, reportar logs y sobrevivir a cambios en la infraestructura. En ese punto, las primitivas de Kubernetes y OpenShift dejan de ser “overkill” y pasan a ser el lenguaje natural para el problema.

OpenShift ya tiene muchas de las piezas que necesito: scheduling, restart automático, Secrets, ConfigMaps, PVCs, NetworkPolicy, security contexts, probes, service accounts y límites de recursos. La parte interesante no es usar OpenShift porque sí, sino usarlo para responder una pregunta que cada vez me parece más importante: ¿cómo se opera un agente de IA en infraestructura real?

No en una demo bonita. No en un notebook. No en la laptop. En infraestructura real.

La imagen: UBI 10 y Node.js 24

La primera decisión fue construir la imagen sobre Red Hat UBI 10. No porque tenga algo contra Debian o Ubuntu, sino porque quería que el proyecto encajara naturalmente con OpenShift y con el ecosistema de Red Hat.

El Containerfile usa un build multi-stage. La imagen de builder instala OpenClaw usando Node.js 24, y la imagen final usa una base minimal para ejecutar el agente con menos superficie innecesaria.

ARG OPENCLAW_VERSION=2026.4.23

FROM registry.access.redhat.com/ubi10/nodejs-24:10.1 AS builder

ARG OPENCLAW_VERSION
WORKDIR /opt/app-root/src

USER 0
RUN npm install "openclaw@${OPENCLAW_VERSION}" \
  --omit=dev \
  --no-audit \
  --no-fund \
  && npm cache clean --force

FROM registry.access.redhat.com/ubi10/nodejs-24-minimal:10.1 AS runtime

ARG OPENCLAW_VERSION
WORKDIR /opt/app-root/src

COPY --from=builder --chown=1001:0 /opt/app-root/src/node_modules ./node_modules

USER 0
RUN mkdir -p /var/lib/openclaw \
  && chown 1001:0 /var/lib/openclaw \
  && chmod g=u /var/lib/openclaw

USER 1001

ENV OPENCLAW_VERSION=${OPENCLAW_VERSION} \
  XDG_CONFIG_HOME=/var/lib/openclaw \
  OPENCLAW_CONFIG_PATH=/var/lib/openclaw/openclaw.json \
  NODE_ENV=production \
  NPM_CONFIG_CACHE=/tmp/.npm \
  HOME=/var/lib/openclaw \
  PATH="/opt/app-root/src/node_modules/.bin:$PATH"

EXPOSE 18789

ENTRYPOINT ["openclaw", "gateway", "--allow-unconfigured"]

Hay un detalle importante para OpenShift: la imagen usa el usuario 1001, pero OpenShift puede asignar un UID arbitrario en runtime cuando se usa la SCC restringida. Por eso el directorio persistente queda preparado con grupo 0 y permisos compatibles con ese modelo. Parece un detalle menor hasta que un Pod no puede escribir en el volumen y uno pierde una tarde mirando los logs.

El estado del agente

Un agente sin estado suele ser una demo. Si quiero que OpenClaw funcione como servicio, necesito persistir la configuración y los datos entre reinicios.

En ShiftClaw decidí que el estado viva en /var/lib/openclaw. En OpenShift, ese directorio se monta a partir de un PVC. Ahí queda la configuración viva del agente, incluyendo cosas que no quiero perder cada vez que se recrea el Pod.

Esto también me obligó a tomar una decisión sobre la configuración inicial. Un ConfigMap es muy cómodo para versionar un openclaw.json, pero OpenClaw necesita modificar su configuración en runtime. Si monto el archivo directamente desde el ConfigMap, termino con un archivo de solo lectura y una aplicación peleando contra Kubernetes.

La solución fue usar el ConfigMap como semilla. Un init container copia el archivo inicial al PVC solo si el archivo aún no existe.

command:
  - sh
  - -c
  - '[ -f /var/lib/openclaw/openclaw.json ] || cp /run/config/openclaw.json /var/lib/openclaw/openclaw.json'

Me gusta esta solución porque es simple y explícita. El ConfigMap define el punto de partida, pero después, el estado en vivo pertenece al PVC. Si algún día quiero forzar una nueva configuración desde cero, borro el archivo del PVC y reinicio el StatefulSet. No hay magia, pero hay control.

Por qué usé StatefulSet

Podría haber usado un Deployment, pero un StatefulSet se siente más natural en este caso. No necesito escalar ShiftClaw horizontalmente; por ahora una sola réplica es suficiente. Lo que sí necesito es identidad estable y almacenamiento persistente asociados al Pod.

Un agente con pairing de Telegram, configuración en vivo y estado local no se siente como una aplicación stateless cualquiera. Se parece más a un pequeño servicio persistente. Por eso preferí un StatefulSet con un PVC de 5 Gi. No es una arquitectura sofisticada, pero sí la adecuada para este primer objetivo.

Telegram como interfaz y no exponer una Route

Una de las decisiones que más me gustaron fue no exponer ShiftClaw a través de una Route desde el inicio.

El agente se maneja por Telegram, así que no necesito publicar una interfaz web en Internet, ni abrir una Route en OpenShift, ni resolver de inmediato el TLS público, la autenticación web o la exposición accidental. El gateway interno escucha en el puerto 18789, pero para la operación normal no necesito exponerlo fuera del clúster.

Cuando necesito acceso local, uso port-forward.

oc port-forward pod/shiftclaw-0 18789:18789 -n shiftclaw

Esta decisión reduce considerablemente la superficie de ataque inicial. No significa que Telegram sea perfecto ni que sea la única interfaz posible. Significa que, para este experimento, me permite operar el agente sin abrir más puertas de las necesarias.

Seguridad desde el primer manifiesto

Si voy a correr un agente de IA con tokens y acceso a servicios externos, no quiero que el YAML sea el típico manifiesto de demo que corre como root, con filesystem writable, capacidades por defecto y un service account token montado sin razón.

ShiftClaw corre como non-root, usa RuntimeDefault como seccomp profile, no permite privilege escalation, elimina capabilities y usa root filesystem de solo lectura.

securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault

Y dentro del contenedor:

securityContext:
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop:
      - ALL

También deshabilité el montaje automático del token del ServiceAccount.

automountServiceAccountToken: false

Ese último punto me parece especialmente importante. Si el agente no necesita comunicarse con la API de Kubernetes, no hay razón para entregarle un token del clúster. Es una de esas pequeñas decisiones que reducen el riesgo sin complicar demasiado la operación.

Como el filesystem raíz es de solo lectura, las rutas que requieren escritura se montan explícitamente. El estado vive en el PVC y /tmp vive en un emptyDir. Eso obliga a que el manifiesto diga la verdad sobre lo que la aplicación necesita registrar.

NetworkPolicy y salida controlada

También agregué una NetworkPolicy. La idea no es crear una cárcel perfecta, sino adoptar una postura razonable: no aceptar tráfico entrante y permitir únicamente la salida que el agente necesita para funcionar.

En OpenShift con OVN-Kubernetes hay un detalle importante para DNS: hay que permitir el tráfico hacia openshift-dns, normalmente en UDP 5353. Después de eso, el agente necesita HTTPS para comunicarse con servicios externos como Telegram y OpenRouter.

- to:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: openshift-dns
    podSelector:
      matchLabels:
        app: dns
  ports:
  - port: 5353
    protocol: UDP

La tentación en un laboratorio siempre es abrir todo y avanzar. A veces toca hacerlo para diagnosticar. Pero si desde el inicio sé que el agente solo necesita resolver DNS y salir por HTTPS, prefiero que el manifiesto lo refleje.

Build automático y GHCR

No quería que la imagen dependiera de builds manuales en mi laptop. Por eso el repo incluye un workflow de GitHub Actions que construye la imagen y la publica en GitHub Container Registry.

El workflow fija la versión de OpenClaw en una variable, construye para linux/amd64 y linux/arm64, genera SBOM y provenance y ejecuta Trivy contra la imagen. La política de escaneo intenta ser práctica: reportar severidades relevantes, pero fallar el pipeline solo por vulnerabilidades críticas.

Ese balance me gusta porque evita que el pipeline se convierta en ruido permanente, pero mantiene una barrera clara frente a problemas graves.

Despliegue en OpenShift

El despliegue está pensado para ser directo. Primero creo el namespace, luego creo el Secret desde un .env local y después aplico los manifiestos con Kustomize.

oc apply -f manifests/namespace.yaml

oc create secret generic shiftclaw \
  --from-env-file=.env \
  --namespace=shiftclaw

oc apply -k manifests/

El .env no se commitea. Ahí van valores como el token de Telegram, la API key de OpenRouter y el token interno del gateway.

Para mirar el arranque uso los comandos de siempre.

oc get pods -n shiftclaw -w
oc logs -l app.kubernetes.io/name=shiftclaw -n shiftclaw -f

Al primer arranque, OpenClaw requiere aprobar el emparejamiento con Telegram. El código aparece en los logs y la aprobación se realiza dentro del Pod.

oc exec -it shiftclaw-0 -n shiftclaw -- sh
openclaw pairing approve telegram <PAIRING_CODE>

Una vez aprobado, esa información queda en el PVC. El Pod puede reiniciarse sin perder el emparejamiento.

Correrlo localmente con Podman

Aunque el objetivo principal es OpenShift, también quería una forma sencilla de probar ShiftClaw localmente. Para eso dejé un run.sh que corre la imagen con Podman, monta estado persistente desde el home del usuario, carga secretos desde .env y expone el gateway en localhost:18789.

El flujo local empieza por copiar el archivo de ejemplo y editar las credenciales.

cp .env.example .env
./run.sh

Si quiero probar una imagen construida localmente, puedo hacerlo sin alterar demasiado el flujo.

podman build -t localhost/shiftclaw:dev .
./run.sh localhost/shiftclaw:dev

Esto me permite iterar rápido sin tener que desplegar cada cambio en un clúster. Para mí es importante que el proyecto tenga ese doble camino: local para desarrollo, OpenShift para operación.

Quadlet como punto intermedio

También dejé una opción para ejecutar ShiftClaw como servicio de usuario con systemd mediante Quadlet. Me gusta mucho ese modelo porque es un punto intermedio entre “lo corro a mano” y “lo despliego en OpenShift”.

Con Quadlet puedo dejar el agente corriendo de forma persistente en una máquina Linux, sin root y sin clúster.

mkdir -p ~/.local/share/shiftclaw
cp config/openclaw.json ~/.local/share/shiftclaw/openclaw.json

mkdir -p ~/.config/shiftclaw
cp .env.example ~/.config/shiftclaw/env

mkdir -p ~/.config/containers/systemd
cp shiftclaw.container ~/.config/containers/systemd/

loginctl enable-linger

systemctl --user daemon-reload
systemctl --user enable --now shiftclaw

Los logs quedan en journald.

journalctl --user -u shiftclaw -f

No todo experimento necesita empezar en Kubernetes. A veces Podman y systemd son suficientes. Pero diseñar el proyecto para que pueda moverse entre esos mundos me parece valioso.

Qué me dejó este experimento

La primera conclusión es que un agente de IA deja de ser un juguete en el momento en que cuenta con tokens, estado, red y persistencia. En ese punto ya estás operando una aplicación, aunque se llame “agente” y hable por Telegram.

La segunda conclusión es que OpenShift calza muy bien con este tipo de carga. A veces pensamos en OpenShift solo para aplicaciones empresariales tradicionales, pero un agente persistente también necesita las mismas primitivas: Pod, Secret, PVC, NetworkPolicy, probes, límites y políticas de seguridad.

La tercera conclusión es que el estado es el centro del problema. Me interesa mucho la idea de que el agente tenga una especie de “alma” que no dependa del compute. Si mañana reemplazo el Pod, la imagen, el nodo o incluso el clúster, debería poder conservar su estado y configuración. Por ahora esa alma vive en un PVC. Más adelante quiero experimentar con opciones externas como S3, Redis o algún sistema de memoria más explícito.

Y la cuarta conclusión es que conviene diseñar la seguridad desde el primer manifiesto. Es mucho más fácil empezar con non-root, filesystem de solo lectura, capabilities eliminadas, NetworkPolicy y Secrets fuera de la imagen que intentar endurecer todo cuando el proyecto ya creció.

Lo que quiero explorar después

ShiftClaw todavía es un laboratorio, pero ya tiene forma de proyecto real. Lo siguiente que quiero investigar es cómo dar acceso controlado a un navegador, cómo limitar mejor el tráfico outbound con un proxy, cómo manejar la memoria externa, cómo desplegarlo con GitOps, cómo firmar imágenes con Cosign y cómo integrar MCPs útiles sin convertir el agente en una caja negra con demasiados permisos.

También quiero seguir probando modelos. OpenRouter facilita cambiar de backend, pero cada modelo se comporta de manera distinta. No todos sirven para el mismo tipo de agente ni para el mismo estilo de interacción.

El objetivo no es tener un bot simpático en Telegram. El objetivo es entender cómo operar agentes de IA con prácticas de infraestructura reales.

Correr un agente es fácil. Correrlo de forma persistente, reproducible, segura, actualizable y observable ya es otro tema.

ShiftClaw es mi primer intento de llevar OpenClaw a ese terreno. Y como todo buen experimento de infraestructura, seguro que todavía se va a romper varias veces.

Por eso, justamente, vale la pena documentarlo.