Chris Binnie - Cloud Native Security

12 Chapter 18Figure 18.1: Rakkess outputFigure 18.2: Rakkess output for the certificate-controlleraccountFigure 18.3: kubectl-who-can get secretsFigure 18.4: Example of rbackoutput

13 Chapter 19Figure 19.1: Traffic flow in the base Kubernetes clusterFigure 19.2: Network traffic after default deny policies appliedFigure 19.3: Network traffic after allow-webapp-accesspolicy added

14 Chapter 20Figure 20.1: PodSecurityPolicies

1 Cover

2 Table of Contents

3 Begin Reading

1 iii

2 xix

3 xx

4 xxi

5 xxii

6 xxiii

7 xxiv

8 1

9 3

10 4

11 5

12 6

13 7

14 8

15 9

16 10

17 11

18 12

19 13

20 14

21 15

22 17

23 18

24 19

25 20

26 21

27 22

28 23

29 24

30 25

31 26

32 27

33 28

34 29

35 30

36 31

37 33

38 34

39 35

40 36

41 37

42 38

43 39

44 40

45 41

46 42

47 43

48 45

49 46

50 47

51 48

52 49

53 50

54 51

55 52

56 53

57 54

58 55

59 56

60 57

61 58

62 59

63 60

64 61

65 62

66 63

67 65

68 66

69 67

70 68

71 69

72 70

73 71

74 72

75 73

76 74

77 75

78 76

79 77

80 79

81 80

82 81

83 82

84 83

85 84

86 85

87 86

88 87

89 88

90 89

91 90

92 91

93 92

94 93

95 94

96 95

97 96

98 97

99 98

100 99

101 100

102 101

103 103

104 104

105 105

106 106

107 107

108 108

109 109

110 110

111 111

112 112

113 113

114 114

115 115

116 116

117 117

118 118

119 119

120 120

121 121

122 122

123 123

124 124

125 125

126 126

127 127

128 129

129 130

130 131

131 132

132 133

133 134

134 135

135 136

136 137

137 138

138 139

139 140

140 141

141 142

142 143

143 144

144 145

145 146

146 147

147 148

148 149

149 150

150 151

151 152

152 153

153 154

154 155

155 156

156 157

157 158

158 159

159 160

160 161

161 162

162 163

163 164

164 165

165 166

166 167

167 168

168 169

169 170

170 171

171 172

172 173

173 174

174 175

175 176

176 177

177 178

178 179

179 180

180 181

181 182

182 183

183 184

184 185

185 186

186 187

187 188

188 189

189 190

190 191

191 192

192 193

193 194

194 195

195 196

196 197

197 198

198 199

199 200

200 201

201 202

202 203

203 204

204 205

205 207

206 208

207 209

208 210

209 211

210 212

211 213

212 214

213 215

214 216

215 217

216 218

217 219

218 220

219 221

220 222

221 223

222 225

223 226

224 227

225 228

226 229

227 230

228 231

229 232

230 233

231 234

232 235

233 236

234 237

235 239

236 241

237 242

238 243

239 244

240 245

241 246

242 247

243 248

244 249

245 250

246 251

247 252

248 253

249 254

250 255

251 256

252 257

253 258

254 259

255 260

256 261

257 262

258 263

259 265

260 266

261 267

262 268

263 269

264 270

265 271

266 272

267 273

268 274

269 275

270 276

271 277

272 278

273 279

274 280

275 281

276 282

277 283

278 284

279 285

280 286

281 287

282 288

283 289

284 290

285 291

286 292

287 293

288 294

289 295

290 296

291 297

292 298

293 299

294 300

295 301

296 302

297 303

298 304

299 305

300 306

301 307

302 iv

303 v

304 vii

305 ix

306 308

Chris Binnie

Rory McCune

There is little doubt that we have witnessed a dramatic and notable change in the way that software applications are developed and deployed in recent years.

Take a moment to consider what has happened within the last decade alone. Start with the mind-blowing levels of adoption of containers, courtesy of Docker's clever packaging of Linux container technologies. Think of the pivotal maturation of cloud platforms with their ever-evolving service offerings. Remember the now-pervasive use of container orchestrators to herd multiple catlike containers. And do not forget that software applications have been teased apart and broken down into portable, microservice-sized chunks.

Combined, these significant innovations have empowered developers by offering them a whole new toolbox from which their software can be developed, and a reliable platform that their applications can be deployed upon.

In hand with the other recent milestone innovations in computing, such as the growth of Unix-like operating systems and the birth of the web and the internet as a whole, Cloud Native technologies have already achieved enough to merit a place in the history books. However, as with all newly formed tech, different types of security challenges surface and must be addressed in a timely fashion.

Cloud Native security is a complex, multifaceted topic to understand and even harder to get right. Why is that? The answer lies with the multiple, diverse components that need to be secured. The cloud platform, the underlying host operating system, the container runtime, the container orchestrator, and then the applications themselves each require specialist security attention.

Bear in mind too, that the securing and then monitoring of the critical nuts and bolts of a tech stack needs to happen 24 hours a day, all year round. For those who are working in security and unaccustomed to Cloud Native technologies, their limited breadth of exposure can make the challenge that they are suddenly faced with a real eye-opener.

Among the more advanced attackers, there are many highly adaptive, intelligent, and ultimately extremely patient individuals with a vast amount of development and systems experience who have the ability to pull off exceptional compromises, including those of the highest-profile online services. These individuals, who may also be well-funded, are extremely difficult to keep out of a cloud estate. Only by continually plugging every security hole, with multiple layers of defense, is it possible to hope to do so. They are the attackers, however, that can usually be kept at arm's length. At the highest level, so-called nation-state attackers are advanced enough that many security teams would struggle to even identify if a compromise had been successful.