1
00:00:05,239 --> 00:00:07,259
[music]

2
00:00:09,825 --> 00:00:11,845
[music]

3
00:00:15,120 --> 00:00:17,199
All right, welcome back. If you could

4
00:00:17,199 --> 00:00:19,359
find some seats or if you have a blank

5
00:00:19,359 --> 00:00:21,119
seat next to you, maybe compress a

6
00:00:21,119 --> 00:00:22,880
little bit.

7
00:00:22,880 --> 00:00:24,800
Amazing. Um, I just forgot to mention at

8
00:00:24,800 --> 00:00:26,160
the start of the last one, hi, I'm

9
00:00:26,160 --> 00:00:28,720
Charelle. This is Fraser. Um, we're

10
00:00:28,720 --> 00:00:30,400
co-organizers for this track. We do

11
00:00:30,400 --> 00:00:32,320
security stuff at Red Hat. Um, come say

12
00:00:32,320 --> 00:00:34,160
hi if you want. All right, without

13
00:00:34,160 --> 00:00:36,079
further ado, our next talk is called Can

14
00:00:36,079 --> 00:00:38,559
I Trust You? Serviceto Identity with

15
00:00:38,559 --> 00:00:41,040
Spiffy. So, please make welcome Oliver

16
00:00:41,040 --> 00:00:42,575
Basset.

17
00:00:42,575 --> 00:00:44,595
[applause]

18
00:00:56,879 --> 00:00:59,920
All right, first time trying to use a

19
00:00:59,920 --> 00:01:01,280
terminal presenter. So, we'll see how

20
00:01:01,280 --> 00:01:04,320
that goes. Um,

21
00:01:04,320 --> 00:01:05,920
so

22
00:01:05,920 --> 00:01:09,200
the premise of my talk today is that

23
00:01:09,200 --> 00:01:11,439
uh when service A calls service B in

24
00:01:11,439 --> 00:01:14,560
your microser environment, how does

25
00:01:14,560 --> 00:01:16,799
service B know that it's really service

26
00:01:16,799 --> 00:01:19,360
A and not just something else?

27
00:01:19,360 --> 00:01:22,000
Um, so we're going to go on a little bit

28
00:01:22,000 --> 00:01:24,080
of a journey with Sam the S. This was

29
00:01:24,080 --> 00:01:27,920
originally a platform focused talk. So,

30
00:01:27,920 --> 00:01:29,680
excuse me. Lots of community stuff in

31
00:01:29,680 --> 00:01:32,000
here. Um,

32
00:01:32,000 --> 00:01:35,439
and then every night he gets woken up by

33
00:01:35,439 --> 00:01:38,560
the happy attacker called Omen. Um, and

34
00:01:38,560 --> 00:01:40,799
through a series of challenges

35
00:01:40,799 --> 00:01:43,280
eventually discovers Spiffy and what it

36
00:01:43,280 --> 00:01:45,200
does. So then we'll go into that and um

37
00:01:45,200 --> 00:01:47,600
hopefully leave you with some something

38
00:01:47,600 --> 00:01:49,920
new that you've learned. Um my name is

39
00:01:49,920 --> 00:01:52,880
Oliver Basset. Um I'm a

40
00:01:52,880 --> 00:01:56,079
platform engineer slash developer

41
00:01:56,079 --> 00:01:58,719
slashperson that manages a product that

42
00:01:58,719 --> 00:02:01,200
has distributed Kubernetes platforms and

43
00:02:01,200 --> 00:02:04,159
we needed to find a way to get all of

44
00:02:04,159 --> 00:02:05,920
them to talk to each other in a way that

45
00:02:05,920 --> 00:02:07,360
was at least a little bit more secure

46
00:02:07,360 --> 00:02:08,879
than some of the other ideas that are

47
00:02:08,879 --> 00:02:10,720
presented in this talk at the beginning.

48
00:02:10,720 --> 00:02:13,599
Um, so, uh, I've got a kind of a

49
00:02:13,599 --> 00:02:16,640
declaration about AI here. Um, I used AI

50
00:02:16,640 --> 00:02:19,440
a lot in preparing the slides and the

51
00:02:19,440 --> 00:02:22,800
code samples. Um, but the talk and the

52
00:02:22,800 --> 00:02:25,760
structure was, um, written by me, so

53
00:02:25,760 --> 00:02:28,400
hopefully I don't mess it up too bad.

54
00:02:28,400 --> 00:02:30,160
Um, all of the the code samples have

55
00:02:30,160 --> 00:02:33,040
been checked. They do work. Um, so

56
00:02:33,040 --> 00:02:34,319
you're welcome to use them, but they are

57
00:02:34,319 --> 00:02:36,160
demo quality, not production quality.

58
00:02:36,160 --> 00:02:39,360
So, uh, and I'll share a repo at the

59
00:02:39,360 --> 00:02:40,800
end.

60
00:02:40,800 --> 00:02:44,720
Um, okay. So,

61
00:02:44,720 --> 00:02:47,440
we've kind of all done this kind of

62
00:02:47,440 --> 00:02:50,879
thing where you have a set of services,

63
00:02:50,879 --> 00:02:52,480
you build a nice big perimeter around

64
00:02:52,480 --> 00:02:54,720
the outside, you secure it, you maybe

65
00:02:54,720 --> 00:02:57,280
put a front end in or an API in front of

66
00:02:57,280 --> 00:03:00,319
that, uh, and you secure the user access

67
00:03:00,319 --> 00:03:03,040
to the API server.

68
00:03:03,040 --> 00:03:05,599
But sometimes you sort of stop at that

69
00:03:05,599 --> 00:03:07,440
and rely on that perimeter to protect

70
00:03:07,440 --> 00:03:10,480
the services inside that wall. So it's

71
00:03:10,480 --> 00:03:13,519
kind of like castle architecture. Um the

72
00:03:13,519 --> 00:03:15,599
premise being that inside the walls is

73
00:03:15,599 --> 00:03:17,519
safe cuz I've secured the outside and no

74
00:03:17,519 --> 00:03:18,640
one can get in there that shouldn't be

75
00:03:18,640 --> 00:03:22,319
in there. Um and I've authenticated the

76
00:03:22,319 --> 00:03:24,560
inbound on the user. So we should be

77
00:03:24,560 --> 00:03:26,400
good

78
00:03:26,400 --> 00:03:28,159
cuz it's but the problem is that inside

79
00:03:28,159 --> 00:03:31,040
the network is not an identity. Uh, and

80
00:03:31,040 --> 00:03:33,120
any service shouldn't be able to walk up

