Cuando utiliza la función de bolsa de datos cifrados para Chef, ¿cómo hace para implementar la clave en muchos servidores? Si lo coloca en una receta, cualquiera que tenga acceso a cualquiera de los servidores o clientes del chef puede extraer la clave y potencialmente descifrar cualquiera de las bolsas de datos.
¿Cómo se asegura de que la clave esté en las máquinas que la necesitan, pero también a salvo de cualquier persona que husmee?
Respuestas:
Desafortunadamente, no hay mucho que pueda hacer, ya que la clave debe estar en algún lugar del nodo Chef en texto sin formato. Si alguien tiene acceso de shell o local a la caja, entonces es posible que pueda leer la (s) clave (s).
Para mitigar un poco las cosas, agrego lo siguiente a mi basenode (es decir, alguna receta o función que es común a todos los nodos):
directory "/etc/chef/keys" do
mode 0700
owner "root"
group "root"
end
y cualquier mecanismo de distribución de claves que tenga, coloca las claves en esa ubicación. Los permisos y la propiedad evitan la lectura de las claves si alguien olvida poner los permisos correctos en un archivo de claves.
Tal como lo veo, las bolsas de datos cifradas son más para proteger el material clave de ser legible en un sistema de control de fuente, y menos como una característica de seguridad en los propios nodos de Chef.
Mis EDB están separados por:
Cargamos todas las claves con un sufijo especial en cada nueva instancia de EC2 a medida que lo iniciamos y luego eliminamos todas las claves que no han sido utilizadas por ninguna de las recetas en la lista de ejecución al final de la primera vez que el chef-cliente ejecuta (que será justo cuando comienza la instancia).
Todos los archivos se cargan como propietario y grupo "root" y solo con permisos de lectura.
Cada receta que utiliza un EDB genera el nombre EDB y el nombre del archivo de clave en el tiempo de ejecución de la receta concatenando 'edb_' + el entorno de nodos + nombre específico de receta / elemento + '.key' y luego busca la clave con este nombre . (Si no existe, esto arroja una excepción por defecto).
Por lo tanto, para nuestro servidor couchdb, que ejecuta un rol llamado 'couch', para obtener las credenciales que estamos usando para los usuarios administradores en el entorno de desarrollo, la receta busca una clave llamada 'edb_dev_couch.key'
Luego busca en una bolsa de datos llamada 'edb_dev' un elemento llamado 'couch_credentials'.
Para administrar claves, actualmente estoy usando el enfoque simple de:
Afortunadamente, esto limita el tiempo que las claves fuera del alcance de un solo nodo son susceptibles hasta que la máquina haya sido arrancada y haya tenido la primera ejecución de chef_client.
Esta es nuestra primera ronda de prueba de cómo proteger las claves, pero hasta ahora satisface nuestras necesidades actuales, ya que evita que un servidor de desarrollo rooteado pueda acceder de inmediato a cualquier otra credencial de servidor almacenada en un EDB.
Para mantener una receta al final de cada lista de ejecución, utilizo un trabajo de ejecución de cuchillo que se asegura de que esta receta delete_keys sea exactamente la última receta en cada nodo.
Mis claves están integradas en las AMI que usamos o en las imágenes que usamos. No lo hago como parte de la rutina de arranque ya que esos datos no son seguros. Por lo general, puede ver datos en registros y tal si no tiene cuidado.