Basic Github Information
Estructura Básica
La estructura básica del entorno de github de una empresa grande es poseer una empresa que tiene varias organizaciones y cada una de ellas puede contener varios repositorios y varios equipos. Las empresas más pequeñas pueden tener solo una organización y ninguna empresa.
Desde el punto de vista de un usuario, un usuario puede ser miembro de diferentes empresas y organizaciones. Dentro de ellas, el usuario puede tener diferentes roles de empresa, organización y repositorio.
Además, un usuario puede ser parte de diferentes equipos con diferentes roles de empresa, organización o repositorio.
Y finalmente, los repositorios pueden tener mecanismos de protección especiales.
Privilegios
Roles de Empresa
Propietario de la empresa: Las personas con este rol pueden gestionar administradores, gestionar organizaciones dentro de la empresa, gestionar configuraciones de la empresa, hacer cumplir políticas en las organizaciones. Sin embargo, no pueden acceder a la configuración o contenido de la organización a menos que se les haga propietario de la organización o se les dé acceso directo a un repositorio propiedad de la organización.
Miembros de la empresa: Los miembros de las organizaciones propiedad de tu empresa también son automáticamente miembros de la empresa.
Roles de Organización
En una organización, los usuarios pueden tener diferentes roles:
Propietarios de la organización: Los propietarios de la organización tienen acceso administrativo completo a tu organización. Este rol debe ser limitado, pero no menos de dos personas, en tu organización.
Miembros de la organización: El rol predeterminado, no administrativo para personas en una organización es el miembro de la organización. Por defecto, los miembros de la organización tienen una serie de permisos.
Gerentes de facturación: Los gerentes de facturación son usuarios que pueden gestionar la configuración de facturación de tu organización, como la información de pago.
Gerentes de seguridad: Es un rol que los propietarios de la organización pueden asignar a cualquier equipo en una organización. Cuando se aplica, otorga a cada miembro del equipo permisos para gestionar alertas y configuraciones de seguridad en toda tu organización, así como permisos de lectura para todos los repositorios en la organización.
Si tu organización tiene un equipo de seguridad, puedes usar el rol de gerente de seguridad para dar a los miembros del equipo el acceso mínimo que necesitan a la organización.
Gerentes de Github App: Para permitir que usuarios adicionales gestionen Github Apps propiedad de una organización, un propietario puede otorgarles permisos de gerente de Github App.
Colaboradores externos: Un colaborador externo es una persona que tiene acceso a uno o más repositorios de la organización pero no es explícitamente miembro de la organización.
Puedes comparar los permisos de estos roles en esta tabla: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles
Privilegios de los Miembros
En https://github.com/organizations/<org_name>/settings/member_privileges puedes ver los permisos que los usuarios tendrán solo por ser parte de la organización.
La configuración aquí establecida indicará los siguientes permisos de los miembros de la organización:
Ser administrador, escritor, lector o sin permiso sobre todos los repositorios de la organización.
Si los miembros pueden crear repositorios privados, internos o públicos.
Si es posible hacer fork de los repositorios.
Si es posible invitar a colaboradores externos.
Si se pueden publicar sitios públicos o privados.
Los permisos que los administradores tienen sobre los repositorios.
Si los miembros pueden crear nuevos equipos.
Roles de Repositorio
Por defecto se crean roles de repositorio:
Lectura: Recomendado para colaboradores no técnicos que quieren ver o discutir tu proyecto.
Triaje: Recomendado para colaboradores que necesitan gestionar proactivamente problemas y pull requests sin acceso de escritura.
Escritura: Recomendado para colaboradores que participan activamente en tu proyecto.
Mantenimiento: Recomendado para gerentes de proyecto que necesitan gestionar el repositorio sin acceso a acciones sensibles o destructivas.
Administración: Recomendado para personas que necesitan acceso completo al proyecto, incluyendo acciones sensibles y destructivas como gestionar la seguridad o eliminar un repositorio.
Puedes comparar los permisos de cada rol en esta tabla https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role
También puedes crear tus propios roles en https://github.com/organizations/<org_name>/settings/roles
Equipos
Puedes listar los equipos creados en una organización en https://github.com/orgs/<org_name>/teams. Ten en cuenta que para ver los equipos que son hijos de otros equipos necesitas acceder a cada equipo padre.
Usuarios
Los usuarios de una organización pueden ser listados en https://github.com/orgs/<org_name>/people.
En la información de cada usuario puedes ver los equipos de los que el usuario es miembro, y los repositorios a los que el usuario tiene acceso.
Autenticación en Github
Github ofrece diferentes formas de autenticarte en tu cuenta y realizar acciones en tu nombre.
Acceso Web
Accediendo a github.com puedes iniciar sesión con tu nombre de usuario y contraseña (y potencialmente un 2FA).
Claves SSH
Puedes configurar tu cuenta con una o varias claves públicas permitiendo que la clave privada relacionada realice acciones en tu nombre. https://github.com/settings/keys
Claves GPG
No puedes suplantar al usuario con estas claves pero si no las usas podría ser posible que te descubran por enviar commits sin una firma. Aprende más sobre el modo vigilante aquí.
Tokens de Acceso Personal
Puedes generar un token de acceso personal para darle acceso a una aplicación a tu cuenta. Al crear un token de acceso personal el usuario necesita especificar los permisos que el token tendrá. https://github.com/settings/tokens
Aplicaciones Oauth
Las aplicaciones Oauth pueden pedirte permisos para acceder a parte de tu información de github o para suplantarte para realizar algunas acciones. Un ejemplo común de esta funcionalidad es el botón de iniciar sesión con github que podrías encontrar en algunas plataformas.
Puedes crear tus propias aplicaciones Oauth en https://github.com/settings/developers
Puedes ver todas las aplicaciones Oauth que tienen acceso a tu cuenta en https://github.com/settings/applications
Puedes ver los alcances que las aplicaciones Oauth pueden solicitar en https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps
Puedes ver el acceso de aplicaciones de terceros en una organización en https://github.com/organizations/<org_name>/settings/oauth_application_policy
Algunas recomendaciones de seguridad:
Una aplicación OAuth siempre debe actuar como el usuario autenticado de GitHub en todo GitHub (por ejemplo, al proporcionar notificaciones al usuario) y con acceso solo a los alcances especificados.
Una aplicación OAuth puede usarse como un proveedor de identidad habilitando un "Iniciar sesión con GitHub" para el usuario autenticado.
No construyas una aplicación OAuth si quieres que tu aplicación actúe en un repositorio único. Con el alcance
repode OAuth, las aplicaciones OAuth pueden actuar en _todos_** los repositorios del usuario autenticado**.No construyas una aplicación OAuth para actuar como una aplicación para tu equipo o empresa. Las aplicaciones OAuth se autentican como un usuario único, por lo que si una persona crea una aplicación OAuth para que la use una empresa y luego abandona la empresa, nadie más tendrá acceso a ella.
Más información aquí.
Aplicaciones Github
Las aplicaciones Github pueden pedir permisos para acceder a tu información de github o suplantarte para realizar acciones específicas sobre recursos específicos. En las aplicaciones de Github necesitas especificar los repositorios a los que la aplicación tendrá acceso.
Para instalar una aplicación de GitHub, debes ser un propietario de la organización o tener permisos de administrador en un repositorio.
La aplicación de GitHub debe conectarse a una cuenta personal o una organización.
Puedes crear tu propia aplicación de Github en https://github.com/settings/apps
Puedes ver todas las aplicaciones de Github que tienen acceso a tu cuenta en https://github.com/settings/apps/authorizations
Estos son los puntos finales de la API para aplicaciones de Github https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. Dependiendo de los permisos de la aplicación, podrá acceder a algunos de ellos
Puedes ver las aplicaciones instaladas en una organización en https://github.com/organizations/<org_name>/settings/installations
Algunas recomendaciones de seguridad:
Una aplicación de GitHub debe realizar acciones independientes de un usuario (a menos que la aplicación esté utilizando un token de usuario a servidor). Para mantener los tokens de acceso de usuario a servidor más seguros, puedes usar tokens de acceso que expirarán después de 8 horas y un token de actualización que se puede intercambiar por un nuevo token de acceso. Para más información, consulta "Refrescando tokens de acceso de usuario a servidor."
Asegúrate de que la aplicación de GitHub se integre con repositorios específicos.
La aplicación de GitHub debe conectarse a una cuenta personal o una organización.
No esperes que la aplicación de GitHub sepa y haga todo lo que un usuario puede hacer.
No uses una aplicación de GitHub si solo necesitas un servicio de "Iniciar sesión con GitHub". Pero una aplicación de GitHub puede usar un flujo de identificación de usuario para iniciar sesión en los usuarios y hacer otras cosas.
No construyas una aplicación de GitHub si solo quieres actuar como un usuario de GitHub y hacer todo lo que ese usuario puede hacer.
Si estás utilizando tu aplicación con GitHub Actions y quieres modificar archivos de flujo de trabajo, debes autenticarte en nombre del usuario con un token de OAuth que incluya el alcance
workflow. El usuario debe tener permisos de administrador o escritura en el repositorio que contiene el archivo de flujo de trabajo. Para más información, consulta "Entendiendo los alcances para aplicaciones OAuth."Más información aquí.
Github Actions
Esto no es una forma de autenticarse en github, pero una Github Action maliciosa podría obtener acceso no autorizado a github y dependiendo de los privilegios otorgados a la Action se podrían realizar varios ataques diferentes. Ver más abajo para más información.
Git Actions
Git actions permite automatizar la ejecución de código cuando ocurre un evento. Usualmente el código ejecutado está de alguna manera relacionado con el código del repositorio (tal vez construir un contenedor de docker o verificar que el PR no contenga secretos).
Configuración
En https://github.com/organizations/<org_name>/settings/actions es posible verificar la configuración de las acciones de github para la organización.
Es posible deshabilitar completamente el uso de acciones de github, permitir todas las acciones de github, o solo permitir ciertas acciones.
También es posible configurar quién necesita aprobación para ejecutar una Acción de Github y los permisos del GITHUB_TOKEN de una Acción de Github cuando se ejecuta.
Git Secrets
Las Acciones de Github generalmente necesitan algún tipo de secretos para interactuar con github o aplicaciones de terceros. Para evitar ponerlos en texto claro en el repositorio, github permite colocarlos como Secretos.
Estos secretos se pueden configurar para el repositorio o para toda la organización. Luego, para que la Acción pueda acceder al secreto necesitas declararlo así:
Ejemplo utilizando Bash
Los secretos solo pueden ser accedidos desde las Github Actions que los tienen declarados.
Una vez configurados en el repositorio o la organización, los usuarios de github no podrán acceder a ellos de nuevo, solo podrán cambiarlos.
Por lo tanto, la única manera de robar secretos de github es poder acceder a la máquina que está ejecutando la Github Action (en ese escenario solo podrás acceder a los secretos declarados para la Action).
Entornos de Git
Github permite crear entornos donde puedes guardar secretos. Luego, puedes darle acceso a la github action a los secretos dentro del entorno con algo como:
Puede configurar un entorno para ser accedido por todas las ramas (por defecto), solo ramas protegidas o especificar qué ramas pueden acceder a él. También puede establecer un número de revisiones requeridas antes de ejecutar una acción utilizando un entorno o esperar algún tiempo antes de permitir que los despliegues continúen.
Ejecutor de Acción Git
Una Acción de Github puede ser ejecutada dentro del entorno de github o puede ser ejecutada en una infraestructura de terceros configurada por el usuario.
Varias organizaciones permitirán ejecutar Acciones de Github en una infraestructura de terceros ya que suele ser más barato.
Puede listar los ejecutores autoalojados de una organización en https://github.com/organizations/<org_name>/settings/actions/runners
La forma de encontrar qué Acciones de Github se están ejecutando en infraestructura no github es buscar runs-on: self-hosted en el yaml de configuración de la Acción de Github.
No es posible ejecutar una Acción de Github de una organización dentro de una caja autoalojada de una organización diferente porque se genera un token único para el Ejecutor al configurarlo para saber a qué organización pertenece.
Si el Ejecutor de Github personalizado está configurado en una máquina dentro de AWS o GCP por ejemplo, la Acción podría tener acceso al punto final de metadatos y robar el token de la cuenta de servicio con la que se está ejecutando la máquina.
Compromiso de Acción Git
Si se permiten todas las acciones (o una acción maliciosa), un usuario podría usar una Acción de Github que es maliciosa y comprometerá el contenedor donde se está ejecutando.
Una ejecución de Acción de Github maliciosa podría ser abusada por el atacante para:
Robar todos los secretos a los que la Acción tiene acceso
Moverse lateralmente si la Acción se ejecuta dentro de una infraestructura de terceros donde se puede acceder al token de la cuenta de servicio utilizada para ejecutar la máquina (probablemente a través del servicio de metadatos)
Abusar del token utilizado por el flujo de trabajo para robar el código del repositorio donde se ejecuta la Acción o incluso modificarlo.
Protecciones de Rama
Las protecciones de rama están diseñadas para no dar control completo de un repositorio a los usuarios. El objetivo es poner varios métodos de protección antes de poder escribir código dentro de alguna rama.
Las protecciones de rama de un repositorio se pueden encontrar en https://github.com/<orgname>/<reponame>/settings/branches
No es posible establecer una protección de rama a nivel de organización. Por lo tanto, todas deben ser declaradas en cada repositorio.
Se pueden aplicar diferentes protecciones a una rama (como a master):
Puede requerir un PR antes de fusionar (así que no puede fusionar código directamente sobre la rama). Si se selecciona esto, otras protecciones diferentes pueden estar en su lugar:
Requerir un número de aprobaciones. Es muy común requerir que 1 o 2 personas más aprueben tu PR para que un solo usuario no sea capaz de fusionar código directamente.
Descartar aprobaciones cuando se envían nuevos commits. Si no, un usuario puede aprobar código legítimo y luego el usuario podría agregar código malicioso y fusionarlo.
Requerir revisiones de Propietarios de Código. Al menos 1 propietario de código del repositorio necesita aprobar el PR (así que usuarios "aleatorios" no pueden aprobarlo)
Restringir quién puede descartar revisiones de solicitud de extracción. Puede especificar personas o equipos autorizados para descartar revisiones de solicitudes de extracción.
Permitir a actores especificados eludir los requisitos de solicitud de extracción. Estos usuarios podrán eludir restricciones anteriores.
Requerir que las comprobaciones de estado pasen antes de fusionar. Algunas comprobaciones necesitan pasar antes de poder fusionar el commit (como una acción de github que verifica que no haya ningún secreto en texto claro).
Requerir resolución de conversación antes de fusionar. Todos los comentarios sobre el código deben resolverse antes de que se pueda fusionar el PR.
Requerir commits firmados. Los commits necesitan estar firmados.
Requerir historial lineal. Prevenir que los commits de fusión sean empujados a ramas coincidentes.
Incluir administradores. Si esto no se establece, los administradores pueden eludir las restricciones.
Restringir quién puede empujar a ramas coincidentes. Restringir quién puede enviar un PR.
Como puede ver, incluso si logró obtener algunas credenciales de un usuario, los repositorios podrían estar protegidos evitando que empuje código a master por ejemplo para comprometer la pipeline de CI/CD.
Referencias
Última actualización