Vault: ¿Cómo funciona la autenticación de AppRole?

19

Tengo una aplicación de servidor (en infraestructura dinámica) que necesita recuperar un secreto de Hashicorp Vault durante el inicio.

Supongamos que necesitamos que esto sea lo más seguro posible. De los documentos y ejemplos sobre la autenticación AppRole Entiendo que, después de que un administrador de Vault haya creado el approle y el secreto, la aplicación debe configurarse con

  • El nombre del rol de la aplicación
  • Un token que permite recuperar el ID de rol de la aplicación y crear un nuevo identificador secreto bajo ese rol
  • El nombre de host / puerto y del servidor Vault + certificados SSL

Luego, la aplicación recupera el id del rol y crea un nuevo id secreto (modo pull). Con estos dos identificadores la aplicación puede ahora realice un inicio de sesión en el servidor Vault para recuperar el token final que se usa para recuperar el secreto. Durante este flujo, también podríamos ajustar y desenvolver cada respuesta (ajuste de respuesta de cubículo) al configurar X-Vault-Wrap-TTL y usar sys/wrapping/unwrap endpoint para desenvolver.

Primera pregunta: ¿El modo de extracción y / o el ajuste de respuesta realmente tiene sentido aquí? No puedo ver el valor de crear una identificación secreta solo para usarla más tarde para iniciar sesión. Tampoco puedo ver por qué quiero ajustar mis respuestas solo para desenvolverlas.

Si lo anterior es correcto, me parece que cada persona / máquina que conoce el nombre de la función y tiene un token para obtener la identificación de la función y crear un secreto es capaz de recuperar el secreto.

Segunda pregunta: Tener el nombre de la función de la aplicación y el token inicial en mi archivo de configuración no los hace realmente más seguros porque todos los que tienen acceso al servidor Vault solo puedes leer el secreto con eso. Parece que tendría sentido dividir la configuración: tener el nombre del rol de la aplicación en el archivo de configuración y el token En otro lugar (en una variable env, etc).

Tercera pregunta: El ID de aplicación en desuso (basado en push) parece tener más sentido para mí (para mi caso) porque puedo colocar el ID de aplicación en el archivo de configuración y el uso una identificación de usuario específica de la máquina (como la dirección mac, la dirección ip, el nombre de host, etc.) como segundo secreto. Entonces, ¿por qué se prefiere el modo de extracción Autenticación de la aplicación en lugar del modo de inserción o la ID de la aplicación?

    
pregunta Mitchell Stevenson 16.04.2017 - 20:55
fuente

1 respuesta

1

Si no tiene otro servicio autenticado en ejecución (como un programador), no creo que haya mucha diferencia en la seguridad entre los modos de inserción y extracción. Si entiendo el flujo de trabajo correctamente, un atacante necesitaría el token en el archivo de configuración y el nombre de la aplicación y cumplir con las restricciones establecidas en la función (dirección IP, etc.) para obtener acceso a todos los secretos a los que la aplicación tendría acceso. (Suponiendo que los certificados SSL son solo para verificar el servidor de la bóveda y no para autenticarlo).

  1. El ajuste de la respuesta es bueno para garantizar que la identificación correcta sea tomada por la aplicación correcta y no sea detectada por un atacante. Si un programador inicia una aplicación y la respuesta envuelve el ID secreto, entonces la aplicación puede enviar algún tipo de alerta si no puede leerla, porque significa que otra cosa ya la leyó (y podría usarla para autenticarse). . Si la aplicación en sí está sacando la identificación secreta directamente, no creo que envolverla tenga sentido.

  2. La división en la ubicación de los componentes necesarios para la autenticación es probablemente una buena idea.

  3. No creo que el modo push o pull sea fundamentalmente más seguro que el otro con el flujo de trabajo de autenticación que estás describiendo.

respondido por el Vivek Chavda 10.08.2017 - 15:41
fuente

Lea otras preguntas en las etiquetas