4 publicaciones etiquetados con "identidad"

+

La Parte 5 le dio a un agente su propia identidad en el gateway: un token emitido por authentik con client credentials, con un scope, y que expira a los cinco minutos. Terminó nombrando lo que no había cubierto — el servidor de herramientas MCP de la parte 4 de orquestación de agentes sigue fiándose de cualquier cosa que alcance su puerto, issue_refund incluido.

Aquel post fue explícito sobre el límite de lo que había construido:

The MCP server still trusts everyone. Scoping happens in the client. Anything that can reach 127.0.0.1:8770 can call issue_refund directly, agent or not.

Repartir la caja de herramientas por rol impidió que un agente alcanzara una herramienta que no le tocaba. No hizo nada contra un curl. Esta parte cierra eso.

+

La Parte 4 puso control de acceso por grupos sobre la interfaz de administración del gateway y después, al final, llamó a la API desde un shell sin cuenta, sin sesión y sin grupo. Respondió con normalidad. La conclusión fue que el SSO protege un plano de control y que el plano de datos autentica a quien llama por máquina con claves — cosa que tiene que hacer, porque un agente que corre a las 3 de la mañana no puede completar un login en un navegador.

Eso era cierto y era también un punto y aparte, no una respuesta. "Los clientes máquina usan claves" te deja con una credencial que nunca expira, que ningún proveedor de identidad conoce, y que sobrevive a la persona que la creó. La Parte 4 lo dijo sin rodeos: sacar a alguien de un grupo no revoca sus claves, una clave filtrada no se ve afectada por la identidad en absoluto, y las claves sobreviven a las personas.

Esta parte le da a la máquina una identidad en lugar de una clave.

authentik le emite al agente un token con el flujo de client credentials — sin navegador, sin pantalla de consentimiento, sin humano. El token va firmado, lleva un scope y expira a los cinco minutos. El gateway lo verifica localmente contra las claves públicas de authentik y rechaza cualquier cosa sin el scope correcto. Al final, tres códigos de estado enseñan el límite aguantando.

+

La Parte 3 puso authentik delante de Langfuse y terminó con una confesión: el paso de vinculaciones quedó vacío, así que cualquier cuenta de authentik podía llegar a Langfuse y nada te avisaría.

Esta parte cierra ese hueco en la gateway LiteLLM — y el cierre salió mal de una forma que vale más que el procedimiento. Configuramos las vinculaciones en el asistente de authentik, las vimos aparecer en la tabla del propio asistente, enviamos, y acabamos con cero vinculaciones guardadas. La aplicación estaba abierta a todo el mundo, la interfaz no dijo nada, y la única razón por la que lo descubrimos es que probamos con una cuenta que debería haber sido rechazada y no lo fue.

Después, ya con el control de acceso funcionando de verdad, llamamos a la API del gateway desde un shell sin cuenta, sin sesión y sin grupo. Respondió con normalidad. Eso no es un fallo — es la diferencia entre un plano de control y un plano de datos, y suponer que el SSO cubre ambos es cómo la gente concluye que ha asegurado algo que no ha asegurado.

+

La Parte 1 cerró los puertos que nadie quiso abrir. La Parte 2 impidió que dos contenedores se ejecutaran como root. Ambas trataban sobre la máquina. Ninguna tocó la pregunta que una pila de IA autoalojada responde peor: ¿quién tiene permiso para iniciar sesión, y dónde se decide eso?

La misma caja de antes. El Langfuse que venimos endureciendo desde la Parte 1 — aquel cuyo Postgres, ClickHouse y Redis la Parte 1 encontró correctamente enlazados a localhost, y cuyo worker la Parte 2 bajó de root — se desplegó en Detecta lo que tus pruebas no ven. Dos partes han asegurado ya la máquina por debajo sin tocar ni una vez la puerta de entrada de la propia aplicación. Esta es la primera parte que cambia Langfuse en sí.

Ahora mismo esa decisión se toma en cada app, por separado. Langfuse tiene su propia tabla de correo y contraseña. También la tiene cualquier otra herramienta en la caja. Cada una es un lugar donde una cuenta puede sobrevivir a la persona que la tenía, donde una contraseña puede reutilizarse, y donde "quitarle el acceso a esta persona" significa acordarse de que esa app existe.

Este post mueve esa decisión a un solo lugar. Ese lugar es authentik — un proveedor de identidad de código abierto que ejecutas tú mismo, la contraparte autoalojada de Okta o Auth0. Guarda las cuentas, muestra la pantalla de inicio de sesión, y da fe de quién es alguien ante cualquier app que pregunte. Las apps dejan de almacenar contraseñas y empiezan a preguntarle a authentik.

Es el mismo trabajo que hace Keycloak, y Keycloak es el nombre más conocido. authentik se gana la elección aquí por el coste de puesta en marcha: un archivo compose y un asistente frente a los realms, clients y ajustes de JVM de Keycloak. Para una caja y una app, esa diferencia es toda la decisión.

Lo desplegamos, conectamos Langfuse a él por OIDC, y terminamos con un inicio de sesión que pasa por authentik y vuelve.