1
00:00:15,068 --> 00:00:17,510
Bonjour à toutes et à tous, et
bienvenue dans ce deuxième

2
00:00:17,510 --> 00:00:19,289
épisode de Yakafokon.

3
00:00:20,018 --> 00:00:22,809
Dans le précédent épisode, j'ai
exposé les problèmes que je

4
00:00:22,809 --> 00:00:26,334
voyais à l'utilisation d'Ansible
dans le but d'administrer une

5
00:00:26,334 --> 00:00:29,731
infrastructure codifiée par
mutation, c'est-à-dire en

6
00:00:29,731 --> 00:00:31,242
modifiant les machines en
production.

7
00:00:32,216 --> 00:00:34,630
Outre les problèmes de licence
et d'attaques par chaines

8
00:00:34,630 --> 00:00:38,216
d'approvisionnement, l'absence
de garantie d'idempotence est

9
00:00:38,348 --> 00:00:41,392
centrale pour comprendre
l'approche alternative :

10
00:00:41,985 --> 00:00:43,463
une infrastructure immuable.

11
00:00:44,809 --> 00:00:47,745
Cet épisode est consacré à
présenter différentes approches

12
00:00:47,745 --> 00:00:50,884
à l'immuabilité, afin de mieux
en cerner l'intérêt.

13
00:00:52,056 --> 00:00:54,781
Mais tout d'abord : qu'est-ce
qu'une infrastructure immuable ?

14
00:00:55,604 --> 00:00:58,851
Il s'agit d'une infrastructure
composée de serveurs immuables.

15
00:00:59,971 --> 00:01:03,007
Bon, heu... en disant cela, on
n'a pas fait beaucoup avancer le

16
00:01:03,007 --> 00:01:06,635
schmilblick. Donc, qu'est-ce
qu'un serveur immuable ?

17
00:01:07,731 --> 00:01:11,557
Il s'agit d'un serveur qui
applique le principe de sécurité

18
00:01:11,557 --> 00:01:15,308
W xor X, c'est-à-dire qu'une
donnée ne peut être

19
00:01:15,310 --> 00:01:18,860
qu'inscriptible ou exécutable,
mais jamais les deux

20
00:01:18,860 --> 00:01:19,340
en même temps.

21
00:01:20,536 --> 00:01:24,903
La démarche W xor X implique
d'identifier et de séparer

22
00:01:25,025 --> 00:01:28,729
le code, d'une part, et les données
manipulées par les applications,

23
00:01:28,903 --> 00:01:30,136
d'autre part.

24
00:01:30,842 --> 00:01:34,865
Ainsi, les serveurs immuables
font tourner du code qui ne peut

25
00:01:35,251 --> 00:01:37,501
ou n'est pas censé être modifié.

26
00:01:38,912 --> 00:01:42,894
Pas d'ajout de logiciel, pas de
mise à jour, pas de corruption.

27
00:01:43,200 --> 00:01:44,367
Rien.

28
00:01:44,650 --> 00:01:47,731
Si un serveur immuable a besoin
de faire l'une de ces

29
00:01:47,731 --> 00:01:51,096
opérations, il faut passer par
un mode opératoire qui est

30
00:01:51,096 --> 00:01:54,136
spécifique à chaque manière
d'implémenter l'immuabilité.

31
00:01:55,350 --> 00:01:58,442
Généralement, cela implique un
redémarrage de la machine,

32
00:01:59,105 --> 00:02:02,545
voire la machine est détruite et
remplacée par une nouvelle,

33
00:02:02,941 --> 00:02:04,635
contenant les modifications
désirées.

34
00:02:05,854 --> 00:02:08,696
Ce mode opératoire peut vous
sembler familier si vous

35
00:02:08,696 --> 00:02:10,371
travaillez régulièrement avec
des conteneurs.

36
00:02:11,383 --> 00:02:14,047
Lorsqu'on veut modifier un
conteneur, on fabrique une

37
00:02:14,047 --> 00:02:15,096
nouvelle image.

38
00:02:15,581 --> 00:02:19,355
Ensuite, on arrête le conteneur
précédent et on démarre un

39
00:02:19,355 --> 00:02:21,807
nouveau conteneur faisant
tourner la nouvelle image.

40
00:02:22,757 --> 00:02:26,197
Un serveur immuable peut donc
ressembler, en certains égards,

41
00:02:26,200 --> 00:02:28,432
à des conteneurs, le noyau en
plus.

42
00:02:29,581 --> 00:02:32,348
D'ailleurs, certaines approches
à l'immuabilité

43
00:02:32,630 --> 00:02:33,877
 sont précisément cela.

44
00:02:34,941 --> 00:02:38,484
Ce mode opératoire a déjà fait
ses preuves avec les conteneurs,

45
00:02:39,049 --> 00:02:41,854
apportant une meilleure
reproductibilité des

46
00:02:41,854 --> 00:02:46,254
déploiements, une meilleure
auditabilité et facilitant les

47
00:02:46,254 --> 00:02:47,388
retours en arrière.

48
00:02:48,127 --> 00:02:52,461
Les serveurs immuables sont le
pendant des conteneurs, mais à