81
00:03:33,120 --> 00:03:34,959
to another one and say, "Hey, it's me."

82
00:03:34,959 --> 00:03:36,720
And the service goes, "Yeah, cool. Do

83
00:03:36,720 --> 00:03:40,159
what you want to do." So,

84
00:03:40,159 --> 00:03:42,159
the system for round one, uh, the

85
00:03:42,159 --> 00:03:46,000
gateway, the API, um, into the order

86
00:03:46,000 --> 00:03:48,400
service. The order service processes

87
00:03:48,400 --> 00:03:50,480
payments, sends off to the dispatch

88
00:03:50,480 --> 00:03:53,760
service, the dispatch service handles

89
00:03:53,760 --> 00:03:55,680
the logistics and the packing orders to

90
00:03:55,680 --> 00:03:57,599
the warehouse, and then the product gets

91
00:03:57,599 --> 00:03:59,200
shipped.

92
00:03:59,200 --> 00:04:01,439
because you know inside those walls it's

93
00:04:01,439 --> 00:04:06,480
it's nice and safe, right? Um so

94
00:04:06,480 --> 00:04:08,400
there's our authentication or lack

95
00:04:08,400 --> 00:04:11,360
thereof of it authentication. Um so

96
00:04:11,360 --> 00:04:13,200
we've got a ship and it comes in we

97
00:04:13,200 --> 00:04:16,720
dispatch and it's shipped. Very simple

98
00:04:16,720 --> 00:04:19,600
code.

99
00:04:19,600 --> 00:04:21,359
Enter

100
00:04:21,359 --> 00:04:22,960
our guy in a dark room in front of

101
00:04:22,960 --> 00:04:26,560
screens coding. Thanks, Upsplash. Um,

102
00:04:26,560 --> 00:04:30,560
who discovered a way in a zero day AI.

103
00:04:30,560 --> 00:04:32,880
Got to love it. Uh, these days, maybe

104
00:04:32,880 --> 00:04:35,199
he's got access to mythos. Probably not.

105
00:04:35,199 --> 00:04:36,720
Um,

106
00:04:36,720 --> 00:04:38,960
he's broken his way in and after a

107
00:04:38,960 --> 00:04:41,919
little bit of lateral movement um, and

108
00:04:41,919 --> 00:04:45,840
discovery, finds the dispatch service

109
00:04:45,840 --> 00:04:48,560
and ships himself a PlayStation 5. I

110
00:04:48,560 --> 00:04:49,919
mean, he's not the smartest. He shipped

111
00:04:49,919 --> 00:04:52,479
it to his own layer. Obviously we can

112
00:04:52,479 --> 00:04:56,400
trace him but you know for example

113
00:04:56,400 --> 00:04:58,160
um

114
00:04:58,160 --> 00:05:02,320
pager goes off Sam gets woken up

115
00:05:02,320 --> 00:05:06,240
it's very early morning um all these

116
00:05:06,240 --> 00:05:08,160
orders are going out there's no matching

117
00:05:08,160 --> 00:05:10,880
payments what are we going to do so he

118
00:05:10,880 --> 00:05:13,280
explores the system he figures out where

119
00:05:13,280 --> 00:05:15,759
Omen entered patches that quickly and

120
00:05:15,759 --> 00:05:18,560
then goes well

121
00:05:18,560 --> 00:05:22,400
how can I prevent that lateral movement

122
00:05:22,400 --> 00:05:25,280
I know

123
00:05:25,280 --> 00:05:27,759
I'll put a shared secret in between all

124
00:05:27,759 --> 00:05:30,960
my services. And so he introduces a a

125
00:05:30,960 --> 00:05:33,840
header key between the services um

126
00:05:33,840 --> 00:05:35,680
injects it into all the pods and the

127
00:05:35,680 --> 00:05:38,240
environment. And suddenly we have a way

128
00:05:38,240 --> 00:05:42,240
of you know securing access to those

129
00:05:42,240 --> 00:05:46,160
services. Looks something like this. Um

130
00:05:46,160 --> 00:05:48,160
environment injection.

131
00:05:48,160 --> 00:05:49,919
We look at what's sent through in the

132
00:05:49,919 --> 00:05:52,080
headers. we match the keys. If it

133
00:05:52,080 --> 00:05:54,080
doesn't match, we raise a 401.

134
00:05:54,080 --> 00:05:57,440
Otherwise, we dispatch that order.

135
00:05:57,440 --> 00:06:00,560
Problem with that is

136
00:06:00,560 --> 00:06:02,639
Omen comes along and scrapes the

137
00:06:02,639 --> 00:06:04,000
environment through another

138
00:06:04,000 --> 00:06:06,720
vulnerability he found. Um, so so the

139
00:06:06,720 --> 00:06:09,280
challenge is you've got this

140
00:06:09,280 --> 00:06:12,000
bearer token, but it's a shared secret

141
00:06:12,000 --> 00:06:15,039
and it's typically longived. So you've

142
00:06:15,039 --> 00:06:16,960
injected it into your pods. It's

143
00:06:16,960 --> 00:06:18,800
throughout all of your systems. Maybe

144
00:06:18,800 --> 00:06:20,319
you share it across multiple services

145
00:06:20,319 --> 00:06:21,759
because that that seemed like a good

146
00:06:21,759 --> 00:06:23,520
idea at the time. It probably wasn't, by

147
00:06:23,520 --> 00:06:26,400
the way. Um, but all it does is prove

148
00:06:26,400 --> 00:06:28,000
that you have that token. It doesn't

149
00:06:28,000 --> 00:06:30,319
prove that you are the service you think

150
00:06:30,319 --> 00:06:32,880
you are. And the problem is you don't

151
00:06:32,880 --> 00:06:36,560
rotate it cuz it's painful. Um, and it's

152
00:06:36,560 --> 00:06:38,880
in every single pod and service that

153
00:06:38,880 --> 00:06:40,639
uses it. So there's lots of places it

154
00:06:40,639 --> 00:06:42,880
can be harvested from. Uh, and if you

155
00:06:42,880 --> 00:06:44,800
share the same key, then that one key

156
00:06:44,800 --> 00:06:48,160
can be used across a lot of things. Um,

157
00:06:48,160 --> 00:06:51,759
so pager goes off again. Sam gets woken

158
00:06:51,759 --> 00:06:54,479
up. All right, this was a bad idea.

159
00:06:54,479 --> 00:06:56,639
Maybe that wasn't the way to secure it.

160
00:06:56,639 --> 00:06:58,880
Rotate all the keys, lock down the

