¿Es inseguro tener un usuario ansible con sudo sin contraseña?

Soy nuevo en Ansible. La mayoría de las guías de aprovisionamiento de VPS que he visto hasta ahora hacen esto:

deshabilitar el inicio de sesión de root
crear un nuevo usuario que solo pueda iniciar sesión con ssh(no con contraseña)
agregue el nuevo usuario al wheelgrupo, con permiso de sudo sin contraseña

Entiendo (1) y (2), pero no (3).

Seguramente sin contraseña sudoes como iniciar sesión como root? Entiendo el beneficio (conveniencia), pero ¿no es esto altamente inseguro?

Me doy cuenta de que los administradores ejecutan sus redes de varias maneras, por lo que podría decirse que esto es "subjetivo", pero esta es una práctica MUY común, incluso se muestra en varios documentos oficiales de Ansible, así como en guías publicadas por empresas de hosting. Va en contra del sentido común. ¿Cuál es la lógica detrás de esto?

— lonix
fuente

Ansible está destinado a automatizar tareas administrativas, por lo que generalmente necesita acceso de nivel superior (raíz), por lo tanto, "sudo sin contraseña". Sin embargo, si solo lo necesita para ejecutar un subconjunto de los comandos disponibles en su sistema, puede bloquearlo solo para aquellos comandos con una configuración de sudo más detallada. Sudo sin contraseña no significa necesariamente el acceso a todo lo que puede hacer root (aunque esto se hace difícil de cumplir cuando te das cuenta de que el usuario puede modificar tu configuración de sudo a través de sudo para tener un mayor control ...).

— David Spillett el

@DavidSpillett Me preguntaba sobre eso, es decir, definir qué comandos sudo permitir en el archivo sudoers ... pero leí en alguna parte que ansible hace todo interpretando a través de comandos complejos de Python, y que ese enfoque se volvería desordenado rápidamente.

— lonix

Respuestas:

Si la cuenta de servicio puede hacer sudo sin contraseña, entonces debe proteger el acceso a esa cuenta.

Tener la cuenta no tiene una contraseña y usar solo las claves ssh para iniciar sesión, logra esto, siempre que también pueda mantener segura la clave privada ssh.

— Michael Hampton
fuente

Así que estoy "bastante" en lo cierto al sentirme perturbada por esta convención, y, sin embargo, esta es la convención para ansible, por necesidad / pragmatismo.

— lonix

Entonces, ¿está diciendo que esencialmente "muevo" la seguridad central del VPS a mi sistema local, que contiene la clave ssh de la cuenta ansible? En cuyo caso, el punto débil no es el VPS en sí, sino ¡soy yo! Y necesito estar más atento para proteger esa clave ssh, a cambio de la comodidad que me brinda la automatización ansible.

— lonix

La clave ssh, frase de contraseña protegida con ssh-agent, es una credencial razonablemente buena.

— John Mahowald

@lonix Todos los sistemas seguros necesitan credenciales. Los sistemas asegurados son, como máximo, tan seguros como las medidas que usted establece para proteger estas credenciales, ya que tenerlas les da acceso al 100%. Entonces, sí, no puede esperar asegurar su VPS si no asegura adecuadamente su clave SSH (o contraseña de root o lo que sea). El hecho de que configure sudo sin contraseña no significa nada desde este punto de vista, habilitar sudo con contraseña no cambia el hecho de que es esencial que asegure la clave SSH.

— Giacomo Alzetta

@GiacomoAlzetta Lo sé, lo que quise decir anteriormente es que la responsabilidad se está transfiriendo del equipo remoto al equipo local. Dado que la escalada de sudo se realiza sin contraseña, el punto débil se vuelve local.

— lonix

El nuevo usuario creado en (2) solo puede iniciar sesión con la clave SSH, sin contraseña. La clave SSH brinda acceso indirecto a la raíz. Entonces, esto es equivalente a solo permitir el inicio de sesión raíz con una clave.

Como la cuenta no tiene una contraseña, no es posible sudosolicitar una contraseña. También Ansible necesita poder ejecutar comandos. Tener una contraseña adicional para proporcionar en el mismo lugar que la clave no aumentaría la seguridad.

— RalfFriedl
fuente

El problema es que ansible es para administradores y automatización, por lo que si necesita ingresar una contraseña para ejecutar un script, no es realmente la mejor manera. Tampoco es seguro almacenar la contraseña de sudo en un archivo o base de datos y obtenerla cada vez que ejecute el libro de jugadas. Por lo tanto, la combinación de sudo sin contraseña y la autenticación con ssh Keys es el mejor método para garantizar la seguridad y sin problemas al ejecutar el libro de jugadas. También eres administrador y sabes lo que estás programando en el libro de jugadas. Entonces el libro de jugadas no puede destruir sus servidores.

— NicoKlaus
fuente

Los libros de jugadas pueden destruir sus sistemas, pero si usa solo claves de entorno de prueba separadas, eso no destruirá los hosts de producción.

— John Mahowald

Exactamente, esto es un requisito previo cuando se trabaja en sistemas productivos.

— NicoKlaus

Ansible tiene 'ansible-vault' y complementos / módulos / bibliotecas que permiten almacenar secretos en muchos sistemas de almacenamiento secreto de terceros como bitwarden, hashicorp vault, keepass, etc.

— Zoredache