49
00:02:52,461 --> 00:02:54,037
l'échelle du système
d'exploitation complet.

50
00:02:55,049 --> 00:02:56,875
Mais voyons justement
différentes approches à

51
00:02:56,875 --> 00:02:59,875
l'immuabilité, afin de rendre
les choses un peu concrètes et

52
00:02:59,875 --> 00:03:01,044
pragmatiques.

53
00:03:01,783 --> 00:03:05,844
L'immuabilité est devenue un
terme à la mode, notamment grâce

54
00:03:05,844 --> 00:03:10,103
au tao de Hashicorp qui l'érige
au rang de principe fondamental.

55
00:03:11,195 --> 00:03:13,877
De nombreuses entreprises ont
donc franchi le pas vers des

56
00:03:13,877 --> 00:03:15,548
formes d'immuabilité.

57
00:03:16,461 --> 00:03:20,371
Certaines ont des garanties de
sécurité ou de stabilité plus

58
00:03:20,371 --> 00:03:21,355
fortes que d'autres.

59
00:03:22,127 --> 00:03:25,176
L'approche immuable la plus
faible est conventionnelle.

60
00:03:26,000 --> 00:03:28,776
C'est-à-dire qu'il n'existe
aucun moyen technique pour

61
00:03:28,776 --> 00:03:31,776
forcer l'immuabilité ; c'est une
convention.

62
00:03:33,345 --> 00:03:37,035
Avec cette approche, nous ne
sommes pas censé.es effectuer de

63
00:03:37,035 --> 00:03:40,108
modification en se connectant
aux serveurs, que ce soit

64
00:03:40,164 --> 00:03:43,294
manuellement ou avec des outils
de configuration.

65
00:03:44,560 --> 00:03:48,931
À la place, nous concevons une
nouvelle image système, et

66
00:03:48,931 --> 00:03:51,665
réinstallons la machine à partir
de cette image.

67
00:03:53,025 --> 00:03:56,258
Néanmoins, rien ne nous empêche
réellement de nous connecter à

68
00:03:56,258 --> 00:03:58,837
une machine et d'effectuer une
modification.

69
00:03:59,943 --> 00:04:04,277
Cette modification serait
éphémère et perdue la prochaine

70
00:04:04,277 --> 00:04:06,842
fois que la procédure
conventionnelle de modification

71
00:04:06,842 --> 00:04:08,023
sera utilisée.

72
00:04:08,757 --> 00:04:11,289
Cette approche présente
l'avantage d'être extrêmement

73
00:04:11,289 --> 00:04:12,898
simple à mettre en œuvre.

74
00:04:13,360 --> 00:04:16,390
Nul besoin d'adopter une
distribution Linux atypique

75
00:04:16,851 --> 00:04:18,315
ou  de nouveaux outils.

76
00:04:18,964 --> 00:04:22,324
Les images peuvent être créées à
l'aide d'outils DevOps assez

77
00:04:22,324 --> 00:04:26,117
classiques, comme Packer ou
mkosi.

78
00:04:27,430 --> 00:04:30,677
Pour rappel, Packer vise à
dériver une image système

79
00:04:30,680 --> 00:04:32,197
afin d'en former une nouvelle.

80
00:04:32,941 --> 00:04:36,385
mkosi permet de créer des images
de toutes pièces

81
00:04:36,390 --> 00:04:38,385
pour différentes
distributions Linux.

82
00:04:39,040 --> 00:04:41,957
Nous reviendrons plus tard sur
cet outil, puisqu'il est aussi

83
00:04:41,957 --> 00:04:45,105
utilisé pour les formes les
plus fortes de l'immuabilité.

84
00:04:46,517 --> 00:04:50,898
Il est ainsi possible de créer
une image très générique, et

85
00:04:50,898 --> 00:04:54,484
d'y installer tous les outils,
scripts et fichiers de

86
00:04:54,484 --> 00:04:57,011
configuration dont le serveur
aura besoin.

87
00:04:57,890 --> 00:05:01,722
Le résultat forme alors notre
"golden image", c'est-à-dire

88
00:05:01,722 --> 00:05:05,844
l'image système prête à
l'emploi et à laquelle il ne sera plus

89
00:05:05,844 --> 00:05:07,844
nécessaire de faire des
modifications.

90
00:05:08,823 --> 00:05:11,872
Un des défauts de cette
approche est que le système n'est pas

91
00:05:11,872 --> 00:05:13,510
vraiment immuable.

92
00:05:14,164 --> 00:05:16,240
Il ne l'est qu'aux yeux de ses
administrateurs 

93
00:05:16,240 --> 00:05:17,651
et administratrices.

94
00:05:18,409 --> 00:05:22,258
Le système lui-même est en
mesure de se modifier, y compris

95
00:05:22,258 --> 00:05:24,202
si des logiciels sont compromis.

96
00:05:24,964 --> 00:05:27,708
L'immuabilité conventionnelle
n'a donc aucun apport de

97
00:05:27,708 --> 00:05:31,298
sécurité particulier, en dehors
de réduire la durée de la

