Identidades y acceso

En Airframe, ninguna cuenta de uso diario puede cambiar la infraestructura de producción, y ninguna máquina tiene una contraseña que funcione para siempre. Los pipelines reciben identidades que duran una hora y solo sirven para un trabajo; las personas pueden mirar, y cuando de verdad necesitan cambiar algo a mano, piden un acceso con tiempo limitado, aprobado por otra persona y registrado. Esta página explica cómo funcionan las dos cosas, un nivel más abajo que la página de cero privilegios permanentes.

Quién actúa sobre la plataforma

Tres tipos de identidad tocan Google Cloud:

Las identidades de pipeline son cuentas de servicio de Google con las que se ejecuta Terraform. Cada raíz de la plataforma tiene la suya, como la de la fábrica de proyectos, y cada producto tiene sus propias identidades de plan y de apply en cada uno de sus proyectos.
Las identidades de ejecución pertenecen a los servicios en funcionamiento de un producto. Cada servicio recibe la suya, con exactamente los secretos, la base de datos y los tópicos que usa.
Las personas inician sesión con sus cuentas de la organización. Su acceso llega mediante grupos de Google que llenan los reconciliadores del catálogo, como el grupo de un equipo o el grupo de los usuarios de un producto.

Cómo un trabajo de pipeline obtiene una identidad

Un trabajo de pipeline nunca tiene una clave. En cambio, usa la federación de identidades de carga de trabajo:

El trabajo le pide a GitLab un token firmado. El token dice a qué repositorio pertenece el trabajo, en qué entorno despliega y si su rama está protegida.
El proveedor de identidades de Google Cloud revisa el token. Un token de fuera del grupo projectairframe en GitLab se rechaza antes de leer cualquier otra cosa, así que una copia de un repositorio en el espacio personal de alguien no recibe nada.
El proveedor combina los tres datos en un solo valor, por ejemplo, el repositorio de pedidos, el entorno prod y true para protegida. Cada identidad está vinculada a exactamente uno de esos valores.
Si el valor coincide, el trabajo recibe un token de acceso para esa única identidad, válido por una hora.

Un trabajo en una rama sin protección, en otro repositorio o en otro entorno no coincide con ningún vínculo y no recibe nada. Un repositorio renombrado pierde sus vínculos, y la ruta de un producto eliminado nunca se reutiliza, así que un repositorio nuevo no puede heredar el acceso de uno viejo.

Identidades de plan e identidades de apply

Cada producto tiene dos identidades de pipeline en cada uno de sus proyectos:

La identidad de plan puede leer el proyecto y el estado de Terraform, y no cambia nada. No está vinculada a ningún repositorio: solo el ejecutor puede usarla, cuando la compuerta de aprobación inicia una ejecución al aprobarse un merge request.
La identidad de apply puede cambiar el proyecto. La de producción solo responde a un trabajo del propio repositorio del producto, en una rama protegida, en el entorno prod, o grafana para la raíz que publica los paneles del producto. La de no producción responde a np, y el ejecutor también la usa para construir la vista previa de un merge request.

El ejecutor puede usar todas las identidades de plan y todas las identidades de apply de no producción, y ninguna identidad de apply de producción. Así, nada de lo que se ejecuta antes de un merge puede cambiar producción.

Qué reciben las personas

Los roles permanentes de las personas son roles de lectura: pueden ver un proyecto y sus registros, no cambiarlo. La única excepción, muy acotada, es que el equipo de un producto puede agregar una versión nueva de uno de los secretos del producto; nunca puede leer uno.

Cuando una persona necesita más, pide una concesión de Privileged Access Manager con un motivo escrito. Airframe tiene cuatro tipos:

Concesión	Qué da, quién la aprueba y cuánto dura
Nivel 1	Lectura de los registros, métricas y estado de un proyecto de no producción, hoy solo el proyecto de ejecución de la plataforma, `lk-runtime-np`. Aprobada por: quien la pide, con un motivo. Dura: 1 hora.
Nivel 2	Roles administrativos en la carpeta de la organización de demostración, para una corrección a mano. Aprobada por: otro miembro del grupo de plataforma. Dura: 2 horas.
Apply de plataforma	Los roles para las pocas raíces de la plataforma que todavía se aplican desde una laptop. Aprobada por: otro miembro del grupo de plataforma. Dura: 2 horas.
Organización	Los roles para cambios a nivel de la organización. Aprobada por: otro miembro del grupo de plataforma. Dura: 2 horas.

Los miembros del grupo de emergencia, lk-breakglass@, pueden pedir las tres primeras concesiones. La concesión de organización la piden los miembros del grupo de plataforma, lk-platform@, y todas las aprobaciones vienen también de ese grupo. Privileged Access Manager nunca deja que quien pide apruebe su propio pedido en las concesiones que necesitan aprobación. Toda concesión queda en el registro de auditoría.

Hoy el nivel 1 existe solo en el proyecto de ejecución de no producción de la plataforma. Ninguna fábrica de proyectos lo crea todavía para el proyecto de no producción de un producto, así que las concesiones de nivel 1 en los proyectos de los productos están diseñadas.

Tres raíces de la plataforma todavía se aplican desde una laptop con una concesión así: las políticas de la organización, la configuración de auditoría y la raíz que crea el proveedor de identidades y la identidad de cada raíz de la plataforma. Un pipeline que pudiera reescribir el modelo de identidades sería el más poderoso de la plataforma, así que queda detrás de una segunda persona. Cada una de estas raíces se planifica todos los días en un pipeline programado cuya identidad solo puede leer, así que un cambio hecho con una concesión aparece como deriva en menos de un día.

Hoy una sola persona opera la plataforma, y el segundo aprobador es la segunda cuenta del mantenedor: el mecanismo se aplica, pero la separación entre dos personas todavía no es real.

Sin claves

Una clave de cuenta de servicio es una contraseña de larga duración para una identidad de máquina, y Airframe no permite ninguna. Las políticas de organización en la carpeta de la organización de demostración prohíben crear o subir claves, y una política de denegación bloquea la creación de claves para todos excepto el grupo de emergencia, la cuenta de administrador del arranque y el propio agente de servicio de Privileged Access Manager. El paquete de políticas también rechaza una clave declarada en Terraform. Las credenciales vienen del token de un trabajo o, para un servicio en funcionamiento, del servidor de metadatos del lugar donde se ejecuta.

La única cuenta de administrador

Una cuenta dedicada tiene Organization Administrator, el rol más alto de la organización. Se usa solo para el arranque y para procedimientos excepcionales, y el resto del tiempo tiene la sesión cerrada. Un trabajo programado en el repositorio landing-zone le pregunta todos los días a Policy Analyzer de Google quién tiene qué rol en la organización, y falla si alguna persona tiene allí un rol distinto del Organization Administrator de esa cuenta, o si algún grupo tiene uno.

Dónde está

En el repositorio landing-zone: