Table des matières

Ajout d'un administrateur au cluster

Ajout d'un administrateur au cluster

Il faut pour cela donner accès aux mots de passe, donner accès au git, et déployer les clés ssh sur le cluster.

Donner accès au git

C'est un gitolite qui se configure par un repos git : gitolite-admin. Pour avoir une idée ça ressemble à ça :

$ cd gitolite-admin
$ tree
.
├── conf
│   └── gitolite.conf
└── keydir
    ├── admin-doku.pub
    ├── benj.pub
    ├── edausq.pub
    ├── madix.pub
    ├── PoluX.pub
    ├── QGuLL.pub
    └── vincentxavier.pub

On commence par copier le pubring ssh du nouvel admin dans le dossier keydir.

Ensuite dans conf/gitolite.conf on complète la définition @admins avec le nom du pubring qui convient.

conf/gitolite.conf

admins = edausq PoluX QGuLL vincentxavier benj madix nouvelAdmin

Enfin on commit et on pousse.

git add *
git commit -m 'ajout nouvelAdmin'
git push

Déploiement des clés ssh sur le cluster

Mise à jour du paquet

Dans le dépot adminsys pour les paquets, on a le paquet sexy-chapril qui installe diverses choses dont les clés root des adminsys sur le cluster.

On installe les nouvelles clés ssh dans sexy-chapril/authorized_keys/root.

Ensuite on édite sexy-chapril/debian/changelog et on recopie matatis mutandis la dernière entrée en tête du fichier:

sexy-chapril/debian/changelog

sexy-chapril (1.2) stable; urgency=medium                                       
 
.   * Ajout clés Mad et Benj                                                      
 
   -- François Poulain <fpoulain@metrodore.fr>  Sun, 23 Jun 2017 22:20:04 +0200

On veillera à bien incrémenter la version et surtout à mettre un couple nom/email qui permette la signature gpg. Sinon debuild va échouer.

Ensuite on build le paquet :

$ cd sexy-chapril/
$ debuild

Pour des détails sur le build : Paquets Chapril.

Ensuite on uploade le paquet avec

$ dupload --to chapril ../sexy-chapril_1.2_amd64.changes

Pour les détails sur l'upload : Paquets Chapril

Enfin on pense à commiter sur le git. :)

Déploiement du paquet

../_scripts/do-update-upgrade.sh

Accès ssh

Pour les accès, la config ssh suivante devrait suffire :

~/.ssh/config

Host coon.chapril.org maine.chapril.org
  User root
  SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
 
Host felicette.chapril.org
  User root
  Port 2242
  SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
 
Host *.cluster.chapril.org
  User root
  ProxyJump root@fip.chapril.org
  SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL

Donner accès au password store

On utilise password store, documenté ici. C'est pass sous debian et le paquet à installer est pass.

Pour se faciliter la vie si c'est votre unique dépot on peut faire un lien symbolique vers le dépot chapril :

$ ls -l ~/.password-store
[...] /home/bling/.password-store -> /home/bling/April/chapril/password-store

Pour lister les actuels accès à pass :

cd ~/.password-store
cat .gpg-id

ou bien pour avoir une autre idée (en supposant que le repo est fonctionnel chez vous donc que vous avez toutes les clés dans votre trousseau) :

gpg --list-key `cat .gpg-id`
gpg --list-key `cat .gpg-id` | grep pub -A1 | grep @ | sed 's/uid *//'

Des clés GPG sont présentes dans le dossier …/password-store/ClésGPG/

Supposons qu'on veuille ajouter l'accès à un certain Frédéric Couchet. On recherche sa clé dans notre trousseau :

$ gpg --list-key couchet
[...]
pub   4096R/76264A53 2014-03-18 [expire : 2018-02-23]
uid                  Frédéric Couchet <frederic@couchet.org>
uid                  Frédéric Couchet <fcouchet@april.org>
sub   4096R/93262A7B 2014-03-18 [expire : 2018-02-23]

L'id qui nous intéresse est donc 76264A53.

Pass requiert des clés de confiance. Il vous faudra a priori signer la clé si ce n'est déjà fait.

Une signature de clé ça ne se fait pas à la légère !! Assurez vous de pouvoir contrôler préalablement le fingerprint de la clé, présenté via un canal sûr (idéalement en personne) par l'admin concerné.

On va réencoder le dépôt pour toutes les clés listées en option de init :

pass init `cat .gpg-id` 76264A53
Password store initialized for 02F5B40A, 71458CFC, 14ABB3F2, AFD9831F, 76264A53, 904BE741
[master 05c1776] Set GPG id to 02F5B40A, 71458CFC, 14ABB3F2, AFD9831F, 76264A53, 904BE741.
 1 file changed, 1 insertion(+)