98
00:05:31,298 --> 00:05:33,242
persistance d'un attaquant ou
d'une attaquante

99
00:05:33,242 --> 00:05:34,508
dans le système.

100
00:05:35,218 --> 00:05:38,456
Néanmoins, d'un point de vue
DevOps, cette approche de

101
00:05:38,456 --> 00:05:41,456
l'immuabilité offre déjà
d'excellents avantages.

102
00:05:42,089 --> 00:05:45,604
Les "golden images" sont des
artefacts finaux.

103
00:05:46,757 --> 00:05:50,447
Une fois construits, ils peuvent
être déployés à l'identique en

104
00:05:50,447 --> 00:05:53,447
développement, en préproduction
et en production.

105
00:05:54,555 --> 00:05:57,435
Il est donc possible de créer
des circuits de tests et de

106
00:05:57,435 --> 00:05:58,988
promotion de l'image.

107
00:05:59,651 --> 00:06:02,705
Cette approche facilite aussi le
déploiement de N instances

108
00:06:02,705 --> 00:06:05,360
identiques, puisque c'est
toujours la même image

109
00:06:05,360 --> 00:06:06,390
qui est utilisée.

110
00:06:07,063 --> 00:06:10,672
En outre, si une nouvelle image
déployée présente un problème,

111
00:06:11,284 --> 00:06:14,480
le retour en arrière à une
version fonctionnelle se résume

112
00:06:14,480 --> 00:06:16,414
à faire démarrer le serveur
sur une version

113
00:06:16,414 --> 00:06:17,910
précédente de l'image.

114
00:06:18,936 --> 00:06:22,164
On peut donc conclure que cette
approche est déjà intéressante

115
00:06:22,164 --> 00:06:26,131
pour le DevOps, mais pas
spécialement pour le SecDevOps.

116
00:06:27,807 --> 00:06:32,037
Pour améliorer les choses,
notamment la sécurité, on peut

117
00:06:32,040 --> 00:06:34,600
tourner le regard vers des
distributions Linux

118
00:06:34,600 --> 00:06:35,905
en lecture seule.

119
00:06:36,508 --> 00:06:39,731
Ces distributions visent à
permettre le déploiement et

120
00:06:39,731 --> 00:06:43,176
l'administration de systèmes
dont les partitions contenant du

121
00:06:43,176 --> 00:06:46,602
code sont montées en lecture
seule dès le démarrage.

122
00:06:47,783 --> 00:06:50,428
Avec ces distributions, les
modifications s'effectuent

123
00:06:50,428 --> 00:06:52,390
avant le démarrage.

124
00:06:53,501 --> 00:06:57,360
Avec NixOS, le nouveau système
est installé et configuré

125
00:06:57,360 --> 00:06:59,190
avant le redémarrage.

126
00:07:00,367 --> 00:07:04,070
Cela présuppose donc d'avoir un
système déjà démarré, que ce

127
00:07:04,070 --> 00:07:07,228
soit sur LiveCD ou depuis un
système déjà installé.

128
00:07:08,564 --> 00:07:11,807
Avec des distributions comme
Fedora CoreOS ou openSUSE

129
00:07:11,807 --> 00:07:16,282
MicroOS, le nouveau système est
initialisé et configuré lors

130
00:07:16,282 --> 00:07:19,571
de son premier démarrage, dans
l'initramfs.

131
00:07:20,785 --> 00:07:24,752
Finalement, certains systèmes,
comme Kairos OS ou openSUSE

132
00:07:24,752 --> 00:07:28,974
MicroOS sont configurés à chaque
démarrage par Cloud Init.

133
00:07:30,376 --> 00:07:32,762
Quelle que soit la distribution
utilisée, les modifications

134
00:07:32,762 --> 00:07:35,840
sont exprimées soit de
manière déclarative,

135
00:07:35,840 --> 00:07:37,755
soit de manière impérative.

136
00:07:39,289 --> 00:07:42,188
La manière déclarative consiste
à décrire l'état désiré du

137
00:07:42,188 --> 00:07:45,938
système, et à laisser les outils
interpréter ces descriptions et

138
00:07:45,938 --> 00:07:47,680
effectuer les modifications.

139
00:07:48,738 --> 00:07:51,162
La manière impérative consiste à
faire tourner des scripts

140
00:07:51,162 --> 00:07:54,162
arbitraires pour altérer le
système.

141
00:07:54,804 --> 00:07:57,581
Un exemple de manière
déclarative est l'outil

142
00:07:57,581 --> 00:08:01,411
Ignition. Ce dernier est
intégré aux distributions Fedora

143
00:08:01,411 --> 00:08:04,823
CoreOS, openSUSE MicroOS et
Flatcar.

144
00:08:06,127 --> 00:08:10,856
Avec Ignition, on écrit des
fichiers JSON décrivant les

145
00:08:10,856 --> 00:08:13,856
disques, les partitions, les
systèmes de fichiers, les

146
00:08:13,856 --> 00:08:16,738
répertoires à créer et les
fichiers à copier, les

147
00:08:16,738 --> 00:08:18,917
utilisateurs à initialiser, etc.