161
00:06:58,880 --> 00:07:00,400
systems,

162
00:07:00,400 --> 00:07:02,880
and then how can I prevent this from

163
00:07:02,880 --> 00:07:04,400
happening?

164
00:07:04,400 --> 00:07:06,720
I know. I heard about this thing called

165
00:07:06,720 --> 00:07:10,160
MTLS. If I have a certificate on the

166
00:07:10,160 --> 00:07:12,319
systems that proves the identity of the

167
00:07:12,319 --> 00:07:15,840
client when it connects, then hopefully

168
00:07:15,840 --> 00:07:19,360
we have a way of proving who it is. It's

169
00:07:19,360 --> 00:07:20,720
not something that can be incepted

170
00:07:20,720 --> 00:07:22,160
intercepted in flight. You have to

171
00:07:22,160 --> 00:07:25,199
actually get hold of that key. Um so,

172
00:07:25,199 --> 00:07:28,240
you know, maybe this is the way.

173
00:07:28,240 --> 00:07:30,319
How does that look? Um you secure the

174
00:07:30,319 --> 00:07:33,520
service. Uh you have to load all these

175
00:07:33,520 --> 00:07:35,199
keys. So, you've got both the key file

176
00:07:35,199 --> 00:07:36,960
and the certificate. I'm sure this

177
00:07:36,960 --> 00:07:39,680
audience knows all of this stuff. Um the

178
00:07:39,680 --> 00:07:41,280
CAerts

179
00:07:41,280 --> 00:07:43,599
uh and then we do a verification and say

180
00:07:43,599 --> 00:07:45,680
that we require for client certification

181
00:07:45,680 --> 00:07:48,880
this um a certificate from from the

182
00:07:48,880 --> 00:07:51,840
client that's signed by this CA.

183
00:07:51,840 --> 00:07:54,400
But the problem is

184
00:07:54,400 --> 00:07:56,000
we've got to get that key out there.

185
00:07:56,000 --> 00:07:57,440
We've got to sign the certificates on

186
00:07:57,440 --> 00:07:59,840
every node. The keys and the

187
00:07:59,840 --> 00:08:02,720
certificates live on the pods. So there

188
00:08:02,720 --> 00:08:05,919
is a way to get them. If you do it

189
00:08:05,919 --> 00:08:08,560
badly, which this assumes,

190
00:08:08,560 --> 00:08:10,400
um you don't check the identity on the

191
00:08:10,400 --> 00:08:12,319
certificate. You just check that it's

192
00:08:12,319 --> 00:08:13,840
signed. So at least it's, you know,

193
00:08:13,840 --> 00:08:16,080
valid. Um the certificates last for

194
00:08:16,080 --> 00:08:19,039
typically a year. Now with publics, that

195
00:08:19,039 --> 00:08:21,520
problem's mostly gone away thanks to

196
00:08:21,520 --> 00:08:23,599
let's encrypt and automatic key

197
00:08:23,599 --> 00:08:26,960
locations, but rotation. But inside a

198
00:08:26,960 --> 00:08:29,759
corporate environment, that's not

199
00:08:29,759 --> 00:08:31,199
usually the case. If you've signed your

200
00:08:31,199 --> 00:08:33,200
own keys, you've been a bit lazy and

201
00:08:33,200 --> 00:08:34,800
you've got these yearlong certificates

202
00:08:34,800 --> 00:08:37,680
everywhere. Um, certificate revocation

203
00:08:37,680 --> 00:08:40,560
lists, don't know anybody that actually

204
00:08:40,560 --> 00:08:45,760
checks them. Um, so what we've got is is

205
00:08:45,760 --> 00:08:47,360
the client does the client hold a

206
00:08:47,360 --> 00:08:50,800
certificate that's signed by C RCA? Yes.

207
00:08:50,800 --> 00:08:52,560
So what does that mean? Well, say we've

208
00:08:52,560 --> 00:08:55,680
got a partner who has a certificate for

209
00:08:55,680 --> 00:08:57,680
valid use.

210
00:08:57,680 --> 00:09:01,839
Well, that gets harvested, taken,

211
00:09:01,839 --> 00:09:04,959
and then Omen later can use that to

212
00:09:04,959 --> 00:09:06,880
attack any other service that's only

213
00:09:06,880 --> 00:09:10,000
checking the validity of the CA and not

214
00:09:10,000 --> 00:09:12,160
the actual identification

215
00:09:12,160 --> 00:09:14,560
because again, he's got the key and he's

216
00:09:14,560 --> 00:09:16,160
got theert. So, that's that's kind of

217
00:09:16,160 --> 00:09:20,240
all there is to it. So off he goes and

218
00:09:20,240 --> 00:09:24,240
the page goes off again and well

219
00:09:24,240 --> 00:09:25,760
Sam gets woken up and goes, "Well, we're

220
00:09:25,760 --> 00:09:28,000
we're shipping again. How many

221
00:09:28,000 --> 00:09:32,399
PlayStations has this guy got now?" Uh

222
00:09:32,399 --> 00:09:35,360
so he's investigated. He realized that

223
00:09:35,360 --> 00:09:38,399
someone's calling from but but we didn't

224
00:09:38,399 --> 00:09:41,200
do the identity checking. So, you know,

225
00:09:41,200 --> 00:09:42,560
we don't know which certificate it is.

226
00:09:42,560 --> 00:09:46,640
So we have to rotate them all um

227
00:09:46,640 --> 00:09:49,440
and close the gap. So how can we do

228
00:09:49,440 --> 00:09:51,920
that? Now we could put an identity check

229
00:09:51,920 --> 00:09:53,760
and that it at least solved one of the

230
00:09:53,760 --> 00:09:55,920
problems. We know who who was the

231
00:09:55,920 --> 00:09:58,080
breach. Um but it doesn't solve the

232
00:09:58,080 --> 00:10:00,000
actual problem.

233
00:10:00,000 --> 00:10:04,240
So then Sam discovers Spiffy,

234
00:10:04,240 --> 00:10:06,959
the secure production identity framework

235
00:10:06,959 --> 00:10:09,360
for everyone. It's such a chipper name.

236
00:10:09,360 --> 00:10:13,440
Um, so it's a CNCF project for doing

237
00:10:13,440 --> 00:10:15,680
provable cryptographic identity for your

238
00:10:15,680 --> 00:10:17,519
workloads.

239
00:10:17,519 --> 00:10:20,320
Um, and then Spy, which is part of the

