¿Cómo asegurar usuarios compartidos en el servidor de compilación?

5

Tenemos un servidor de CI que está instalado como usuario build y todas las tareas se ejecutan como ese usuario respectivo en el nivel del sistema operativo. Tenemos muchos equipos que comparten el servidor de compilación, lo que significa que el usuario build y sus recursos se comparten.

Cada equipo también administra diferentes entornos y esto requiere conectividad ssh del servidor de compilación. Debido a que estamos impulsando la automatización, la conectividad sin contraseña se configuró inicialmente para facilitar la ejecución remota de tareas automatizadas (la clave pública de build user copiada al archivo deploy user authorized_keys en el host remoto).

Esto, como puede imaginar, plantea un problema de seguridad, ya que cualquier usuario que ejecute una tarea puede acceder a cualquier entorno.

Una solución sería usar algo como sshpass (proporcionar la contraseña ssh como argumento) y tener diferentes combinaciones de usuario / contraseña para cada entorno. En el nivel de la tarea, cree ACL basadas en roles para bloquear quién puede ver la contraseña como parece que estará en texto plano. Otra cosa preocupante sobre la que tengo curiosidad por saber más es la exposición de comandos aquí. Me han llevado a creer que los usuarios pueden llegar al proceso de ejecución y ver qué comandos ha ejecutado el usuario build . ¿Es esto posible sin privilegios de raíz? (incluso mejor si alguien puede ilustrar cómo se puede hacer esto o señalarme alguna documentación)

Además de validar mi enfoque, también estoy buscando recomendaciones sobre cómo este problema puede resolverse potencialmente.

    
pregunta kaizenCoder 18.02.2016 - 09:56
fuente

2 respuestas

2

Si la cuenta build puede ejecutar comandos arbitrarios como usuario de producción en un servidor de producción, será necesario bloquearla. Solo un grupo selecto de usuarios privilegiados debería poder usarlo, idealmente sin la capacidad de alterar los comandos (con suerte, un pequeño conjunto de predefinidos).

¿Realmente necesitas esta habilidad? Tal vez haya una solución mejor, como un área de descarga en los servidores de producción en la que la cuenta build puede escribir, completa con secuencias de comandos en los servidores de producción que mueven rápidamente la carga útil al área apropiada (por lo que no se sobrescribe), extráigalo y luego instálelo según sea necesario. La instalación se haría con una cuenta de usuario específica de la aplicación en lugar de una cuenta genérica build o deploy .

Cuando configuré este tipo de cosas en el pasado, hice un uso abundante de sudo y /etc/sudoers para limitar la capacidad de los usuarios individuales para actuar como cualquier cuenta de rol (como build ). También utilicé áreas de colocación, que normalmente eran SFTP o control de revisión (subversion, git, etc.).

El control de revisión es bueno porque los registros son más accesibles que los registros sudo . Solo agregue una etiqueta y el trabajo cron que se ejecuta cada cinco minutos reconocerá la etiqueta, verificará su actualización y dará inicio a una nueva compilación. La finalización exitosa de la compilación (y un conjunto de pruebas de humo) desencadena automáticamente la instalación en un servidor de prueba, después de lo cual el equipo de control de calidad recibe un correo electrónico. Cuando el control de calidad es contenido, agregan otra etiqueta de repositorio y el paquete de preparación se instala en producción.

    
respondido por el Adam Katz 24.03.2016 - 02:40
fuente
0

Calculado, responderé esto con mis conclusiones ya que no he recibido una respuesta.

  

se ha llevado a creer que los usuarios pueden alcanzar el máximo en la ejecución   procesar y ver qué comandos ha ejecutado el usuario de compilación, es esto   posible sin privilegios de root? (Incluso mejor si alguien puede   ilustrar cómo se puede hacer esto o señalarme alguna documentación)

Esto es realmente posible con muy poco esfuerzo. a ps -ef | grep build le mostrará los comandos que se ejecutan como usuario build junto con los argumentos. Esto significa que las contraseñas pueden ser expuestas a un usuario diferente con intenciones maliciosas. Incluso las variables de entorno se pueden ver a través de /etc/proc .

Cuanto más leo sobre esto, más me llevan a creer que todo se reduce a "confianza". Un servidor CI es generalmente configurado para equipos pequeños. Para fomentar la colaboración, se otorga cierta confianza entre los miembros del equipo.

En mi caso de uso de arriba, es esencialmente configurado como un servidor de CI de propósito general. Aquí tenemos múltiples equipos compartiéndolo para ejecutar tareas. Yo diría que esto rompe el 'modelo de confianza' a menos que se pueda proporcionar cierta segregación.

En pocas palabras, hemos decidido que el servidor de CI estará bajo control operativo para cualquier cambio. Esto es ciertamente una solución temporal para soportar un modelo de trabajo compartido.

En el futuro, proveeremos agentes remotos y los asociaremos por equipo.

    
respondido por el kaizenCoder 18.03.2016 - 02:58
fuente

Lea otras preguntas en las etiquetas