148
00:08:19,680 --> 00:08:22,216
Pendant le premier démarrage de
la machine, ce fichier est

149
00:08:22,216 --> 00:08:25,647
consommé par Ignition qui
s'exécute dans l'initramfs.

150
00:08:27,105 --> 00:08:31,350
Le fichier peut être récupéré
sur le réseau, sur un point de

151
00:08:31,350 --> 00:08:34,945
montage ou intégré dans un
fichier ISO personnalisé

152
00:08:34,945 --> 00:08:36,381
de la distribution Linux.

153
00:08:37,647 --> 00:08:41,529
En cas de modification de la
configuration, on réinstalle la

154
00:08:41,529 --> 00:08:44,529
machine, et la nouvelle
configuration sera appliquée

155
00:08:44,529 --> 00:08:47,030
lors du premier démarrage
suivant la réinstallation.

156
00:08:48,531 --> 00:08:51,731
Pour la manière impérative, on
peut citer l'outil Combustion,

157
00:08:52,094 --> 00:08:54,790
qui est utilisé par openSUSE
MicroOS.

158
00:08:56,080 --> 00:08:59,110
Ce dernier exécute, lors de
l'initramfs du premier

159
00:08:59,110 --> 00:09:01,444
démarrage, un script arbitraire.

160
00:09:02,771 --> 00:09:07,011
À titre personnel, je considère
que la manière déclarative est

161
00:09:07,010 --> 00:09:11,035
préférable à la méthode
impérative. J'admets volontiers

162
00:09:11,035 --> 00:09:14,035
que la méthode impérative
est plus flexible

163
00:09:14,040 --> 00:09:15,397
et permet de tout faire.

164
00:09:16,352 --> 00:09:19,520
Néanmoins, nous nous retrouvons
alors individuellement

165
00:09:19,520 --> 00:09:23,101
responsables des bugs et
problèmes de sécurité éventuels

166
00:09:23,454 --> 00:09:25,171
des scripts que nous avons
développés.

167
00:09:26,357 --> 00:09:30,616
En comparaison, l'approche
déclarative repose sur un outil

168
00:09:30,616 --> 00:09:32,225
commun dont nous sommes toutes et tous

169
00:09:32,230 --> 00:09:33,661
collectivement responsables.

170
00:09:35,124 --> 00:09:38,508
Cela permet de mutualiser les
efforts, de bénéficier

171
00:09:38,508 --> 00:09:41,435
collectivement des correctifs
et améliorations proposées par

172
00:09:41,435 --> 00:09:45,096
la communauté, tout en rendant
abstraits les détails

173
00:09:45,096 --> 00:09:47,223
d'implémentation qui peuvent
varier dans le temps.

174
00:09:48,428 --> 00:09:51,392
Dans le cas d'openSUSE MicroOS
qui propose les approches

175
00:09:51,392 --> 00:09:55,642
déclaratives avec ignition et
cloud-init, je pense que

176
00:09:55,642 --> 00:09:57,515
l'approche d'ignition
est à la fois plus

177
00:09:57,515 --> 00:09:59,152
simple et plus puissante.

178
00:10:00,385 --> 00:10:03,054
Cloud-init s'exécute pendant le
démarrage du système

179
00:10:03,054 --> 00:10:05,948
d'exploitation, en plusieurs
fois, à l'aide de différents

180
00:10:05,948 --> 00:10:07,185
services systèmes.

181
00:10:08,047 --> 00:10:10,832
Cela lui permet d'effectuer des
actions une fois le réseau

182
00:10:10,832 --> 00:10:13,364
obtenu ou une fois tous les
services système démarrés.

183
00:10:14,461 --> 00:10:17,294
Néanmoins, cela occasionne des
complexités liés à

184
00:10:17,294 --> 00:10:20,941
l'ordonnancement des actions.
Par exemple, les fichiers sont

185
00:10:20,941 --> 00:10:24,037
écrits sur le système de
fichiers très tôt ; tellement

186
00:10:24,037 --> 00:10:27,105
tôt que l'initialisation et le
montage de nouvelles partitions

187
00:10:27,105 --> 00:10:28,964
se fait ultérieurement.

188
00:10:29,505 --> 00:10:32,616
Créer un fichier dans une
nouvelle partition, mais avant

189
00:10:32,616 --> 00:10:35,616
qu'un service spécifique ne se
lance est un casse-tête.

190
00:10:37,152 --> 00:10:40,277
Ignition s'exécute dans
l'initramfs, avant que le

191
00:10:40,277 --> 00:10:44,174
système d'exploitation ne
démarre. Il est donc libre de

192
00:10:44,174 --> 00:10:47,538
faire toutes les modifications
qu'il souhaite, sans avoir à

193
00:10:47,538 --> 00:10:50,192
réfléchir à l'état d'avancement
du démarrage.

194
00:10:51,280 --> 00:10:54,235
Et s'il a besoin d'intercaler
des opérations pendant le

195
00:10:54,235 --> 00:10:57,143
démarrage du système, il lui
suffit d'ajouter des

196
00:10:57,140 --> 00:10:58,602
services systemd.

