Airframe

Por qué Airframe

Cero privilegios permanentes

Ninguna cuenta de uso diario de una persona, incluida la de un mantenedor, tiene un rol que pueda cambiar la infraestructura de producción. Fuera de una concesión con tiempo limitado, lo que la cambia es un job de pipeline cuya identidad de corta duración está vinculada a un repositorio, una ref protegida y un entorno.

Cómo un job obtiene una identidad, y cómo una persona obtiene acceso

  1. Un job demuestra dónde se ejecuta

    Un job de pipeline le pide a GitLab un token firmado que nombra su repositorio, su entorno y si su ref está protegida. La federación de identidades de cargas de trabajo de Google Cloud verifica el token; un token de fuera del grupo projectairframe, incluido el de un fork en un espacio de nombres personal, se rechaza antes de leer cualquier vinculación.

  2. Una identidad de apply responde a un solo repositorio

    Cada identidad de apply está vinculada al repositorio de su producto, en una ref protegida, en su propio entorno: la de producción responde a jobs en el entorno prod, y en grafana para los paneles del producto. Un job en una rama no protegida, en otro repositorio o en otro entorno no obtiene nada.

  3. Sin claves

    No se pueden crear ni subir claves de cuentas de servicio: una política de la organización en la carpeta de la organización de demostración prohíbe ambas cosas, y una política de denegación bloquea la creación de claves para todos salvo el grupo de acceso de emergencia, la cuenta de administrador del arranque y el agente de servicio de Privileged Access Manager. Las credenciales vienen del token del job o del servidor de metadatos.

  4. Las personas reciben concesiones, no roles administrativos permanentes

    Un mantenedor que necesita cambiar algo solicita una concesión de Privileged Access Manager con una justificación. Una concesión de roles administrativos necesita la aprobación de otro miembro del grupo de plataforma y dura como máximo dos horas; el acceso de lectura a los registros y al estado de un proyecto de no producción lo aprueba el propio solicitante y dura una hora. Cada concesión queda en el registro de auditoría.

  5. Una imagen se atesta y luego se admite

    El compilador de confianza compila cada imagen a partir del commit aprobado. El ejecutor revisa el registro de Cloud Build de esa compilación antes de que una identidad separada firme la atestación de compilación, y la promoción agrega una segunda. Cada servicio que despliega el módulo de Cloud Run del golden path se acoge a la política de Binary Authorization de su proyecto, que en producción admite solo una imagen con ambas; la política se escribe una vez que los proyectos de un producto tienen facturación. La compuerta de aprobación y este sitio web funcionan con la misma regla.

  6. Una versión defectuosa se puede revocar

    Las herramientas de pipeline de la plataforma se publican como versiones con fecha. Revocar una, con un merge request a la lista de versiones permitidas, hace que la compuerta de aprobación haga fallar cada nuevo pipeline que aún la incluya, y nombra la versión a la que hay que pasar.

Pruébalo

Elige un job de GitLab. Esta es la identidad que puede obtener, si alguna, según las vinculaciones que declara el código de la plataforma en la versión que describe este sitio.

projectairframe/shop/store/ordering/orders · prod · protegida

Puede obtener orders-apply@lk-store-orders-8k2p.iam.gserviceaccount.com

mediante la vinculación del repositorio, el entorno y la ref protegida

Atributo: attribute.airframe/projectairframe/shop/store/ordering/orders/prod/true

Qué lo hace cierto

Ninguna cuenta de uso diario de una persona tiene un rol permanente que pueda cambiar la infraestructura de producción.
La raíz de carpetas y las fábricas de proyectos otorgan a las personas roles de lector y de lector de registros, y la plantilla del producto permite que un equipo agregue versiones de sus secretos de producción, nunca que las lea. Los roles administrativos llegan a las personas solo mediante concesiones de Privileged Access Manager. La administración de la organización queda en una única cuenta de administrador dedicada, usada solo para el arranque y los procedimientos excepcionales; un job programado de Policy Analyzer falla si, en el nodo de la organización, esa cuenta tiene cualquier rol salvo Organization Administrator, o cualquier otra persona o grupo tiene un rol permanente.
Solo un job del propio repositorio del producto, en una ref protegida y en el entorno correcto, puede obtener su identidad de apply.
La fábrica de proyectos vincula cada identidad de apply al atributo compuesto de ruta del repositorio, entorno y protección de la ref, solo con el valor protegido; el proveedor del grupo de identidades rechaza cualquier token de fuera del grupo projectairframe.
No se puede crear ni subir ninguna clave de cuenta de servicio bajo la carpeta de la organización de demostración.
Las políticas de la organización en la carpeta desactivan la creación y la subida de claves para todo principal, y una política de denegación de IAM bloquea la creación de claves para todos salvo el grupo de acceso de emergencia, la cuenta de administrador del arranque y el agente de servicio de Privileged Access Manager.
El acceso administrativo de un mantenedor dentro de la carpeta de la organización de demostración es temporal, y lo aprueba otro miembro del grupo de plataforma.
Las autorizaciones de Privileged Access Manager que otorgan roles administrativos requieren la aprobación de otro miembro del grupo de plataforma, nunca la de la propia cuenta del solicitante, y duran como máximo dos horas; la única autorización de nivel 1, en el proyecto de no producción lk-runtime-np de la plataforma, otorga acceso de lectura a ese proyecto durante una hora, y la aprueba el propio solicitante.
Un servicio de producto desplegado mediante el golden path ejecuta solo una imagen que la plataforma compiló y promovió.
El módulo de Cloud Run del golden path acoge cada servicio a la política de Binary Authorization que tenga su proyecto, que en el proyecto de producción de un producto con facturación se aplica y exige las atestaciones build y promote; la raíz trusted-builder permite firmar con sus claves solo a la identidad que firma la atestación de compilación y al promotor de artefactos.
Una versión revocada no ejecuta ningún pipeline nuevo.
El job de integridad de la compuerta de aprobación, que la política de ejecución de pipelines del grupo inyecta en cada pipeline, lee las versiones permitidas en el main de control-plane y hace fallar un pipeline que incluya una revocada; el ejecutor hace la misma verificación antes de que una ejecución de merge request o de versión tenga las credenciales de un producto.