Skip to main content

Administrar las llaves de despliegue

Aprende las diversas formas de administrar llaves SSH en tus servidores cuando automatizas los scripts de desplegue y averigua qué es lo mejor para ti.

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.

Ventajas

  • 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.

Desventajas

  • Los usuarios deben utilizar SSH para la implementación; no se pueden usar procesos de implementación automatizados.
  • El reenvío del agente SSH puede ser difícil de ejecutar para usuarios de Windows.

Configurar

  1. Habilita el reenvío de agente localmente. Vea nuestra guía sobre el reenvío de agentes SSH para más información.
  2. Configura tus scripts de despliegue para utilizar el reenvío de agente. Por ejemplo, en un script de Bash, la habilitación del reenvío de agentes tendría un aspecto similar al siguiente: 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.

Ventajas

  • Cualquiera que tenga acceso al servidor puede desplegar el repositorio.
  • Los usuarios no tienen que implementar la 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.

Desventajas

  • 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.

Configurar

Vea nuestra guía sobre cómo crear un token de acceso personal.

Claves de implementación

Puedes lanzar proyectos hacia tu servidor desde un repositorio de GitHub AE utilizando una llave de despliegue, la cual es una llave SSH que otorga acceso a un repositorio único. GitHub AE adjunta la parte pública de la llave directamente en tu repositorio en vez de hacerlo a una cuenta personal, mientras que la parte privada de la clave permanece en tu servidor. Para más información, vea "Entrega de implementaciones".

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 más información, consulta "Roles de repositorio para una organización" y "Niveles de permisos para un repositorio de cuentas personales".

Ventajas

  • Cualquiera que tenga acceso al repositorio y al servidor tiene la capacidad de desplegar el proyecto.
  • Los usuarios no tienen que implementar la configuración local de SSH.
  • Las claves de implementación son de solo lectura de forma predeterminada, pero puede darles acceso de escritura al agregarlas a un repositorio.

Desventajas

  • 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.

Configurar

  1. Ejecuta el procedimientossh-keygen en el servidor y recuerda dónde guardas el par de claves RSA públicas y privadas generado.
  2. En la esquina superior derecha de cualquier página de GitHub AE, haga clic en la fotografía de perfil y luego en Your profile. Navegación al perfil
  3. En la página del perfil, haga clic en Repositories y después en el nombre del repositorio. Vínculo Repositories
  4. Desde el repositorio, haga clic en Settings. Configuración del repositorio
  5. En la barra lateral, haga clic en Deploy Keys y después en Add deploy key. Vínculo para agregar claves de implementación
  6. Proporciona un título, pégalo en tu llave pública. Página de la llave de despliegue
  7. Seleccione Allow write access si quiere que esta clave 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. Haga clic en Add key.

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), agregue 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: alias del repositorio.
  • Hostname my-GHE-hostname.com: configura el nombre de host que se va a usar con el alias.
  • IdentityFile=/home/user/.ssh/repo-0_deploy_key: asigna una clave 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 el servidor tiene que acceder a repositorios en una o más organizaciones, puede usar una aplicación de GitHub para definir el acceso necesario y, luego, generar tokens de ámbito limitado y de servidor a servidor desde esa aplicación de GitHub. 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 AE, 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 más información, vea Límites de frecuencia para GitHub Apps.

Ventajas

  • 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.

Desventajas

  • 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.

Configurar

  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 más información, vea Creación de una aplicación de GitHub.
  4. Anote la aplicación de GitHub id.
  5. Genera y descarga la llave privada de tu GitHub App y almacénala de forma segura. Para más información, vea Generación de una clave 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 el valor installation_id que representa la conexión entre la aplicación de GitHub y los repositorios de la organización a los que puede acceder. Cada par de aplicación de GitHub y organización tiene como máximo un único valor installation_id. Puede identificar este valor installation_id mediante la Obtención de una instalación de la organización para la aplicación autenticada. Para esto es necesario autenticase como una aplicación de GitHub mediante un JWT. Para más información, vea Autenticación como una aplicación de GitHub.
  8. Genere un token de servidor a servidor mediante el punto de conexión de la API REST correspondiente, Crear un token de acceso de instalación para una aplicación. Para esto es necesario autenticase como una aplicación de GitHub mediante un JWT. Para más información, vea Autenticación como una aplicación de GitHub y Autenticación 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 acceso a varios repositorios, puedes crear una cuenta nueva en GitHub AE y adjuntar la llave SSH que se utilizará exclusivamente para la automatización. Ya que ningún humano usará esta cuenta en GitHub AE, se denomina usuario de máquina. Puede agregar el usuario de máquina como colaborador en un repositorio personal (y conceder acceso de lectura y escritura), como colaborador externo en un repositorio de la organización (y conceder acceso de lectura, escritura o administrador), o bien a un equipo con acceso a los repositorios que necesita automatizar (y conceder los permisos del equipo).

Ventajas

  • 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.

Desventajas

  • Ú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.

Configurar

  1. Ejecute el procedimiento ssh-keygen en el servidor y adjunte la clave pública a la cuenta de usuario de máquina.
  2. Otorga a la cuenta del usuario máquina el acceso a los repositorios que quieras automatizar. Para ello, agregue la cuenta como colaborador, como colaborador externo o a un equipo de una organización.

Información adicional