197
00:11:00,000 --> 00:11:02,785
Outre cette philosophie de
configuration précédant ou

198
00:11:02,785 --> 00:11:06,978
intervenant lors du démarrage,
la plupart de ces distributions

199
00:11:07,228 --> 00:11:09,978
intègrent des mécanismes
d'installation de mises à jour

200
00:11:10,254 --> 00:11:12,428
et de retour en arrière
sophistiqués.

201
00:11:13,920 --> 00:11:16,997
Comme les systèmes sont en
lecture seule, les mises à jour

202
00:11:16,997 --> 00:11:20,621
ne s'effectuent pas par
altération du système. Elles

203
00:11:20,621 --> 00:11:23,783
nécessitent un redémarrage afin
de terminer tous les processus

204
00:11:23,783 --> 00:11:27,585
anciens, et redémarrer tous les
processus depuis le système

205
00:11:27,585 --> 00:11:28,856
de fichiers mis à jour.

206
00:11:30,371 --> 00:11:33,760
La préparation de cette mise à
jour varie suivant la

207
00:11:33,760 --> 00:11:34,771
distribution Linux.

208
00:11:35,600 --> 00:11:40,376
MicroOS de openSUSE utilise le
mécanisme de snapshots

209
00:11:40,380 --> 00:11:42,390
du système de fichiers BTRFS.

210
00:11:43,223 --> 00:11:46,960
Les mises à jour sont faites
dans un nouveau snapshot, dérivé

211
00:11:46,960 --> 00:11:50,296
du système actuellement en
cours d'exécution, et qui est monté

212
00:11:50,296 --> 00:11:52,277
avec l'autorisation en écriture.

213
00:11:53,444 --> 00:11:56,216
Une fois l'ensemble des mises à
jour et modifications faites,

214
00:11:56,861 --> 00:11:59,816
ce snapshot est marqué en
lecture seule, et le système est

215
00:11:59,816 --> 00:12:01,778
redémarré pour
utiliser ces napshot

216
00:12:01,780 --> 00:12:03,421
comme son système de fichiers.

217
00:12:04,235 --> 00:12:06,945
Pour revenir en arrière sur une
modification cassante du

218
00:12:06,945 --> 00:12:10,051
système, il suffit de faire
démarrer la machine sur

219
00:12:10,050 --> 00:12:11,407
le précédent snapshot.

220
00:12:12,432 --> 00:12:18,098
Fedora CoreOS utilise une autre
méthode reposant sur rpm-ostree.

221
00:12:19,294 --> 00:12:22,569
Ostree est un peu l'équivalent
de l'outil de versionnement git,

222
00:12:22,917 --> 00:12:24,597
mais à l'échelle d'un système
de fichiers.

223
00:12:25,665 --> 00:12:27,689
Lorsqu'on veut faire une
modification, comme

224
00:12:27,689 --> 00:12:31,576
l'installation ou la mise à
jour d'un programme, on ajoute un

225
00:12:31,576 --> 00:12:34,576
commit à Ostree contenant ces
modifications.

226
00:12:35,571 --> 00:12:38,945
Lors du prochain démarrage,
c'est ce nouveau commit qui est

227
00:12:38,945 --> 00:12:43,967
utilisé et démarré. Pour cela,
Ostree créé des hardlinks entre

228
00:12:43,967 --> 00:12:45,938
les fichiers contenus
dans le dépôt Ostree

229
00:12:46,221 --> 00:12:48,235
et l'arborescence /usr.

230
00:12:49,712 --> 00:12:52,630
Un retour en arrière consiste
simplement à démarrer sur un

231
00:12:52,630 --> 00:12:53,783
commit précédent.

232
00:12:54,776 --> 00:12:57,920
D'un point de vue sécurité, le
fait que le système

233
00:12:57,920 --> 00:13:00,644
d'exploitation démarre avec ses
partitions de code en lecture

234
00:13:00,644 --> 00:13:04,823
seule semble à première vue
améliorer nettement la sécurité.

235
00:13:05,938 --> 00:13:08,851
Cela prévient certainement les
modifications accidentelles.

236
00:13:09,355 --> 00:13:12,771
Cela ne prévient cependant pas
les modifications malveillantes.

237
00:13:13,637 --> 00:13:17,943
Linux ne dispose de mécanismes
de verrouillage du système, à

238
00:13:17,943 --> 00:13:21,303
l'instar des niveaux de
sécurité d'OpenBSD, qui empêchent de

239
00:13:21,303 --> 00:13:24,303
remonter en écriture des
partitions montées en

240
00:13:24,300 --> 00:13:25,411
lecture seule.

241
00:13:26,367 --> 00:13:30,508
Il est certes possible
d'inhiber l'appel système mount avec

242
00:13:30,508 --> 00:13:35,237
des Linux Security Modules ou
seccomp-bpf, mais un processus

243
00:13:35,237 --> 00:13:37,788
root non limité pourra tout de
même effectuer ces

244
00:13:37,788 --> 00:13:38,927
modifications.

245
00:13:39,609 --> 00:13:42,348
Les développeurs d'Ostree
travaillent sur un outil appelé