VMs/dns: reencrypting to 0D26C546C89CC0AB 19DA3F1993262A7B 324424FACB5DC1E5 81C3137F3FE3C04A C2DAD63D95F17989 EAA3CF7EE6E90179
[...]

Attention si vous vous poutrez sur l'étape précédente il est possible que le dépôt ne soit plus lisible par vous ni par personne après.

En cas de soucis voir plus bas.

Et on peut vérifier que tout s'est bien passé en prenant dans des fichiers de pass :

gpg --list-packets --list-only Infra/icinga.chapril.org/icinga2-icinga.gpg

On peut aussi vérifier qu'on a soi-même accès :

pass Infra/icinga.chapril.org/icinga2-icinga

Puis on pousse :

git push

Enfin on peut se fader d'un petit email de courtoisie aux admins anciens et nouveaux :

From: François Poulain <fpoulain@metrodore.fr>
To: Francois Poulain <fpoulain@metrodore.fr>, Edouard Dausque <edouard@dausque.net>, Gibeaux Quentin <quentin.gibeaux@insa-rouen.fr>, Vincent-Xavier Jumel <endymion@thetys-retz.net>
Cc: Benjamin Drieu <bdrieu@april.org>, Frédéric Couchet <fcouchet@april.org>
Subject: Ajout d'admins dans le pass chapril
Date: Fri, 23 Jun 2017 11:59:37 +0200
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)

Coucou,

J'ai ajouté des admins dans le pass chapril. Il va falloir que vous
vous organisiez pour signer leurs clés si ce n'est déjà fait.

Pour rappel sur l'usage du pass :
https://admin.chapril.org/doku.php?id=admin:procedures:configuration_password_store

L'état actuel du dépôt :

$ gpg --list-key `cat .gpg-id`
pub   1024D/71458CFC 2010-03-25
uid                  François Poulain <fpoulain@metrodore.fr>
uid                  François Poulain <fpoulain@amie.coop>
uid                  François Poulain <fpoulain@april.org>
sub   4096g/E6E90179 2010-03-25

pub   1024D/904BE741 2000-02-07
uid                  Benjamin Drieu <tresorier@april.org>
uid                  Benjamin Drieu <bdrieu@april.org>
uid                  Benjamin Drieu <benjamin@drieu.org>
uid                  Benjamin Drieu <benj@grassouille.org>
sub   1024g/C89CC0AB 2000-02-07

pub   4096R/14ABB3F2 2013-08-25 [expire : 2019-08-24]
uid                  Vincent-Xavier Jumel (Clef 4096) <endymion@thetys-retz.net>
uid                  Vincent-Xavier Jumel <vxjumel@april.org>
uid                  Vincent-Xavier Jumel <vxjumel@parinux.org>
uid                  Vincent-Xavier Jumel <vincentxavier@jumel.net>
sub   4096R/CB5DC1E5 2013-08-25 [expire : 2019-08-24]

pub   4096R/76264A53 2014-03-18 [expire : 2018-02-23]
uid                  Frédéric Couchet <frederic@couchet.org>
uid                  Frédéric Couchet <fcouchet@april.org>
sub   4096R/93262A7B 2014-03-18 [expire : 2018-02-23]

pub   4096R/AFD9831F 2016-06-16 [expire : 2031-06-13]
uid                  Quentin Gibeaux (QGuLL) <quentin@gibeaux.eu>
sub   4096R/3FE3C04A 2016-06-16 [expire : 2031-06-13]

pub   4096R/02F5B40A 2016-08-08 [expire : 2018-08-08]
uid                  Edouard Dausque <secure@edouard.dausque.net>
sub   4096R/95F17989 2016-08-08 [expire : 2018-08-08]

Soucis avec pass, git ou gpg

Aucune assurance que la clef appartienne vraiment à l'utilisateur nommé

L'erreur se manifeste ainsi :

gpg: DEADBEEF : aucune assurance que la clef appartienne vraiment à l'utilisateur nommé.

sub  rsa4096/DEADBEEF 2042-42-42 douglas@adams.42
Empreinte clef princip. : DEAD BEEF
 Empreinte de sous-clef : DEAD BEEF

La clef n'appartient PAS forcément à la personne nommée
dans l'identité. Si vous savez *vraiment* ce que vous
faites, vous pouvez répondre oui à la prochaine question.


Faut-il quand même utiliser cette clef ? (o/N) o

Solution: donner un niveau de confiance fort à la clé.

gpg --edit-key DEADBEEF
tsign
--> suivez selon les pointillés