240
00:10:20,320 --> 00:10:22,560
Spiffy site, is is an implementation of

241
00:10:22,560 --> 00:10:26,640
the the standard. Um, so what does that

242
00:10:26,640 --> 00:10:28,480
look like?

243
00:10:28,480 --> 00:10:30,880
Um, so the idea is every workload is

244
00:10:30,880 --> 00:10:33,680
given an identity. So it's made up of

245
00:10:33,680 --> 00:10:36,399
this fancy URL which starts with a

246
00:10:36,399 --> 00:10:40,320
spiffy. um the trust domain uh acme.in

247
00:10:40,320 --> 00:10:42,959
internal in this case um and then a path

248
00:10:42,959 --> 00:10:45,440
which is the workload's

249
00:10:45,440 --> 00:10:48,480
identity um that varies depending on how

250
00:10:48,480 --> 00:10:50,399
you want to build it uh and that lives

251
00:10:50,399 --> 00:10:53,360
inside a certificate. So that's that's

252
00:10:53,360 --> 00:10:56,320
great but not too dissimilar to the MTLS

253
00:10:56,320 --> 00:10:59,600
certificates we talked about before. Um

254
00:10:59,600 --> 00:11:03,760
so what it is is a um spiffy verifiable

255
00:11:03,760 --> 00:11:06,480
identity object. Uh, so X5 and I insert

256
00:11:06,480 --> 00:11:08,560
is the most common if you're doing MTLS

257
00:11:08,560 --> 00:11:12,560
because MTLS isn't inherently bad. Um,

258
00:11:12,560 --> 00:11:16,000
or it can live inside of Jot tokens.

259
00:11:16,000 --> 00:11:18,720
Um, the difference with these is you

260
00:11:18,720 --> 00:11:21,440
don't have a key on the machine.

261
00:11:21,440 --> 00:11:25,120
Um, so and theerts are shortlived. So by

262
00:11:25,120 --> 00:11:28,320
default the X509 lives for an hour uh

263
00:11:28,320 --> 00:11:31,200
and rotates after 20 minutes. Uh, and

264
00:11:31,200 --> 00:11:34,880
the jotss live for 5 minutes at most.

265
00:11:34,880 --> 00:11:37,600
um and rotate as frequently as you want

266
00:11:37,600 --> 00:11:39,600
to use them. Basically, generally you

267
00:11:39,600 --> 00:11:43,200
would get one before making a call. Um

268
00:11:43,200 --> 00:11:44,880
and that happens in an automatic

269
00:11:44,880 --> 00:11:47,600
fashion. Uh and the way that works is

270
00:11:47,600 --> 00:11:50,399
through the workload API. Um so every

271
00:11:50,399 --> 00:11:53,360
node that's part of a spiffy environment

272
00:11:53,360 --> 00:11:56,800
has a

273
00:11:56,800 --> 00:12:00,240
Unix socket that that runs. Um the node

274
00:12:00,240 --> 00:12:01,839
is already attested and we'll talk about

275
00:12:01,839 --> 00:12:03,760
that in a little bit. Um, and then the

276
00:12:03,760 --> 00:12:05,680
workload connects to the socket and asks

277
00:12:05,680 --> 00:12:08,959
for its identity. It doesn't provide

278
00:12:08,959 --> 00:12:11,040
anything. It just connects and asks for

279
00:12:11,040 --> 00:12:14,560
its identity. Then the workload API

280
00:12:14,560 --> 00:12:17,360
looks at the process that's calling it

281
00:12:17,360 --> 00:12:20,000
and decides based on whatever selectors

282
00:12:20,000 --> 00:12:24,000
have been set up um whether or not it's

283
00:12:24,000 --> 00:12:25,680
allowed an identity and if it is then

284
00:12:25,680 --> 00:12:28,560
what identity it gets. So in a Unix

285
00:12:28,560 --> 00:12:32,800
system that's process ids, user ids, um

286
00:12:32,800 --> 00:12:35,600
hashes of executables,

287
00:12:35,600 --> 00:12:37,519
um and various other things. There's

288
00:12:37,519 --> 00:12:39,440
it's an extensible

289
00:12:39,440 --> 00:12:40,800
um framework in a Kubernetes

290
00:12:40,800 --> 00:12:42,639
environment. That's service account

291
00:12:42,639 --> 00:12:46,480
names, pod names, that kind of thing. Um

292
00:12:46,480 --> 00:12:48,959
so the overall structure is you have a a

293
00:12:48,959 --> 00:12:51,279
spy server which is your root of trust

294
00:12:51,279 --> 00:12:53,440
in your spiffy environment. It does

295
00:12:53,440 --> 00:12:55,200
support federation. It does support

296
00:12:55,200 --> 00:12:56,800
nesting and a bunch of other bits and

297
00:12:56,800 --> 00:13:00,560
pieces um to make it really complicated.

298
00:13:00,560 --> 00:13:03,279
Um but the core of it is a root of trust

299
00:13:03,279 --> 00:13:05,279
that signs all of the requests and

300
00:13:05,279 --> 00:13:07,760
maintains the database of what workloads

301
00:13:07,760 --> 00:13:11,360
are allowed what. Um every node in your

302
00:13:11,360 --> 00:13:13,519
environment runs a spire agent which

303
00:13:13,519 --> 00:13:17,519
attests itself to the server. Now, agent

304
00:13:17,519 --> 00:13:22,079
adaptation is based on um the the

305
00:13:22,079 --> 00:13:24,720
easiest is is is a a join token. So, you

306
00:13:24,720 --> 00:13:26,399
get a disposable join token the first

307
00:13:26,399 --> 00:13:28,880
time. Once it's attested, it's in and it

308
00:13:28,880 --> 00:13:31,040
rotates those credentials. If they ever

309
00:13:31,040 --> 00:13:33,519
expire, you have to re manually generate

310
00:13:33,519 --> 00:13:36,480
a join token. So, that's not ideal. um

311
00:13:36,480 --> 00:13:39,440
TPM modules inside systems

312
00:13:39,440 --> 00:13:43,519
um cloud provider uh internal reference

313
00:13:43,519 --> 00:13:45,920
APIs that provide identity information

314
00:13:45,920 --> 00:13:47,519
can be used and again there's an

315
00:13:47,519 --> 00:13:49,920
extensible framework for us we ended up

316
00:13:49,920 --> 00:13:53,200
building our own um for what we needed

317
00:13:53,200 --> 00:13:54,800
um but there's there's a ton of options

318
00:13:54,800 --> 00:13:58,000
out there um and so that ensures that