246
00:13:42,348 --> 00:13:46,927
composefs qui ajoute du
contrôle d'intégrité, grâce à

247
00:13:46,927 --> 00:13:49,520
FS-Verity et des signatures
cryptographiques sur les

248
00:13:49,520 --> 00:13:51,171
fichiers gérés par Ostree.

249
00:13:52,320 --> 00:13:55,665
Les développeurs d'Ostree
travaillent notamment sur BootC,

250
00:13:55,901 --> 00:13:57,849
qui est une nouvelle manière de
déployer des systèmes

251
00:13:57,849 --> 00:14:01,303
immuables, distribués sous la
forme d'images OCI.

252
00:14:01,797 --> 00:14:04,009
BootC utilise notamment composefs.

253
00:14:05,096 --> 00:14:08,861
Il existe également des travaux
pour combiner Linux Integrity

254
00:14:08,861 --> 00:14:12,715
Measurement Architecture à
Ostree, pour arriver à des fins

255
00:14:12,715 --> 00:14:13,727
similaires.

256
00:14:14,550 --> 00:14:17,298
Néanmoins, ces preuves
cryptographiques sont en cours

257
00:14:17,298 --> 00:14:20,498
d'intégration et en leur
absence, l'immuabilité des

258
00:14:20,498 --> 00:14:23,054
systèmes de fichiers de ces
distributions n'est que

259
00:14:23,054 --> 00:14:26,054
marginalement meilleure que
celle des systèmes utilisant

260
00:14:26,050 --> 00:14:27,585
une immuabilité conventionnelle.

261
00:14:28,922 --> 00:14:31,825
Ce que ces distributions ont
pour elles, en revanche, est une

262
00:14:31,825 --> 00:14:35,134
excellente reproductibilité des
déploiements, notamment si

263
00:14:35,134 --> 00:14:37,712
l'on s'en tient à l'approche
déclarative de la configuration,

264
00:14:38,423 --> 00:14:41,435
ainsi que des processus de
mises à jour et de retour en

265
00:14:41,435 --> 00:14:44,435
arrière efficace et faciles à
mettre en œuvre.

266
00:14:45,623 --> 00:14:49,002
Pour ces raisons, Fedora CoreOS
est parmi mes systèmes

267
00:14:49,002 --> 00:14:52,371
d'exploitation favoris. Il est
notamment utilisé pour héberger

268
00:14:52,371 --> 00:14:53,369
ce podcast.

269
00:14:54,687 --> 00:14:58,752
Mais est-il possible de faire
mieux ? Peut-on concevoir des

270
00:14:58,752 --> 00:15:03,284
systèmes apportant une réelle
immuabilité avec des assurances

271
00:15:03,284 --> 00:15:04,635
cryptographiques ?

272
00:15:05,176 --> 00:15:08,644
La réponse est oui, et il est
assez probable que les auditeurs

273
00:15:08,644 --> 00:15:11,261
et auditrices soient en train
d'utiliser un tel système pour

274
00:15:11,261 --> 00:15:12,320
écouter ce podcast.

275
00:15:13,336 --> 00:15:16,508
Android est un système
d'exploitation dont

276
00:15:16,508 --> 00:15:19,600
l'immuabilité est assurée par
des vérifications de preuves

277
00:15:19,600 --> 00:15:22,818
cryptographiques. C'est
également le cas de Flatcar.

278
00:15:23,905 --> 00:15:26,611
Pour cela, ces systèmes
d'exploitation utilisent des

279
00:15:26,611 --> 00:15:30,640
images de systèmes de fichiers,
dont l'intégrité est vérifiée

280
00:15:30,640 --> 00:15:32,644
avec dm-verity.

281
00:15:33,849 --> 00:15:37,877
dm-verity est une
fonctionnalité du noyau Linux qui vérifie en

282
00:15:37,877 --> 00:15:41,407
direct et à chaque accès que
les blocs d'un périphérique de

283
00:15:41,410 --> 00:15:44,555
blocs, typiquement un disque dur,
 sont intègres.

284
00:15:45,487 --> 00:15:49,308
 S'ils ne le sont pas, la
lecture de ce bloc est bloquée.

285
00:15:50,550 --> 00:15:54,376
Grâce à cette approche, il
n'est pas possible, même pour un

286
00:15:54,376 --> 00:15:57,007
attaquant, de modifier le
système de fichiers.

287
00:15:58,117 --> 00:16:01,760
La contrepartie est que les
modifications légitimes comme

288
00:16:01,760 --> 00:16:04,447
les mises à jour ou
l'installation de nouveaux logiciels

289
00:16:04,870 --> 00:16:07,152
sont rendues relativement
complexes.

290
00:16:07,840 --> 00:16:10,823
En effet, puisque l'intégrité
cryptographique couvre

291
00:16:11,030 --> 00:16:14,588
l'ensemble du périphérique de
bloc, il n'est pas aisé de

292
00:16:14,588 --> 00:16:17,708
remplacer uniquement un seul ou
quelques fichiers.

