Administrar las llaves de despliegue

Puedes administrar llaves SSH en tus servidores cuando automatices tus scripts de despliegue utilizando el reenvío del agente de SSH, HTTPS con tokens de OAuth, o usuarios máquina.

Reenvío del agente SSH

En muchos casos, especialmente al inicio de un proyecto, el reenvío del agente SSH es el método más fácil y rápido a utilizar. El reenvío de agentes utiliza las mismas llaves SSH que utiliza tu ordenador de desarrollo local.

Pros

• No tienes que generar o llevar registros de las llaves nuevas.
• No hay administración de llaves; los usuarios tienen los mismos permisos en el servidor y localmente.
• No se almacenan las llaves en el servidor, así que, en caso de que el servidor se ponga en riesgo, no necesitas buscar y eliminar las llaves con este problema.

Contras

• Los usuarios deben ingresar cno SSH para hacer los despliegues; no pueden utilizarse los procesos de despliegue automatizados.
• El reenvío del agente SSH puede ser difícil de ejecutar para usuarios de Windows.

Configuración

1. Habilita el reenvío de agente localmente. Consulta nuestra guía sobre el redireccionamiento del agente SSH para obtener más información.
2. Configura tus scripts de despliegue para utilizar el reenvío de agente. Por ejemplo, el habilitar el reenvío de agentes en un script de bash se vería más o menos así: ssh -A serverA 'bash -s' < deploy.sh

Clonado de HTTPS con tokens de OAuth

Si no quieres utilizar llaves SSH, puedes utilizar HTTPS con tokens de OAuth.

Pros

• Cualquiera que tenga acceso al servidor puede desplegar el repositorio.

• Los usuarios no tienen que cambiar su configuración local de SSH.

• No se necesitan tokens múltiples (uno por usuario); un token por servidor es suficiente.

• Los tokens se pueden revocar en cualquier momento, convirtiéndolos esencialmente en una contraseña de un solo uso.

• Se puede generar nuevos tokens con scripts si se utiliza la API de OAuth.

Contras

• Debes asegurarte de que configuras tu token con los alcances de acceso correctos.
• Los tokens son prácticamente contraseñas, y deben protegerse de la misma manera.

Configuración

Consulta nuestra guía sobre la automatización de tokens en Git.

Llaves de implementación

Puedes lanzar proyectos desde un repositorio de GitHub Enterprise Server hacia tu servidor al utilizar una llave de despliegue, la cual es una llave SSH que otorga acceso a un repositorio específico. GitHub Enterprise Server adjunta la parte pública de la llave directamente en tu repositorio en vez de hacerlo a una cuenta de usuario, y la parte privada de ésta permanece en tu servidor. Para obtener más información, consulta la sección "Entregar despliegues".

Las claves de despliegue con acceso de escritura pueden llevar a cabo las mismas acciones que un miembro de la organización con acceso administrativo o que un colaborador en un repositorio personal. Para obtener más información, consulta las secciones "Niveles de permiso en los repositorios para una organización" y "Niveles de permiso para un repositorio de una cuenta de usuario".

Pros

• Cualquiera que tenga acceso al repositorio y al servidor tiene la capacidad de desplegar el proyecto.
• Los usuarios no tienen que cambiar su configuración local de SSH.
• Las llaves de despliegue son de solo lectura predeterminadamente, pero les puedes otorgar acceso de escritura cuando las agregas a un repositorio.

Contras

• Las llaves de despliegue solo otorgan acceso a un solo repositorio. Los proyectos más complejos pueden tener muchos repositorios que extraer del mismo servidor.
• Las llaves de lanzamiento habitualmente no están protegidas con una frase de acceso, lo cual hace que se pueda acceder fácilmente a ellas si el servidor estuvo en riesgo.

Configuración

1. Ejecuta el procedimiento de ssh-keygen en tu servidor, y recuerda en donde guardaste el par de llaves pública/privada de rsa.
2. En la esquina superior derecha de cualquier página de GitHub Enterprise Server, da clic en tu foto de perfil y luego da clic en Tu perfil.
3. En tu página de perfil, da clic en Repositorios y luego en el nombre de tu repositorio.
4. Desde tu repositorio, da clic en Configuración.
5. En la barra lateral, da clic en Desplegar llaves y luego en Agregar llave de despliegue.
6. Proporciona un título, pégalo en tu llave pública.
7. Selecciona Permitir acceso de escritura si quieres que esta llave tenga acceso de escritura en el repositorio. Una llave de despliegue con acceso de escritura permite que un despliegue cargue información al repositorio.
8. Da clic en Agregar llave.

Utilizar repositorios múltiples en un servidor

Si utilizas repositorios múltiples en un servidor, necesitarás generar un par de llaves dedicados para cada uno. No puedes reutilizar una llave de despliegue para repositorios múltiples.

En el archivo de configuración SSH del servidor (habitualmente ~/.ssh/config), agrega una entrada de alias para cada repositorio. Por ejemplo:

Host my-GHE-hostname.com-repo-0
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-0_deploy_key

Host my-GHE-hostname.com-repo-1
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-1_deploy_key

• Host my-GHE-hostname.com-repo-0 - El alias del repositorio.
• Hostname my-GHE-hostname.com - Configura el nombre de host para utilizarlo con el alias.
• IdentityFile=/home/user/.ssh/repo-0_deploy_key - Asigna una llave privada al alias.