319
00:13:58,000 --> 00:14:00,000
the the node is attested and that we

320
00:14:00,000 --> 00:14:02,480
know that it's a valid node and then you

321
00:14:02,480 --> 00:14:04,720
have a workload atestation that runs on

322
00:14:04,720 --> 00:14:06,320
top of that. So then the agent is

323
00:14:06,320 --> 00:14:08,240
serving the workloads. The workloads

324
00:14:08,240 --> 00:14:11,120
connect based on selectors. Um and then

325
00:14:11,120 --> 00:14:13,760
they get their identity. So the entire

326
00:14:13,760 --> 00:14:15,279
process is verifiable all the way

327
00:14:15,279 --> 00:14:20,000
through. Um this is what an entry to

328
00:14:20,000 --> 00:14:22,399
create a workload identity looks like.

329
00:14:22,399 --> 00:14:24,720
So in this example, it's our order

330
00:14:24,720 --> 00:14:28,639
service. Um and it's the path there

331
00:14:28,639 --> 00:14:30,560
represents that it's in the namespace

332
00:14:30,560 --> 00:14:33,199
prod. uh and it's a Kubernetes service

333
00:14:33,199 --> 00:14:36,079
account by auto service. So that's a

334
00:14:36,079 --> 00:14:39,680
pretty simple one, but that ensures that

335
00:14:39,680 --> 00:14:41,519
when that workload connects, if it's not

336
00:14:41,519 --> 00:14:43,120
running in the prod name space under

337
00:14:43,120 --> 00:14:44,720
that service account, it won't get that

338
00:14:44,720 --> 00:14:49,760
identity. Um and that's the gist of

339
00:14:49,760 --> 00:14:53,120
how it works at a really high level. Um

340
00:14:53,120 --> 00:14:54,959
so how does that work based on the

341
00:14:54,959 --> 00:14:57,040
attacks we've seen? Well, firstly,

342
00:14:57,040 --> 00:14:59,680
there's nothing to harvest. So there's

343
00:14:59,680 --> 00:15:02,560
no keys to pull off the pods.

344
00:15:02,560 --> 00:15:06,160
There's no um identity to harvest out of

345
00:15:06,160 --> 00:15:09,760
environment variables. Um if you steal

346
00:15:09,760 --> 00:15:13,519
the certificate in flight somehow, it

347
00:15:13,519 --> 00:15:15,279
expires in a really short period of

348
00:15:15,279 --> 00:15:18,240
time. Um and if you manage to get on the

349
00:15:18,240 --> 00:15:20,160
node and ask for an identity, you're not

350
00:15:20,160 --> 00:15:22,639
going to get the one you want. Um so it

351
00:15:22,639 --> 00:15:26,079
kind of defeats a lot of the

352
00:15:26,079 --> 00:15:28,720
ways of doing this. Um,

353
00:15:28,720 --> 00:15:32,079
so I'll try and do some quick demos to

354
00:15:32,079 --> 00:15:34,000
sort of show how it works. Um, so this

355
00:15:34,000 --> 00:15:37,920
is the the Python Spiffy toolkit. Um,

356
00:15:37,920 --> 00:15:39,199
does exist in a ton of different

357
00:15:39,199 --> 00:15:41,600
languages. I don't use the Python one

358
00:15:41,600 --> 00:15:43,519
day-to-day. We most of our code base is

359
00:15:43,519 --> 00:15:47,360
is Rust. So, uh, it's it's it's not

360
00:15:47,360 --> 00:15:49,440
super familiar. So, that's the AI

361
00:15:49,440 --> 00:15:52,880
generated help here. Um, but, uh, the

362
00:15:52,880 --> 00:15:55,120
code tests do work. So I've written a

363
00:15:55,120 --> 00:15:58,800
few little just scripts. Um

364
00:15:58,800 --> 00:16:01,920
so this generates the spiffy ID and you

365
00:16:01,920 --> 00:16:04,800
can see the expiry is at 2:35.

366
00:16:04,800 --> 00:16:07,759
So that's roughly 30 minutes from now,

367
00:16:07,759 --> 00:16:11,519
40 minutes from now. Um

368
00:16:11,519 --> 00:16:13,199
and there was no secret presented to

369
00:16:13,199 --> 00:16:15,920
attain the attendee. Um that comes from

370
00:16:15,920 --> 00:16:19,519
the code that looks typo

371
00:16:19,519 --> 00:16:20,959
looks kind of like that. It's a really

372
00:16:20,959 --> 00:16:22,639
simple. It's the same as what the slide

373
00:16:22,639 --> 00:16:25,040
kind of shows. Um, this uses the default

374
00:16:25,040 --> 00:16:26,720
location of the workload socket. So, you

375
00:16:26,720 --> 00:16:28,320
can see there's nothing specified.

376
00:16:28,320 --> 00:16:31,279
There's no configuration needed. Um, it

377
00:16:31,279 --> 00:16:33,279
talks to the default socket. Sorry, no

378
00:16:33,279 --> 00:16:35,199
configuration needed in the code. The

379
00:16:35,199 --> 00:16:37,839
setting up all of Spiffy does require a

380
00:16:37,839 --> 00:16:40,399
fair bit of planning and work. Um, but

381
00:16:40,399 --> 00:16:42,399
that's why it was a platform talk, not a

382
00:16:42,399 --> 00:16:44,560
crypto one originally, security one

383
00:16:44,560 --> 00:16:47,199
originally. Um, and then that kind of

384
00:16:47,199 --> 00:16:51,839
presents it. Um so if

385
00:16:51,839 --> 00:16:54,959
omen um so so yeah the the security on

386
00:16:54,959 --> 00:16:57,120
the listeners uh so on the dispatch

387
00:16:57,120 --> 00:16:59,759
service um what we do is we set up a

388
00:16:59,759 --> 00:17:02,560
automatically rotating so the spiffy TLS

389
00:17:02,560 --> 00:17:04,000
library provides an automatically

390
00:17:04,000 --> 00:17:07,199
rotating SSL credential store. So you

391
00:17:07,199 --> 00:17:09,839
can pass that to most

392
00:17:09,839 --> 00:17:12,799
um things that use the standard SSL

393
00:17:12,799 --> 00:17:14,319
library configurations and it will

394
00:17:14,319 --> 00:17:15,679
handle automatically rotating the

395
00:17:15,679 --> 00:17:18,160
credentials when they rotate. So your

396
00:17:18,160 --> 00:17:20,799
calls just work. You don't have to code

397
00:17:20,799 --> 00:17:25,360
in the paths to manage that. Um and then