293
00:16:19,063 --> 00:16:21,938
La solution la plus simple est
de régénérer l'image en

294
00:16:21,938 --> 00:16:22,790
intégralité.

295
00:16:23,981 --> 00:16:27,656
Il existe d'autres méthodes,
comme des diffs binaires ou

296
00:16:27,656 --> 00:16:30,494
l'utilisation de couches à
l'instar de ce qui est fait avec

297
00:16:30,494 --> 00:16:32,734
OverlayFS pour les conteneurs.

298
00:16:34,258 --> 00:16:37,364
Systemd est très actif dans
l'écosystème des images Linux et

299
00:16:37,364 --> 00:16:39,741
il propose de nombreux outils
qui vont dans ce sens.

300
00:16:40,861 --> 00:16:44,315
Ainsi, Systemd utilise des
options de la ligne de commande

301
00:16:44,315 --> 00:16:47,152
de démarrage du noyau pour
spécifier les options

302
00:16:47,152 --> 00:16:49,162
nécessaires pour dm-verity.

303
00:16:50,512 --> 00:16:56,296
De même, Systemd gère des
sysext ou system extensions, qui

304
00:16:56,296 --> 00:16:59,105
sont une implémentation de
couches permettant de faire de

305
00:16:59,105 --> 00:17:02,188
l'ajout ou du remplacement de
fichiers par superposition

306
00:17:02,188 --> 00:17:03,096
d'images.

307
00:17:03,774 --> 00:17:08,141
Il peut notamment être utilisé
par les consoles SteamDeck pour

308
00:17:08,141 --> 00:17:11,280
étendre le système quand
l'installation d'applications de

309
00:17:11,280 --> 00:17:13,783
manière non privilégiée, sous
la forme de Flatpaks,

310
00:17:14,075 --> 00:17:15,261
ne suffit pas.

311
00:17:16,381 --> 00:17:19,609
Les system extensions peuvent
être générées de plein de

312
00:17:19,609 --> 00:17:22,992
manières différentes, mais un
outil, lui aussi fourni par

313
00:17:22,992 --> 00:17:27,251
l'écosystème Systemd mérite
d'être mentionné : mkosi.

314
00:17:28,498 --> 00:17:30,691
Nous en avons déjà parlé il y a
quelques minutes pour la

315
00:17:30,691 --> 00:17:31,731
conception d'images.

316
00:17:32,560 --> 00:17:36,880
mkosi peut fabriquer autant des
images système pour le système

317
00:17:36,880 --> 00:17:39,256
entier, que pour des system
extensions.

318
00:17:40,296 --> 00:17:43,270
Il permet de faire des images
reproductibles (sous certaines

319
00:17:43,270 --> 00:17:47,284
conditions), et gère nativement
dm-verity et même les

320
00:17:47,284 --> 00:17:48,616
signatures pour Secure Boot.

321
00:17:49,900 --> 00:17:52,625
Il trouve donc sa place autant
dans l'escarcelle de personnes

322
00:17:52,625 --> 00:17:55,774
voulant faire de l'immuabilité
conventionnelle que dans celle

323
00:17:55,774 --> 00:17:57,967
de personnes souhaitant mettre
en oeuvre la forme

324
00:17:57,967 --> 00:17:59,708
d'immuabilité la plus forte.

325
00:18:00,360 --> 00:18:03,510
Voilà ! Je ne pense pas avoir
fait le tour des systèmes

326
00:18:03,510 --> 00:18:04,936
immuables. Tant s'en faut.

327
00:18:05,425 --> 00:18:08,790
Néanmoins, j'imagine que cet
épisode pourra servir de

328
00:18:08,790 --> 00:18:09,816
première introduction.

329
00:18:10,536 --> 00:18:13,063
Pour les auditeurs et les
auditrices souhaitant en savoir

330
00:18:13,063 --> 00:18:16,235
plus, je ne peux que
recommander d'écouter les nombreuses

331
00:18:16,235 --> 00:18:17,614
conférences sur ce sujet.

332
00:18:18,150 --> 00:18:22,522
Je pense notamment à la salle
Image-based Linux de FOSDEM

333
00:18:22,520 --> 00:18:26,160
2023 ou à la conférence All
Systems Go!.

334
00:18:27,049 --> 00:18:29,675
Je n'ai aucun doute que
l'immuabilité sera un élément

335
00:18:29,675 --> 00:18:32,889
central de la sécurité système
de la prochaine décennie.

336
00:18:33,585 --> 00:18:36,244
C'est d'autant plus vrai que
Secure Boot commence

337
00:18:36,244 --> 00:18:37,383
à montrer ses limites.

338
00:18:37,938 --> 00:18:41,750
J'ai d'ailleurs écrit un
article à ce sujet dans MISC où je

339
00:18:41,750 --> 00:18:44,750
fustigeais la recommandation de
l'ANSSI relative à Secure Boot

340
00:18:44,750 --> 00:18:46,014
dans son guide Linux.

341
00:18:47,140 --> 00:18:51,181
Or, une roue de secours pour le
démarrage sécurisé, après que

342
00:18:51,181 --> 00:18:54,348
Secure Boot se soit révélé un
tuyau percé, est l'emploi des

