La credencial de la CI en un paso y versiones firmadas

Un job de GitHub Actions ya puede conseguir su credencial de kubelatch en un solo paso, con la action picaportelabs/kubelatch-action, en vez de las 25 líneas de curl y jq que había que copiar en cada repositorio. Y desde la 0.44, cada versión de kubelatch sale firmada y con su SBOM, la lista de lo que lleva dentro. Te cuento cómo funciona cada cosa, cómo se comprueba, qué han traído la 0.41, la 0.42 y la 0.43, y hasta dónde llega todo esto.

Veinticinco líneas de curl en cada repositorio

Si ya has conectado un workflow a kubelatch, lo habrás hecho con los dos pasos de bash del manual, los que conté en De GitHub Actions a Kubernetes sin ningún secreto: el primero pide a GitHub el token OIDC del job, y el segundo lo canjea en kubelatch, enmascara la credencial y escribe el kubeconfig. Funcionan, pero son 25 líneas de curl y jq que cada equipo copia en cada repositorio, revisa y luego tiene que mantener.

Con la action, todo eso cabe en un paso:

permissions:
  id-token: write
  contents: read

jobs:
  pods:
    runs-on: ubuntu-latest
    steps:
      - uses: picaportelabs/kubelatch-action@v1
        with:
          url: https://kubelatch.example.com
      - run: kubectl get pods -n default

La action hace lo mismo que aquellos dos pasos. Pide a GitHub el token del job con la URL de tu kubelatch como audiencia, lo canjea una sola vez y enmascara los dos secretos antes de escribir nada en el log. Deja el kubeconfig en una carpeta propia del job, nunca en ~/.kube/config, y apunta KUBECONFIG a él. A partir de ahí, kubectl, helm y cualquier herramienta que lea KUBECONFIG entran en el cluster como el bot de tu regla de confianza, y cada petición queda en la auditoría.

Sirve con cualquier kubelatch que tenga reglas de confianza, porque hace el mismo canje que los pasos de curl. La 0.44 la pone en la pantalla «CI»: ya la traen el «Fragmento del workflow» que kubelatch rellena tras «Crear regla» y el «Workflow de ejemplo». Para un workflow nuevo, cópialo; en uno que ya tienes, cambia los dos pasos por el de la action.

Una action que se puede leer entera

Una action de terceros se ejecuta con los permisos de tu job, así que conviene leerla antes de dárselos. Son dos ficheros cortos de JavaScript, src/main.js y src/action.js, sin dependencias y con licencia MIT. Sus pruebas pasan en runners de Linux, macOS y Windows; en Linux y macOS comprueban además que la carpeta del kubeconfig solo la puede leer el usuario del job. En un runner propio, la action confía en el almacén de certificados del sistema, que es donde suele estar la CA de tu empresa, y sale por HTTPS_PROXY si lo tienes configurado. Si tu política de seguridad lo pide, fíjala por commit en lugar de @v1.

Cuando kubelatch rechaza el canje, el error de la action trae el motivo y un enlace a la sección del manual que lo explica (la página en inglés). Si es un 403 porque no encaja ninguna regla, te dice con qué tiene que coincidir: los ids del propietario y del repositorio, la ref y el entorno. Un 401 casi siempre quiere decir que url no es exactamente la del servidor.

Si tu organización solo permite sus propias actions, los dos pasos de curl siguen en Credenciales para GitHub Actions y funcionan igual.

Versiones firmadas y con su SBOM

Desde la 0.44, cada versión de kubelatch va firmada con cosign y trae sus SBOM en CycloneDX 1.6:

• El fichero de sumas SHA-256 va firmado. Cubre todos los .tar.gz y las SBOM de la versión, así que con esa firma compruebas cualquier binario que descargues.
• La imagen ghcr.io/picaportelabs/kubelatch y el chart van firmados, y la imagen lleva la SBOM del servidor como atestación firmada.
• Hay una SBOM del servidor, con los módulos de Go y los paquetes npm de la interfaz web (sin los de desarrollo), y otra de la CLI.

Para comprobar la imagen antes de desplegarla basta una línea, con cosign 3 o posterior:

cosign verify --key cosign.pub ghcr.io/picaportelabs/kubelatch:0.44.0

La clave pública está escrita en Verificar una release. Guarda esa copia junto a tus pipelines y compara siempre con ella: si la bajas del mismo sitio que la versión, quien pudiera cambiar una podría cambiar también la otra. En la misma página tienes cómo comprobar los binarios y cómo sacar la SBOM de la imagen para pasársela a Dependency-Track, Grype o Trivy.

Firmo las versiones y publico sus SBOM ahora por dos motivos. Con la SBOM en tu Dependency-Track te enteras de una vulnerabilidad en una dependencia de kubelatch sin esperar a que yo te avise. Y el Reglamento de Ciberresiliencia de la UE exigirá a los fabricantes, a partir del 11 de diciembre de 2027, una SBOM en un formato legible por máquina; no les obliga a publicarla, pero kubelatch la publica.

Lo que han traído la 0.41, la 0.42 y la 0.43

Desde la 0.43, «Auditoría» y «Mi actividad» enseñan de qué comando sale cada petición. Una fila dice patch deployments/api (shop) y, al lado, «vía rollout restart». Las peticiones de una misma ejecución de kubectl se pliegan en una sola fila. El comando es el que declara el propio kubectl desde la 1.22; helm, k9s y Lens no declaran ninguno, y sus filas siguen como estaban. Lo explica Auditoría y retención.

La 0.41 te deja resolver varias solicitudes de agentes a la vez: en «Agentes» marcas las filas y las apruebas o deniegas con una sola confirmación. Un lote solo junta escrituras que comparten agente, cluster, herramienta, recurso y namespace. Lo demás se sigue aprobando de una en una, con su diff delante.

En el móvil, «Mis accesos» muestra desde la 0.42 un bloque plegado por cluster. Además, el docker-compose.yaml del tutorial local ya no fija una versión: arranca la que pongas en KUBELATCH_VERSION, para que el servidor coincida con la CLI que te has descargado.

Las notas completas de cada versión, en español y en inglés, están en Novedades.

Lo que esto no resuelve

• La action no revoca la credencial al acabar el job. El runner borra el kubeconfig al terminar, pero la credencial vale hasta que caduca, a la hora por defecto: si algún paso del job la copió, esa copia sirve hasta entonces. Para cortarla antes, un administrador la revoca en «Credenciales».
• Las firmas empiezan en la 0.44.0: la 0.43.0 y las anteriores no traen firma ni SBOM, solo el fichero de sumas.
• La SBOM de la imagen recoge lo que kubelatch añade a su imagen base, gcr.io/distroless/static-debian12, y no la base en sí. Para esa capa, pasa tu escáner por la imagen como siempre.

Pruébalo

Si ya usas kubelatch, cambia los dos pasos de tu workflow por la action siguiendo Credenciales para GitHub Actions; para eso no hace falta actualizar. Para pasar a la 0.44, comprueba antes la imagen y el chart con Verificar una release y actualiza como siempre, con helm upgrade: la base de datos se migra sola al arrancar, y el rollout corta los exec y port-forward abiertos. En Free, los bots y las reglas de confianza no tienen límite.

Si todavía no lo tienes, con el tutorial local lo montas en tu máquina, con un cluster de kind de usar y tirar, en unos quince minutos, más las descargas de la primera vez.

kubelatch se desarrolla en Picaporte Labs, en España. Si algo no cuadra con lo que ves, escríbeme a hola@picaportelabs.com o a hello@kubelatch.com.