398
00:17:25,360 --> 00:17:28,480
uh effectively we we authorize a single

399
00:17:28,480 --> 00:17:31,200
ID of the auto service that's allowed to

400
00:17:31,200 --> 00:17:35,360
connect to this this listener. Um, so

401
00:17:35,360 --> 00:17:37,600
what that means is if you don't have

402
00:17:37,600 --> 00:17:40,480
that specific spiffy ID granted in a

403
00:17:40,480 --> 00:17:42,080
appropriately authorized way, then you

404
00:17:42,080 --> 00:17:45,679
can't connect and that kind of ends up

405
00:17:45,679 --> 00:17:49,120
uh we were generous with um

406
00:17:49,120 --> 00:17:51,520
with Omen and we actually gave him an

407
00:17:51,520 --> 00:17:53,520
identity. It's just the wrong one. Um

408
00:17:53,520 --> 00:17:56,080
but you see straight away the SSL errors

409
00:17:56,080 --> 00:17:58,320
on trying to connect. Um, and that's

410
00:17:58,320 --> 00:18:02,600
because it's not the right one.

411
00:18:03,760 --> 00:18:06,880
Um, and the same thing can be on the

412
00:18:06,880 --> 00:18:08,799
client side because it's mutual TLS,

413
00:18:08,799 --> 00:18:11,520
right? So, um, you can with your client

414
00:18:11,520 --> 00:18:13,280
when you connect out, you can guarantee

415
00:18:13,280 --> 00:18:15,360
that you talk to the correct identity on

416
00:18:15,360 --> 00:18:18,320
the listener on the other end. Um, so

417
00:18:18,320 --> 00:18:23,840
our checkout actually does work.

418
00:18:23,840 --> 00:18:26,840
Um,

419
00:18:28,799 --> 00:18:30,720
so we call into our checkout service

420
00:18:30,720 --> 00:18:32,640
with an authenticated user endpoint.

421
00:18:32,640 --> 00:18:34,640
Okay, so I skipped the user off in this

422
00:18:34,640 --> 00:18:38,080
example, but um and then the the

423
00:18:38,080 --> 00:18:40,160
um checkout endpoint calls the dispatch

424
00:18:40,160 --> 00:18:43,039
service and passes through and

425
00:18:43,039 --> 00:18:46,760
dispatches the package.

426
00:18:47,200 --> 00:18:48,880
Um,

427
00:18:48,880 --> 00:18:51,679
and yeah, as I was saying, the Biffy SSL

428
00:18:51,679 --> 00:18:54,640
context is SD lib compatible. Uh, so you

429
00:18:54,640 --> 00:18:57,760
can use it with requests, HTTPX,

430
00:18:57,760 --> 00:18:59,600
uh, and pretty much anything. So you've

431
00:18:59,600 --> 00:19:02,720
got that context done and ready to go.

432
00:19:02,720 --> 00:19:06,960
You don't have to reimplement anything

433
00:19:06,960 --> 00:19:08,883
much.

434
00:19:08,883 --> 00:19:10,559
[laughter] Um

435
00:19:10,559 --> 00:19:12,880
and then if you do want to call external

436
00:19:12,880 --> 00:19:17,440
things um you can do the jot tokens. Um

437
00:19:17,440 --> 00:19:21,520
and we use this for open telemetry data.

438
00:19:21,520 --> 00:19:24,080
Um so we wanted an open endpoint in our

439
00:19:24,080 --> 00:19:25,600
environment.

440
00:19:25,600 --> 00:19:27,760
Um but I didn't want to accept telemetry

441
00:19:27,760 --> 00:19:29,360
data from anything because we wanted to

442
00:19:29,360 --> 00:19:31,200
collect from our customer system sending

443
00:19:31,200 --> 00:19:34,559
back. Um, so we use a jot token

444
00:19:34,559 --> 00:19:36,559
generated specifically for that purpose

445
00:19:36,559 --> 00:19:38,640
that can be injected because it's really

446
00:19:38,640 --> 00:19:40,720
hard to overlay MTLS on top of open

447
00:19:40,720 --> 00:19:42,240
telemetry and it probably creates way

448
00:19:42,240 --> 00:19:44,320
too many problems. So there are use

449
00:19:44,320 --> 00:19:46,880
cases where this can really help for

450
00:19:46,880 --> 00:19:50,320
easier implementation.

451
00:19:50,320 --> 00:19:53,360
Uh, so from an authorization perspective

452
00:19:53,360 --> 00:19:55,360
um there's a bunch of different options.

453
00:19:55,360 --> 00:20:00,080
So a a specific ID. So authorized ID. Um

454
00:20:00,080 --> 00:20:03,679
one of many member of trust domain. This

455
00:20:03,679 --> 00:20:07,919
is useful in federated systems. Um, and

456
00:20:07,919 --> 00:20:11,919
then authorize any, which in reality is

457
00:20:11,919 --> 00:20:16,080
probably more what I would use, which is

458
00:20:16,080 --> 00:20:18,480
validate that it's true, and then I'll

459
00:20:18,480 --> 00:20:21,039
pass the identity through and then use

460
00:20:21,039 --> 00:20:23,039
that to do authorization in my own code

461
00:20:23,039 --> 00:20:24,480
rather than blocking them right at the

462
00:20:24,480 --> 00:20:26,799
connection point. Uh, depending on how

463
00:20:26,799 --> 00:20:29,520
many variables are involved in what's

464
00:20:29,520 --> 00:20:31,440
connecting.

465
00:20:31,440 --> 00:20:34,640
Um, now, Spiffy is used in a ton of

466
00:20:34,640 --> 00:20:37,919
different products. Um so uh as a CNCF

467
00:20:37,919 --> 00:20:40,080
project uh of course it runs on

468
00:20:40,080 --> 00:20:41,840
Kubernetes really well. Um there's Helm

469
00:20:41,840 --> 00:20:44,640
charts and tons of ways of deploying it.

470
00:20:44,640 --> 00:20:48,159
Um and lots of components of it run

471
00:20:48,159 --> 00:20:49,840
natively in Kubernetes to make it really

472
00:20:49,840 --> 00:20:53,200
easy to work there. Um if you use

473
00:20:53,200 --> 00:20:55,280
service meshes you might find your

474
00:20:55,280 --> 00:20:57,120
service mesh actually uses it for doing

475
00:20:57,120 --> 00:20:58,960
the identity of the um components

476
00:20:58,960 --> 00:21:01,919
because SDTO does. Um if you've used