343
00:18:54,348 --> 00:18:57,910
TPM, qui se trouvent être très
friands des systèmes immuables,

344
00:18:58,240 --> 00:19:00,390
puisqu'ayant toujours la même
empreinte cryptographique !

345
00:19:01,632 --> 00:19:04,922
Pour ma part, les systèmes
d'exploitation immuable sont

346
00:19:04,920 --> 00:19:07,330
dans mes pratiques SecDevOps
depuis maintenant

347
00:19:07,330 --> 00:19:08,280
de nombreuses années.

348
00:19:09,195 --> 00:19:12,555
Chez la plupart de mes clients,
je rencontre une légère

349
00:19:12,555 --> 00:19:15,555
résistance à passer à des
distributions Linux spécialisées

350
00:19:15,938 --> 00:19:19,976
comme Fedora CoreOS ou Flatcar
par appréhension d'avoir des

351
00:19:19,976 --> 00:19:21,167
difficultés de recrutement.

352
00:19:21,740 --> 00:19:24,287
J'arrive néanmoins assez
facilement à les convaincre

353
00:19:24,287 --> 00:19:26,296
d'utiliser au moins l'approche
de l'immuabilité

354
00:19:26,296 --> 00:19:30,098
conventionnelle, qui offre déjà
des avantages assez nets de

355
00:19:30,098 --> 00:19:32,974
reproductibilité des
déploiements et d'auditabilité.

356
00:19:33,967 --> 00:19:36,997
L'utilisation d'outils de
configuration déclarative comme

357
00:19:36,997 --> 00:19:40,484
cloud-init reste cependant une
souffrance du quotidien,

358
00:19:40,484 --> 00:19:41,816
comparé à Ignition.

359
00:19:42,527 --> 00:19:46,592
De même, les mises à jour et
les retours en arrière dans le

360
00:19:46,592 --> 00:19:50,202
cas de l'immuabilité
conventionnelle sont moins aisés qu'avec

361
00:19:50,202 --> 00:19:51,750
des distributions conçues pour.

362
00:19:52,668 --> 00:19:55,120
J'aspire à ce que ces
distributions deviennent plus

363
00:19:55,120 --> 00:19:58,555
présentes, et que les habitudes
DevOps évoluent vers elles,

364
00:19:58,894 --> 00:20:01,990
afin qu'elles puissent se
départir des quelques verrues

365
00:20:01,990 --> 00:20:04,395
violant le principe W xor X qui
persistent encore.

366
00:20:05,440 --> 00:20:08,569
J'espère donc vous avoir
peut-être fait découvrir, ou

367
00:20:08,570 --> 00:20:11,948
mieux, vous avoir convaincu
d'adopter l'approche immuable !

368
00:20:12,898 --> 00:20:15,195
Si c'est le cas, je vous
conseille d'essayer Fedora Core

369
00:20:15,195 --> 00:20:19,760
OS, plus facile, ou Flatcar,
plus immuable, qui sont deux

370
00:20:19,760 --> 00:20:20,894
superbes distributions.

371
00:20:21,769 --> 00:20:24,343
Dans le prochain épisode, nous
verrons que cette approche

372
00:20:24,343 --> 00:20:26,748
comporte cependant quelques
défis inattendus.

373
00:20:27,722 --> 00:20:30,564
Un que je n'avais pas anticipé
lorsque j'ai emprunté cette voie

374
00:20:30,564 --> 00:20:32,094
est la gestion des secrets !

375
00:20:32,795 --> 00:20:36,202
En effet, les gestionnaires de
configuration par mutation sont

376
00:20:36,200 --> 00:20:38,752
souvent utilisés pour déployer
des secrets qu'ils stockent sous

377
00:20:38,752 --> 00:20:41,543
une forme chiffrée dans le
gestionnaire de version de code.

378
00:20:42,291 --> 00:20:46,456
Or, avec l'approche immuable,
on ne se connecte pas ou peu sur

379
00:20:46,456 --> 00:20:49,049
les machines, puisqu'il n'est
pas nécessaire de les modifier !

380
00:20:49,854 --> 00:20:52,649
Aller, je ne vous en dis pas
plus ; cet épisode est déjà bien

381
00:20:52,649 --> 00:20:53,374
assez long !

382
00:20:53,811 --> 00:20:56,418
Comme à chaque fois, je vous
rappelle que vous pouvez

383
00:20:56,418 --> 00:21:00,404
commenter, liker et même
booster ce podcast sur le fédiverse.

384
00:21:01,120 --> 00:21:04,338
Il vous suffit de copier/coller
l'adresse de cet épisode dans

385
00:21:04,340 --> 00:21:06,912
le champ de recherche de votre
logiciel, puis d'interagir avec

386
00:21:06,912 --> 00:21:07,731
le post.

387
00:21:08,230 --> 00:21:11,364
N'hésitez pas à me dire si cet
épisode vous a plu, ou à

388
00:21:11,364 --> 00:21:12,983
apporter une critique
constructive !

389
00:21:13,360 --> 00:21:13,910
À bientôt !