L'administration de la v5 demande de se partager des secrets (genre mot de passes InfluxDB, PostgreSQL, etc.).
Je me demandais quelle serait la pertinence d'un password-store dédié, avec les clés GPG des participants. Qui serait ensuite synchro quelque part sur la forge.
Cf le man :
init [ --path=sub-folder, -p sub-folder ] gpg-id...
Initialize new password storage and use gpg-id for encryption.
Multiple gpg-ids may be specified, in order to encrypt each
password with multiple ids. This command must be run first be‐
fore a password store can be used. If the specified gpg-id is
different from the key used in any existing files, these files
will be reencrypted to use the new id. Note that use of gpg-
agent(1) is recommended so that the batch decryption does not
require as much user intervention. If --path or -p is specified,
along with an argument, a specific gpg-id or set of gpg-ids is
assigned for that specific sub folder of the password store. If
only one gpg-id is given, and it is an empty string, then the
current .gpg-id file for the specified sub-folder (or root if
unspecified) is removed.
L'administration de la v5 demande de se partager des secrets (genre mot de passes InfluxDB, PostgreSQL, etc.).
Je me demandais quelle serait la pertinence d'un password-store dédié, avec les clés GPG des participants. Qui serait ensuite synchro quelque part sur la forge.
Cf le `man` :
```
init [ --path=sub-folder, -p sub-folder ] gpg-id...
Initialize new password storage and use gpg-id for encryption.
Multiple gpg-ids may be specified, in order to encrypt each
password with multiple ids. This command must be run first be‐
fore a password store can be used. If the specified gpg-id is
different from the key used in any existing files, these files
will be reencrypted to use the new id. Note that use of gpg-
agent(1) is recommended so that the batch decryption does not
require as much user intervention. If --path or -p is specified,
along with an argument, a specific gpg-id or set of gpg-ids is
assigned for that specific sub folder of the password store. If
only one gpg-id is given, and it is an empty string, then the
current .gpg-id file for the specified sub-folder (or root if
unspecified) is removed.
```
Ça m'a l'air vraiment bien pourvu que tout le monde ait accès à tous les objets d'administration. Par exemple un dev' peut avoir accès à la bdd mais pas au compte Service Public de l'association.
Ça m'a l'air vraiment bien pourvu que tout le monde ait accès à tous les objets d'administration. Par exemple un dev' peut avoir accès à la bdd mais pas au compte Service Public de l'association.
Faut voir. Pour moi il faudrait plusieurs stores différents : un pour l'assoc', et un pour le site.
Si c'est pas aussi trivial, il faudra faire une étude de besoins plus poussée.
Faut voir. Pour moi il faudrait plusieurs stores différents : un pour l'assoc', et un pour le site.
Si c'est pas aussi trivial, il faudra faire une étude de besoins plus poussée.
L'administration de la v5 demande de se partager des secrets (genre mot de passes InfluxDB, PostgreSQL, etc.).
Je me demandais quelle serait la pertinence d'un password-store dédié, avec les clés GPG des participants. Qui serait ensuite synchro quelque part sur la forge.
Cf le
man:Ça m'a l'air vraiment bien pourvu que tout le monde ait accès à tous les objets d'administration. Par exemple un dev' peut avoir accès à la bdd mais pas au compte Service Public de l'association.
Je ne sait pas si c'est faisable de spécifier ça à password-store. Peut-être avec plusieurs stores différents ? Ou un plugin.
Faut voir. Pour moi il faudrait plusieurs stores différents : un pour l'assoc', et un pour le site.
Si c'est pas aussi trivial, il faudra faire une étude de besoins plus poussée.