477
00:21:01,919 --> 00:21:04,000
Dapper, which is another CNCF project

478
00:21:04,000 --> 00:21:05,919
for application,

479
00:21:05,919 --> 00:21:08,400
um it provides abstractions around a

480
00:21:08,400 --> 00:21:11,360
bunch of tooling. Um so like databases

481
00:21:11,360 --> 00:21:15,440
or message cues or um timelined

482
00:21:15,440 --> 00:21:18,559
executable tasks. Um so Dapper uses

483
00:21:18,559 --> 00:21:21,440
Scycard's built um on Spiffy as well and

484
00:21:21,440 --> 00:21:23,919
the teleport project um which is used

485
00:21:23,919 --> 00:21:26,240
for remote access of systems and

486
00:21:26,240 --> 00:21:29,120
databases and clusters um also uses it

487
00:21:29,120 --> 00:21:31,360
for identity. And there's a ton of

488
00:21:31,360 --> 00:21:35,919
different um libraries. Now, the reality

489
00:21:35,919 --> 00:21:37,600
is most people aren't going to want to

490
00:21:37,600 --> 00:21:39,520
write it directly into their code. So,

491
00:21:39,520 --> 00:21:40,799
one of the more common deployment

492
00:21:40,799 --> 00:21:44,240
options is to chuck an envoy sidecar in

493
00:21:44,240 --> 00:21:47,120
front of your project uh and get it to

494
00:21:47,120 --> 00:21:49,679
automatically manage

495
00:21:49,679 --> 00:21:51,919
the certificate connections and then

496
00:21:51,919 --> 00:21:53,760
just pass through in the headers the

497
00:21:53,760 --> 00:21:55,919
identity. Um, and that's sort of gives

498
00:21:55,919 --> 00:21:58,480
you an easy way in to stop you having to

499
00:21:58,480 --> 00:21:59,600
reimplement your code through

500
00:21:59,600 --> 00:22:02,080
everything. Um, but at the same time,

501
00:22:02,080 --> 00:22:04,240
it's not too tough to actually start

502
00:22:04,240 --> 00:22:06,320
building it in and doing it natively if

503
00:22:06,320 --> 00:22:09,280
if you desire.

504
00:22:09,280 --> 00:22:12,960
So, we went from in a very short time,

505
00:22:12,960 --> 00:22:16,240
uh, from you're inside the walls,

506
00:22:16,240 --> 00:22:19,120
so I trust you implicitly, that's all

507
00:22:19,120 --> 00:22:21,919
good. Um, to prove to me that you are

508
00:22:21,919 --> 00:22:24,640
who you say you are. Um, and I'll prove

509
00:22:24,640 --> 00:22:26,799
to you that I'm who I say I am. Okay, we

510
00:22:26,799 --> 00:22:28,720
agree. Now we can do some work with

511
00:22:28,720 --> 00:22:30,320
credentials that'll expire in a couple

512
00:22:30,320 --> 00:22:33,840
of minutes. Um, so

513
00:22:33,840 --> 00:22:37,840
Omen doesn't stand a chance. Um, some

514
00:22:37,840 --> 00:22:41,679
resources and links and stuff. Uh, and

515
00:22:41,679 --> 00:22:43,520
question time. I think I've still got

516
00:22:43,520 --> 00:22:47,000
about five minutes. So,

517
00:22:47,000 --> 00:22:50,520
[applause] lots of them.

518
00:22:51,585 --> 00:22:53,605
[applause]

519
00:22:55,120 --> 00:22:58,159
Are there any high-profile attacks that

520
00:22:58,159 --> 00:23:00,159
spiffy implementation wasn't implemented

521
00:23:00,159 --> 00:23:02,799
in that you know uh it would have

522
00:23:02,799 --> 00:23:05,799
prevented?

523
00:23:05,919 --> 00:23:09,039
I don't know. I'm not a cyber security

524
00:23:09,039 --> 00:23:10,559
person. Haven't been following close

525
00:23:10,559 --> 00:23:12,320
enough. But think of anything that would

526
00:23:12,320 --> 00:23:15,200
steal credentials, right? um which is

527
00:23:15,200 --> 00:23:17,120
probably a ton of attacks right now

528
00:23:17,120 --> 00:23:20,240
especially with AI.

529
00:23:20,240 --> 00:23:22,400
Good day. Thanks very much for that. Um

530
00:23:22,400 --> 00:23:25,840
I might I don't know this particular

531
00:23:25,840 --> 00:23:27,919
area well enough so I might be

532
00:23:27,919 --> 00:23:30,960
overgeneralizing but I'm wondering what

533
00:23:30,960 --> 00:23:35,679
where that this system differs from uh

534
00:23:35,679 --> 00:23:37,360
Keraros

535
00:23:37,360 --> 00:23:42,159
uh if you got a Ker Ross token for this

536
00:23:42,159 --> 00:23:44,240
service and the other service could

537
00:23:44,240 --> 00:23:47,200
authenticate it would that not be kind

538
00:23:47,200 --> 00:23:49,679
of the a similar

539
00:23:49,679 --> 00:23:53,200
you know have the similar properties.

540
00:23:53,200 --> 00:23:56,480
Uh yeah, I I think to an extent it does.

541
00:23:56,480 --> 00:24:00,240
um the the verification of how the

542
00:24:00,240 --> 00:24:03,039
identity gets issued is probably the the

543
00:24:03,039 --> 00:24:05,039
the main differences in there and the

544
00:24:05,039 --> 00:24:06,720
the fact that it integrates nicely with

545
00:24:06,720 --> 00:24:09,600
Jot tokens and X509 inserts. But the

546
00:24:09,600 --> 00:24:11,919
actual verification of the workload API

547
00:24:11,919 --> 00:24:15,279
guaranteeing that the the requesttor is

548
00:24:15,279 --> 00:24:17,440
who it says it is, which is then

549
00:24:17,440 --> 00:24:19,360
authorized from an agent running on a

550
00:24:19,360 --> 00:24:20,960
node that says who it is it. That's

551
00:24:20,960 --> 00:24:23,600
that's kind of that chain of proof is

552
00:24:23,600 --> 00:24:25,279
the is the key piece of it. As far as

553
00:24:25,279 --> 00:24:27,840
the once you have guaranteed the issue

554
00:24:27,840 --> 00:24:29,360
of the token, does it prove who you are?

555
00:24:29,360 --> 00:24:31,520
Yeah, it's it's very similar to kerros.

556
00:24:31,520 --> 00:24:33,766
I'm not a kerros expert either. So,