Entonces podrás utilizar el alias del nombre de host para que interactúe con el repositorio utilizando SSH, lo cual utilizará la llave de despliegue única que se asignó a dicho alias. Por ejemplo:

$ git clone git@my-GHE-hostname.com-repo-1:OWNER/repo-1.git

Tokens de servidor a servidor

Si tu servidor necesita acceder a repositorios a lo largo de una o más organizaciones, puedes utilizar una GitHub app para definir el acceso que necesitas y luego generar tokens de alcance limitado de servidor a servidor desde dicha GitHub App. Se puede ajustar el alcance de los tokens de servidor a servidor para repositorios múltiples y pueden tener permisos específicos. Por ejemplo, puedes generar un token con acceso de solo lectura al contenido de un repositorio.

Ya que las GitHub Apps son un actor de primera clase en GitHub Enterprise Server, los tokens de servidor a servidor se desacoplan de cualquier usuario de GitHub, lo cual los hace comparables con los "tokens de servicio". Adicionalmente, los tokens de servidor a servidor. tienen límites de tasa dedicados que se escalan de acuerdo con el tamaño de las organizaciones sobre las cuales actúan. Para obtener más información, consulta la sección Límites de tasa para las GitHub Apps.

Pros

• Tokens de alcance muy específico con conjuntos de permisos bien definidos y tiempos de vencimiento (1 hora o menos si se revocan manualmente utilizando la API).
• Límites de tasa dedicados que crecen con tu organización.
• Desacoplados de las identidades de los usuariso de GitHub para que no consuman plazas de la licencia.
• Nunca se les otorga una contraseña, así que no se puede iniciar sesión directamente en ellos.

Contras

• Se necesita de una configuración adicional para crear la GitHub App.
• Los tokens de servidor a servidor vencen después de 1 hora, entonces necesitan volver a generarse habitualmente cuando se necesite, utilizando código.

Configuración

1. Determina si tu GitHub App debería ser pública o privada. Si tu GitHub App solo actúa en los repositorios dentro de tu organización, probablemente la quieras como privada.
2. Determina los permisos que necesita tu GitHub App, tales como el acceso de solo lectura al contenido del repositorio.
3. Crea tu GitHub App a través de la página de configuración de tu organización. Para obtener más información, consulta la sección Crear una GitHub App.
4. Ten en cuenta la id de tu GitHub App.
5. Genera y descarga la llave privada de tu GitHub App y almacénala de forma segura. Para obtener más información, consulta la sección Generar una llave privada.
6. Instala tu GitHub App en los repositorios sobre los que necesita actuar, opcionalmente, puedes instalarla en todos los repositorios de tu organización.
7. Identifica la installation_id que representa la conexión entre tu GitHub App y los repositorios de tu organización a los que puede acceder. Cada par de GitHub App y organización tienen por lo mucho una sola installation_id. Puedes identificar esta installation_id a través de la sección Obtén una instalación de organización para la app autenticada. Esto requiere autenticarse como una GitHub App utilizando un JWT. Para obtener más información, consulta la sección Autenticarse como una GitHub App.
8. Genera un token de servidor a servidor utilizando la terminal de la API de REST correspondiente, Crear un token de acceso a la instalación para una app. Esto requiere autenticarse como una GitHub App utilizando un JWT. Para obtener más información, consulta las secciones Autenticarse como una GitHub App y Autenticarse como una instalación.
9. Esto requiere que un token de servidor a servidor interactúe con tus repositorios, ya sea a través de la API de REST o de GraphQL, o mediante el cliente de Git.

Usuarios máquina

Si tu servidor necesita acceder a repositorios múltiples, puedes crear una nueva cuenta de GitHub Enterprise Server y adjuntar una llave SSH que se utilizará exclusivamente para fines de automatización. Ya que ninguna persona utilizará esta cuenta de GitHub Enterprise Server, se le llama usuario máquina. Puedes agregar el usuario máquina como colaborador en un repositorio personal (otorgándole acceso de lectura y escritura), como un colaborador externo en el repositorio de una organización (otorgándole acceso de lectura, escritura y administrador), o a un equipo con acceso a los repositorios que necesite para la automatización (otorgándole los permisos del equipo).

Pros

• Cualquiera que tenga acceso al repositorio y al servidor tiene la capacidad de desplegar el proyecto.
• No se necesitan usuarios (humanos) para cambiar su configuración local de SSH.
• No se necesitan llaves múltiples; una por servidor está bien.

Contras

• Únicamente las organizaciones pueden restringir a los usuarios máquina para que tengan acceso de solo lectura. Los repositorios personales siempre otorgan a los colaboradores acceso de lectura/escritura.
• Las llaves de los usuarios máquina, tal como las llaves de despliegue, a menudo no se encuentran protegidas con una frase de acceso.

Configuración

1. Ejecuta el procedimiento de ssh-keygen en tu servidor y adjunta la llave pública a la cuenta del usuario máquina.
2. Otorga a la cuenta del usuario máquina el acceso a los repositorios que quieras automatizar. Puedes hacer esto si agregas la cuenta como un colaborador, como un colaborador externo, o a un equipo en una organización.