557
00:24:33,766 --> 00:24:35,600
[laughter] but that that would be where

558
00:24:35,600 --> 00:24:37,520
I think the differences lie. It's that

559
00:24:37,520 --> 00:24:41,559
that chain of trust effectively.

560
00:24:43,600 --> 00:24:46,080
Thank you very much. Um, so I was very

561
00:24:46,080 --> 00:24:48,159
intrigued that you said even if Omen

562
00:24:48,159 --> 00:24:50,640
pops a node and is contacting the agent

563
00:24:50,640 --> 00:24:52,720
to get its identity, it still can't

564
00:24:52,720 --> 00:24:54,960
impersonate the node because it's on the

565
00:24:54,960 --> 00:24:57,520
wrong process. So does that am I am I

566
00:24:57,520 --> 00:24:59,039
understanding that correctly?

567
00:24:59,039 --> 00:25:02,559
Uh, let me

568
00:25:02,559 --> 00:25:05,679
just cuz it's easier to talk with it

569
00:25:05,679 --> 00:25:08,880
further further. No, too far sorry.

570
00:25:08,880 --> 00:25:14,880
Yeah. So the the node attests based on

571
00:25:14,880 --> 00:25:16,799
uh whatever node addestation you have

572
00:25:16,799 --> 00:25:20,159
which is think a TPM module to go the

573
00:25:20,159 --> 00:25:21,520
most secure right it's an embedded

574
00:25:21,520 --> 00:25:23,279
search physically in the box you have

575
00:25:23,279 --> 00:25:25,760
that it has to be that uh and then the

576
00:25:25,760 --> 00:25:28,480
the workload connects to that workload

577
00:25:28,480 --> 00:25:31,440
API that runs from the agent so that's

578
00:25:31,440 --> 00:25:36,240
the attested node um and then it um

579
00:25:36,240 --> 00:25:39,760
attests based on selectors like um the

580
00:25:39,760 --> 00:25:42,720
process ID or a user ID or so if you can

581
00:25:42,720 --> 00:25:45,360
impersonate all of the selectors then

582
00:25:45,360 --> 00:25:48,400
yes you can you can steal the identity

583
00:25:48,400 --> 00:25:50,640
but that's tough to do

584
00:25:50,640 --> 00:25:52,480
so you would sort of allow list the

585
00:25:52,480 --> 00:25:54,320
certain processes that you would want

586
00:25:54,320 --> 00:25:56,880
uh yeah so in this example which is a

587
00:25:56,880 --> 00:25:58,880
Kubernetes version of it but uh where

588
00:25:58,880 --> 00:26:01,600
it's got selectors you would have slash

589
00:26:01,600 --> 00:26:06,880
selector p ID number slash selector hash

590
00:26:06,880 --> 00:26:09,919
like uh executable hash. So like a SHA

591
00:26:09,919 --> 00:26:13,760
256 or whatever of the actual binary,

592
00:26:13,760 --> 00:26:15,520
right? So that gives you a like a it is

593
00:26:15,520 --> 00:26:17,120
that binary that's calling me that

594
00:26:17,120 --> 00:26:19,039
specific one. Uh and then you'll also

595
00:26:19,039 --> 00:26:20,960
notice the parent ID which I didn't talk

596
00:26:20,960 --> 00:26:24,000
I glossed over. Uh that's the agent that

597
00:26:24,000 --> 00:26:27,120
this the selector is running on. So you

598
00:26:27,120 --> 00:26:30,400
can say only that node can ash uh sorry

599
00:26:30,400 --> 00:26:33,279
can attest these workloads with that

600
00:26:33,279 --> 00:26:34,320
identity. Yeah.

601
00:26:34,320 --> 00:26:37,559
Thank you.

602
00:26:39,039 --> 00:26:41,440
Uh hey, thanks for the uh presentation.

603
00:26:41,440 --> 00:26:44,240
Um just a question on how maintainable

604
00:26:44,240 --> 00:26:47,840
this would be compared to like MTLS. Um

605
00:26:47,840 --> 00:26:51,279
if you're got selectors that depend upon

606
00:26:51,279 --> 00:26:53,360
like hashes of things if you're

607
00:26:53,360 --> 00:26:55,600
upgrading processes and stuff like that,

608
00:26:55,600 --> 00:26:56,880
how does that look?

609
00:26:56,880 --> 00:26:58,080
Probably I wouldn't recommend the

610
00:26:58,080 --> 00:27:00,320
hashes. It would be painful. But if it's

611
00:27:00,320 --> 00:27:04,240
a non non-frequent changing sele uh a

612
00:27:04,240 --> 00:27:05,679
non-frequently changing one, you could

613
00:27:05,679 --> 00:27:09,120
do it or you could embed the um the

614
00:27:09,120 --> 00:27:12,640
version in the um ID and have multiple

615
00:27:12,640 --> 00:27:14,640
selectors for the different versions. So

616
00:27:14,640 --> 00:27:16,640
when it rolls out, you could preload

617
00:27:16,640 --> 00:27:18,640
them effectively and then when it rolls

618
00:27:18,640 --> 00:27:20,799
out, it would get the new identity and

619
00:27:20,799 --> 00:27:22,400
you can kind of play with it a little

620
00:27:22,400 --> 00:27:25,360
bit. But probably hashes is the although

621
00:27:25,360 --> 00:27:28,240
most secure, least friendly.

622
00:27:28,240 --> 00:27:30,960
Thank you.

623
00:27:31,440 --> 00:27:34,480
Uh so still on the threat model question

624
00:27:34,480 --> 00:27:40,799
um that it's mostly aimed at not not

625
00:27:40,799 --> 00:27:43,520
allowing node compromises to escalate.

626
00:27:43,520 --> 00:27:45,120
But if you've actually compromised the

627
00:27:45,120 --> 00:27:47,200
service itself, you're going to be able

628
00:27:47,200 --> 00:27:49,039
to impersonate that service still.

629
00:27:49,039 --> 00:27:52,080
Uh yeah. Yeah. If if you are effectively

630
00:27:52,080 --> 00:27:53,679
that process that the service is

631
00:27:53,679 --> 00:27:56,240
running, then yes. Yeah, you can still I

632
00:27:56,240 --> 00:27:59,919
think by then you're you're in trouble.

633
00:27:59,919 --> 00:28:02,919
Yeah.

634
00:28:03,520 --> 00:28:05,039
All right. Let's have another round of

635
00:28:05,039 --> 00:28:06,240
applause, please.

636
00:28:06,240 --> 00:28:08,664
Thank you. [applause]