├── 2022 └── en │ └── src │ ├── K01-insecure-workload-configurations.md │ ├── K02-supply-chain-vulnerabilities.md │ ├── K03-overly-permissive-rbac.md │ ├── K04-policy-enforcement.md │ ├── K05-inadequate-logging.md │ ├── K06-broken-authentication.md │ ├── K07-network-segmentation.md │ ├── K08-secrets-management.md │ ├── K09-misconfigured-cluster-components.md │ ├── K10-vulnerable-components.md │ ├── index.md │ ├── info.md │ ├── leaders.md │ └── other-risks.md ├── .github ├── CODEOWNERS ├── FUNDING.yml └── workflows │ ├── md-broken-link-check.yml │ └── md-lint-check.yml ├── .gitignore ├── .markdownlint.json ├── .textlintrc ├── 404.html ├── CODE_OF_CONDUCT.md ├── Gemfile ├── LICENSE ├── README.md ├── _config.yml ├── assets └── images │ ├── K01-2022-mitigation.gif │ ├── K01-2022.gif │ ├── K02-2022-mitigation.gif │ ├── K02-2022.gif │ ├── K03-2022-mitigation.gif │ ├── K03-2022.gif │ ├── K04-2022-mitigation.gif │ ├── K04-2022.gif │ ├── K05-2022-mitigation.gif │ ├── K05-2022.gif │ ├── K06-2022-mitigation.gif │ ├── K06-2022.gif │ ├── K07-2022-mitigation.gif │ ├── K07-2022.gif │ ├── K08-2022-mitigation.gif │ ├── K08-2022.gif │ ├── K09-2022-mitigation.gif │ ├── K09-2022.gif │ ├── K10-2022-mitigation.gif │ ├── K10-2022.gif │ ├── README.md │ └── kubernetes-auth.png ├── index.md ├── info.md ├── leaders.md ├── markdown-link-check-config.json ├── package.json └── tab_example.md /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # See https://help.github.com/en/articles/about-code-owners 2 | 3 | # These owners will be the default owners for everything in the repo. 4 | * @jmbmxer 5 | -------------------------------------------------------------------------------- /.github/FUNDING.yml: -------------------------------------------------------------------------------- 1 | custom: https://owasp.org/donate/?reponame=www-project-kubernetes-top-ten&title=OWASP+Kubernetes+Top+Ten 2 | github: OWASP 3 | -------------------------------------------------------------------------------- /.github/workflows/md-broken-link-check.yml: -------------------------------------------------------------------------------- 1 | # Credit to https://github.com/OWASP/CheatSheetSeries 2 | # TODO: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ 3 | name: Markdown Broken Link Check 4 | 5 | on: 6 | # Disabling auto running this workflow for now as it's not working as expected. 7 | # Ideally we should come back and fix this at some point. 8 | workflow_dispatch 9 | # push: 10 | # branches: 11 | # - main 12 | # pull_request: 13 | # branches: 14 | # - main 15 | 16 | jobs: 17 | link-check: 18 | runs-on: ubuntu-22.04 19 | env: 20 | CI: true 21 | steps: 22 | - name: Setup Action 23 | uses: actions/checkout@v3 24 | - name: Setup Node 25 | uses: actions/setup-node@v3 26 | with: 27 | node-version: 18.x 28 | - name: Install dependencies 29 | run: npm install 30 | - name: Run link check 31 | run: npm run link-check 32 | - name: Show broken links 33 | if: failure() 34 | run: | 35 | cat log | awk -v RS="FILE:" 'match($0, /(\S*\.md).*\[✖\].*(\d*\slinks\schecked\.)(.*)/, arr ) { print "FILE:"arr[1] arr[3] > "brokenlinks"}' 36 | rm -f err log 37 | cat brokenlinks 38 | links=`cat brokenlinks` 39 | links="${links//'%'/'%25'}" 40 | links="${links//$'\n'/'%0A'}" 41 | links="${links//$'\r'/'%0D'}" 42 | echo ::set-output name=links::**Following links are broken:** %0A$links 43 | - name: Send comment to PR with broken links 44 | if: failure() && github.event_name == 'pull_request' 45 | uses: thollander/actions-comment-pull-request@main 46 | with: 47 | message: ${{ steps.brokenlinks.outputs.links }} 48 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 49 | -------------------------------------------------------------------------------- /.github/workflows/md-lint-check.yml: -------------------------------------------------------------------------------- 1 | # Credit to https://github.com/OWASP/CheatSheetSeries 2 | 3 | name: Markdown Lint Check 4 | 5 | on: 6 | push: 7 | branches: 8 | - main 9 | pull_request: 10 | branches: 11 | - main 12 | 13 | jobs: 14 | lint: 15 | runs-on: ubuntu-22.04 16 | env: 17 | CI: true 18 | steps: 19 | - name: Setup Action 20 | uses: actions/checkout@v3 21 | - name: Setup Node 22 | uses: actions/setup-node@v3 23 | with: 24 | node-version: 18.x 25 | - name: Install dependencies 26 | run: npm install 27 | - name: Run linter 28 | run: npm test 29 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | /Gemfile 2 | /Gemfile.lock 3 | /favicon.ico 4 | _site/ 5 | node_modules/ 6 | package-lock.json 7 | /log 8 | /err 9 | -------------------------------------------------------------------------------- /.markdownlint.json: -------------------------------------------------------------------------------- 1 | { 2 | "default": true, 3 | "MD004": { "style": "dash"}, 4 | "MD007": {"indent": 4}, 5 | "MD013": { 6 | "line_length": 80, 7 | "code_block_line_length": 180 8 | }, 9 | "MD024": { "siblings_only": true}, 10 | "MD029": false 11 | } -------------------------------------------------------------------------------- /.textlintrc: -------------------------------------------------------------------------------- 1 | // Credit to https://github.com/OWASP/CheatSheetSeries 2 | 3 | { 4 | "filters": { 5 | "comments": true, 6 | "allowlist": { 7 | "allow": [ 8 | "XSL stylesheet", 9 | "OS X 10.9", 10 | "Argon2**id**", 11 | "Network IDS" 12 | ] 13 | } 14 | }, 15 | "rules": { 16 | "terminology": { 17 | // Load default terms (see terms.json in the repository) 18 | "defaultTerms": false, 19 | // Syntax elements to skip. Overrides the default 20 | "skip": [ 21 | "Link", 22 | "Blockquote" 23 | ], 24 | // List of terms 25 | "terms": [ 26 | // Brands 27 | "Airbnb", 28 | "Android", 29 | "AppleScript", 30 | "AppVeyor", 31 | "AVA", 32 | "BrowserStack", 33 | "Browsersync", 34 | "Codecov", 35 | "CodePen", 36 | "CodeSandbox", 37 | "DefinitelyTyped", 38 | "EditorConfig", 39 | "ESLint", 40 | "GitHub", 41 | "GraphQL", 42 | "GraphiQL", 43 | "iOS", 44 | "JavaScript", 45 | "JetBrains", 46 | "jQuery", 47 | "LinkedIn", 48 | "Lodash", 49 | "MacBook", 50 | "Markdown", 51 | "OpenType", 52 | "PayPal", 53 | "PhpStorm", 54 | "RubyMine", 55 | "SemVer", 56 | "TypeScript", 57 | "UglifyJS", 58 | "Wasm", 59 | "WebAssembly", 60 | "WebStorm", 61 | "WordPress", 62 | "YouTube", 63 | [ 64 | "StackOverflow", 65 | "Stack Overflow" 66 | ], 67 | [ 68 | "styled ?components", 69 | "styled-components" 70 | ], 71 | [ 72 | "HTTP[ /]2(?:\\.0)?", 73 | "HTTP/2" 74 | ], 75 | [ 76 | "OS X", 77 | "macOS" 78 | ], 79 | [ 80 | "Mac ?OS", 81 | "macOS" 82 | ], 83 | [ 84 | "a npm", 85 | "an npm" 86 | ], 87 | 88 | // Abbreviations 89 | "3D", 90 | [ 91 | "3-D", 92 | "3D" 93 | ], 94 | "AJAX", 95 | "API", 96 | [ 97 | "API['’]?s", 98 | "APIs" 99 | ], 100 | "CSS", 101 | "GIF", 102 | "HTML", 103 | "HTTPS", 104 | "IoT", 105 | "I/O", 106 | [ 107 | "I-O", 108 | "I/O" 109 | ], 110 | "JPEG", 111 | "MIME", 112 | "OK", 113 | "PaaS", 114 | "PDF", 115 | "PNG", 116 | "SaaS", 117 | "URL", 118 | [ 119 | "URL['’]?s", 120 | "URLs" 121 | ], 122 | [ 123 | "an URL", 124 | "a URL" 125 | ], 126 | [ 127 | "wi[- ]?fi", 128 | "Wi-Fi" 129 | ], 130 | [ 131 | "CVE['’]?s", 132 | "CVEs" 133 | ], 134 | 135 | // Words and phrases 136 | "ID", 137 | "JavaScript", 138 | // http://stackoverflow.com/questions/1151338/id-or-id-on-user-interface 139 | [ 140 | "id['’]?s", 141 | "IDs" 142 | ], 143 | [ 144 | "backwards compatible", 145 | "backward compatible" 146 | ], 147 | [ 148 | "build system(s)?", 149 | "build tool$1" 150 | ], 151 | [ 152 | "CLI tool(s)?", 153 | "command-line tool$1" 154 | ], 155 | [ 156 | "he or she", 157 | "they" 158 | ], 159 | [ 160 | "he/she", 161 | "they" 162 | ], 163 | [ 164 | "\\(s\\)he", 165 | "they" 166 | ], 167 | [ 168 | "his/her", 169 | "their" 170 | ], 171 | [ 172 | "his or her", 173 | "their" 174 | ], 175 | [ 176 | "repo\\b", 177 | "repository" 178 | ], 179 | // https://stackoverflow.com/questions/44934828/is-it-spread-syntax-or-the-spread-operator 180 | [ 181 | "spread operator", 182 | "spread syntax" 183 | ], 184 | [ 185 | "re-direct", 186 | "redirect" 187 | ], 188 | 189 | // Single word 190 | [ 191 | "auto[- ]complete", 192 | "autocomplete" 193 | ], 194 | [ 195 | "auto[- ]format", 196 | "autoformat" 197 | ], 198 | [ 199 | "auto[- ]fix", 200 | "autofix" 201 | ], 202 | [ 203 | "auto[- ]fixing", 204 | "autofixing" 205 | ], 206 | [ 207 | "bug[- ]fix(es)?", 208 | "bugfix$1" 209 | ], 210 | [ 211 | "change[- ]log(s)?", 212 | "changelog$1" 213 | ], 214 | [ 215 | "check[- ]box(es)?", 216 | "checkbox$1" 217 | ], 218 | [ 219 | "code[- ]base(es)?", 220 | "codebase$1" 221 | ], 222 | [ 223 | "co[- ]locate(d?)", 224 | "colocate$1" 225 | ], 226 | [ 227 | "end[- ]point(s)?", 228 | "endpoint$1" 229 | ], 230 | [ 231 | "e[- ]mail(s)?", 232 | "email$1" 233 | ], 234 | [ 235 | "file[- ]name(s)?", 236 | "filename$1" 237 | ], 238 | [ 239 | "hack[- ]a[- ]thon(s)?", 240 | "hackathon$1" 241 | ], 242 | [ 243 | "host[- ]name(s)?", 244 | "hostname$1" 245 | ], 246 | [ 247 | "hot[- ]key(s)?", 248 | "hotkey$1" 249 | ], 250 | [ 251 | "lock[- ]file(s)?", 252 | "lockfile$1" 253 | ], 254 | [ 255 | "mark-up", 256 | "markup" 257 | ], 258 | // “mark up” as a verb is OK 259 | [ 260 | "meta[- ]data", 261 | "metadata" 262 | ], 263 | [ 264 | "micro[- ]service(s)?", 265 | "microservice$1" 266 | ], 267 | [ 268 | "name[- ]space(s)?", 269 | "namespace$1" 270 | ], 271 | [ 272 | "pre[- ]condition(s)?", 273 | "precondition$1" 274 | ], 275 | [ 276 | "pre[- ]defined", 277 | "predefined" 278 | ], 279 | [ 280 | "pre[- ]release(s)?", 281 | "prerelease$1" 282 | ], 283 | [ 284 | "re[- ]write", 285 | "rewrite" 286 | ], 287 | [ 288 | "run[- ]time", 289 | "runtime" 290 | ], 291 | [ 292 | "screen[- ]shot(s)?", 293 | "screenshot$1" 294 | ], 295 | [ 296 | "screen[- ]?snap(s)?", 297 | "screenshot$1" 298 | ], 299 | [ 300 | "sub[- ]class((?:es|ing)?)", 301 | "subclass$1" 302 | ], 303 | [ 304 | "sub[- ]tree(s)?", 305 | "subtree$1" 306 | ], 307 | [ 308 | "time[- ]stamp(s)?", 309 | "timestamp$1" 310 | ], 311 | [ 312 | "touch[- ]screen(s)?", 313 | "touchscreen$1" 314 | ], 315 | [ 316 | "user[- ]name(s)?", 317 | "username$1" 318 | ], 319 | [ 320 | "walk[- ]through", 321 | "walkthrough" 322 | ], 323 | [ 324 | "white[- ]space", 325 | "whitespace" 326 | ], 327 | [ 328 | "wild[- ]card(s)?", 329 | "wildcard$1" 330 | ], 331 | 332 | // Multiple words 333 | [ 334 | "css-?in-?js", 335 | "CSS in JS" 336 | ], 337 | [ 338 | "code-?review(s)?", 339 | "code review$1" 340 | ], 341 | [ 342 | "code-?splitting", 343 | "code splitting" 344 | ], 345 | [ 346 | "end-?user(s)?", 347 | "end user$1" 348 | ], 349 | [ 350 | "file-?type(s)?", 351 | "file type$1" 352 | ], 353 | [ 354 | "style-?guide(s)?", 355 | "style guide$1" 356 | ], 357 | [ 358 | "source-?map(s)?", 359 | "source map$1" 360 | ], 361 | [ 362 | "style-?sheet(s)?", 363 | "style sheet$1" 364 | ], 365 | [ 366 | "user-?base", 367 | "user base" 368 | ], 369 | [ 370 | "web-page(s)?", 371 | "webpage$1" 372 | ], 373 | 374 | // Hyphenated 375 | [ 376 | "built ?in", 377 | "built-in" 378 | ], 379 | [ 380 | "command ?line", 381 | "command-line" 382 | ], 383 | [ 384 | "end ?to ?end", 385 | "end-to-end" 386 | ], 387 | [ 388 | "end[- ]?2[- ]?end", 389 | "end-to-end" 390 | ], 391 | [ 392 | "error ?prone", 393 | "error-prone" 394 | ], 395 | [ 396 | "higher ?order", 397 | "higher-order" 398 | ], 399 | [ 400 | "key[/ ]?value", 401 | "key-value" 402 | ], 403 | [ 404 | "two ?steps? authentication", 405 | "two-step authentication" 406 | ], 407 | [ 408 | "two ?steps? verification", 409 | "two-step verification" 410 | ], 411 | [ 412 | "2 ?steps? authentication", 413 | "two-step authentication" 414 | ], 415 | [ 416 | "2 ?steps? verification", 417 | "two-step verification" 418 | ], 419 | [ 420 | "3rd[- ]party", 421 | "third-party" 422 | ], 423 | 424 | // Starts from a lower case letter in the middle of a sentence 425 | [ 426 | "(?<=(?:\\w+[^.?!])? )stylelint\\b", 427 | "stylelint" 428 | ], 429 | [ 430 | "(?<=(?:\\w+[^.?!])? )webpack\\b", 431 | "webpack" 432 | ], 433 | [ 434 | "(?<=(?:\\w+[^.?!])? )npm\\b", 435 | "npm" 436 | ], 437 | 438 | // Typos 439 | [ 440 | "accidentially", 441 | "accidentally" 442 | ], 443 | [ 444 | "busineess", 445 | "business" 446 | ], 447 | [ 448 | "busines", 449 | "business" 450 | ], 451 | [ 452 | "analysed", 453 | "analyzed" 454 | ], 455 | [ 456 | "cancelling", 457 | "canceling" 458 | ], 459 | [ 460 | "environemnt(s)?", 461 | "environment$1" 462 | ], 463 | [ 464 | "explotation", 465 | "exploitation" 466 | ], 467 | [ 468 | "encyprtion", 469 | "encryption" 470 | ], 471 | [ 472 | "flacky test(s)?", 473 | "flaky test$1" 474 | ], 475 | [ 476 | "falsey", 477 | "falsy" 478 | ], 479 | [ 480 | "hsot", 481 | "host" 482 | ], 483 | [ 484 | "intiated", 485 | "initiated" 486 | ], 487 | [ 488 | "localised", 489 | "localized" 490 | ], 491 | [ 492 | "pacakge(s)?", 493 | "package$1" 494 | ], 495 | [ 496 | "perfomed", 497 | "performed" 498 | ], 499 | [ 500 | "refernece(s)?", 501 | "reference$1" 502 | ], 503 | [ 504 | "renegotiaion(s)?", 505 | "renegotiation$1" 506 | ], 507 | [ 508 | "traget", 509 | "target" 510 | ], 511 | [ 512 | "tagret", 513 | "target" 514 | ], 515 | [ 516 | "tilda", 517 | "tilde" 518 | ], 519 | [ 520 | "teh", 521 | "the" 522 | ], 523 | [ 524 | "transfered", 525 | "transferred" 526 | ], 527 | [ 528 | "unlkely", 529 | "unlikely" 530 | ], 531 | [ 532 | "utilising", 533 | "utilizing" 534 | ] 535 | ] 536 | } 537 | } 538 | } -------------------------------------------------------------------------------- /2022/en/src/K01-insecure-workload-configurations.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: "K01: Insecure Workload Configurations" 5 | --- 6 | 7 | ## Overview 8 | 9 | The security context of a workload in Kubernetes is highly configurable which 10 | can lead to serious security misconfigurations propagating across an 11 | organization’s workloads and clusters. The [Kubernetes adoption, security, and 12 | market trends report 13 | 2022](https://www.redhat.com/en/resources/kubernetes-adoption-security-market-trends-overview) 14 | from Redhat stated that nearly 53% of respondents have experienced a 15 | misconfiguration incident in their Kubernetes environments in the last 12 16 | months. 17 | 18 | ![Insecure Workload Configuration - 19 | Illustration](../../../assets/images/K01-2022.gif) 20 | 21 | ## Description 22 | 23 | Kubernetes manifests contain many different configurations that can affect the 24 | reliability, security, and scalability of a given workload. These configurations 25 | should be audited and remediated continuously. Some examples of high-impact 26 | manifest configurations are below: 27 | 28 | **Application processes should not run as root:** Running the process inside of 29 | a container as the `root` user is a common misconfiguration in many clusters. 30 | While `root` may be an absolute requirement for some workloads, it should be 31 | avoided when possible. If the container were to be compromised, the attacker 32 | would have root-level privileges that allow actions such as starting a malicious 33 | process that otherwise wouldn’t be permitted with other users on the system. 34 | 35 | ```yaml 36 | apiVersion: v1 37 | kind: Pod 38 | metadata: 39 | name: root-user 40 | spec: 41 | containers: 42 | ... 43 | securityContext: 44 | #root user: 45 | runAsUser: 0 46 | #non-root user: 47 | runAsUser: 5554 48 | ``` 49 | 50 | **Read-only filesystems should be used:** In order to limit the impact of a 51 | compromised container on a Kubernetes node, it is recommended to utilize 52 | read-only filesystems when possible. This prevents a malicious process or 53 | application from writing back to the host system. Read-only filesystems are a 54 | key component to preventing container breakout. 55 | 56 | ```yaml 57 | apiVersion: v1 58 | kind: Pod 59 | metadata: 60 | name: read-only-fs 61 | spec: 62 | containers: 63 | ... 64 | securityContext: 65 | #read-only fs explicitly defined 66 | readOnlyRootFilesystem: true 67 | ``` 68 | 69 | **Privileged containers should be disallowed**: When setting a container to 70 | `privileged` within Kubernetes, the container can access additional resources 71 | and kernel capabilities of the host. Workloads running as root combined with 72 | privileged containers can be devastating as the user can get complete access to 73 | the host. This is, however, limited when running as a non-root user. Privileged 74 | containers are dangerous as they remove many of the built-in container isolation 75 | mechanisms entirely. 76 | 77 | ```yaml 78 | apiVersion: v1 79 | kind: Pod 80 | metadata: 81 | name: privileged-pod 82 | spec: 83 | containers: 84 | ... 85 | securityContext: 86 | #priviliged 87 | privileged: true 88 | #non-privileged 89 | privileged: false 90 | ``` 91 | 92 | **Resource constraints should be enforced**: By default, containers run with 93 | unbounded compute resources on a Kubernetes cluster. CPU requests and limits 94 | can be attributed to individual containers within a pod. If you don't specify 95 | a CPU limit for a container, it means there's no upper bound on the CPU 96 | resources it can consume. While this flexibility can be advantageous, it also 97 | poses a risk for potential resource abuse, such as crypto-mining, as the 98 | container could potentially utilize all available CPU resources on the 99 | hosting node. 100 | 101 | ```yaml 102 | apiVersion: v1 103 | kind: Pod 104 | metadata: 105 | name: resource-limit-pod 106 | spec: 107 | containers: 108 | ... 109 | resources: 110 | limits: 111 | cpu: "0.5" # 0.5 CPU cores 112 | memory: "512Mi" # 512 Megabytes of memory 113 | requests: 114 | cpu: "0.2" # 0.2 CPU cores 115 | memory: "256Mi" # 256 Megabytes of memory 116 | ``` 117 | 118 | ## How to Prevent 119 | 120 | Maintaining secure configurations throughout a large, distributed Kubernetes 121 | environment can be a difficult task. While many security configurations are 122 | often set in the `securityContext` of the manifest itself there are a number of 123 | other misconfigurations that can be detected elsewhere. In order to prevent 124 | misconfigurations, they must first be detected in both runtime and in code. We 125 | can enforce that applications: 126 | 127 | 1. Run as non-root user 128 | 2. Run as non-privileged mode 129 | 3. Set AllowPrivilegeEscalation: False to disallow child process from 130 | getting more privileges than its parents. 131 | 4. Set a LimitRange to constrain the resource allocations for each applicable 132 | object kind in a namespace. 133 | 134 | Tools such as Open Policy Agent can be used as a policy engine to detect these 135 | common misconfigurations. The CIS Benchmark for Kubernetes can also be used as a 136 | starting point for discovering misconfigurations. 137 | 138 | ![Insecure Workload Configuration - 139 | Mitigations](../../../assets/images/K01-2022-mitigation.gif) 140 | 141 | ## Example Attack Scenarios 142 | 143 | TODO 144 | 145 | ## References 146 | 147 | CIS Benchmarks for Kubernetes: 148 | [https://www.cisecurity.org/benchmark/kubernetes](https://www.cisecurity.org/benchmark/kubernetes) 149 | 150 | Open Policy Agent: 151 | [https://github.com/open-policy-agent/opa](https://github.com/open-policy-agent/opa) 152 | 153 | Pod Security Standards: 154 | [https://kubernetes.io/docs/concepts/security/pod-security-standards/](https://kubernetes.io/docs/concepts/security/pod-security-standards/) 155 | -------------------------------------------------------------------------------- /2022/en/src/K02-supply-chain-vulnerabilities.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: "K02: Supply Chain Vulnerabilities" 5 | --- 6 | 7 | ## Overview 8 | 9 | Containers take on many forms at different phases of the development lifecycle 10 | supply chain; each of them presenting unique security challenges. A single 11 | container alone can rely on hundreds of third-party components and dependencies 12 | making trust of origin at each phase extremely difficult. These challenges 13 | include but are not limited to image integrity, image composition, and known 14 | software vulnerabilities. 15 | 16 | ![Supply Chain Vulnerabilities - 17 | Illustration](../../../assets/images/K02-2022.gif) 18 | 19 | ## Description 20 | 21 | **Image Integrity:** Software provenance has recently attracted significant 22 | attention in the media due to events such as the [Solarwinds 23 | breach](https://www.businessinsider.com/solarwinds-hack-explained-government-agencies-cyber-security-2020-12) 24 | and a variety of [tainted third-party 25 | packages](https://therecord.media/malware-found-in-npm-package-with-millions-of-weekly-downloads/). 26 | These supply chain risks can surface in various states of the container build 27 | cycle as well as at runtime inside of Kubernetes. When systems of record do not 28 | exist regarding the contents of a container image it is possible that an 29 | unexpected container may run in a cluster. 30 | 31 | **Image Composition:** A container image consists of layers, each of which can 32 | present security implications. A properly constructed container image not only 33 | reduces attack surface, but can also increase deployment efficiency. Images with 34 | extraneous software can be leveraged to elevate privileges or exploit known 35 | vulnerabilities. 36 | 37 | **Known Software Vulnerabilities**: Due to their extensive use of third-party 38 | packages, many container images are inherently dangerous to pull into a trusted 39 | environment and run. For example, if a given layer in an image contains a 40 | version of OpenSSL that is susceptible to a known exploit it may be propagated 41 | to several workloads and unknowingly put an entire cluster at risk. 42 | 43 | ## How to Prevent 44 | 45 | **Image Integrity:** Container images can be thought of as a series of software 46 | artifacts and metadata passed from a producer to a consumer. The handoff can be 47 | as simple as a developer’s IDE directly to a Kubernetes cluster or as complex as 48 | a multi-step dedicated CI/CD workflow. The integrity of the software should be 49 | validated through each phase using [in-toto](https://in-toto.io/) 50 | [attestations](https://github.com/in-toto/attestation). This also increases the 51 | [SLSA](https://slsa.dev) level of the build pipeline, with a higher SLSA level 52 | indicating a more resilient build pipeline. 53 | 54 | **Software Bill of Materials (SBOM)**: An SBOM provides a list of software 55 | packages, licenses, and libraries a given software artifact contains and should 56 | be used as a starting point for other security checks. Two of the most popular 57 | open standards for SBOM generation include [CycloneDX](https://cyclonedx.org/) 58 | and [SPDX](https://spdx.dev/). 59 | 60 | **Image Signing**: Each of the steps throughout a DevOps workflow can introduce 61 | attacks or unexpected consequences. Producers and consumers use cryptographic 62 | key-pairs to sign and verify the artifact at each step of the supply chain to 63 | detect tampering with the artifacts themselves. The open-source 64 | [Cosign](https://github.com/sigstore/cosign) project is an open source project 65 | aimed at verifying container images. 66 | 67 | **Image Composition:** Container images should be created using minimal OS 68 | packages and dependencies to reduce the attack surface if the workload should be 69 | compromised. Consider utilizing alternative base images such as 70 | [Distroless](https://github.com/GoogleContainerTools/distroless) or 71 | [Scratch](https://hub.docker.com/_/scratch) to not only improve security posture 72 | but also drastically reduce the noise generated by vulnerability scanners. Using 73 | distroless images also reduces the image size which ultimately helps in faster 74 | CI/CD build. It is also important to ensure your base images are up-to-date 75 | with the latest security patches. Tools such as [Docker 76 | Slim](https://github.com/docker-slim/docker-slim) are available to optimize your 77 | image footprint for performance and security reasons. 78 | 79 | **Known Software Vulnerabilities:** Image vulnerability scanning aims to 80 | enumerate known security issues in container images and should be used as a 81 | first line of defense. ****You can identify all upstream software with 82 | vulnerabilities simply by looking for images built with a specific layer. Images 83 | should be patched quickly by simply replacing the layer containing the 84 | vulnerability and rebuilding the container to use up-to-date, fixed packages. 85 | Open source tools such as [Clair](https://github.com/coreos/clair) and 86 | [trivy](https://github.com/aquasecurity/trivy) will statically analyze container 87 | images for known vulnerabilities such as CVEs and should be used as early in the 88 | development cycle as reasonably possible. 89 | 90 | **Enforcing Policy:** Prevent unapproved images from being used with the 91 | Kubernetes [admission 92 | controls](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) 93 | and policy engines such as [Open Policy Agent](https://www.openpolicyagent.org/) 94 | and [Kyverno](https://kyverno.io) to reject workloads images which: 95 | 96 | - haven’t been scanned for vulnerabilities 97 | - use a base image that’s not explicitly allowed 98 | - don’t include an approved SBOM 99 | - originated from untrusted registries 100 | 101 | ![Supply Chain Vulnerabilities - 102 | Mitigations](../../../assets/images/K02-2022-mitigation.gif) 103 | 104 | ## Example Attack Scenarios 105 | 106 | Example #1: Compromised CI/CD Pipeline 107 | 108 | Most teams use some form of automation to build and push container images to a 109 | central registry. The image is then pulled from Kubernetes as defined in the 110 | object manifest. If that build tool were to be compromised and a malicious 111 | package was injected as part of the build Kubernetes would pull the image into 112 | the cluster and run it. Malware may be executed, cryptocurrency miners may be 113 | installed, or a backdoor planted. 114 | 115 | ## References 116 | 117 | Admission Controllers: 118 | [https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) 119 | 120 | Co-Sign: 121 | [https://github.com/sigstore/cosign](https://github.com/sigstore/cosign) 122 | 123 | CycloneDX: 124 | [https://owasp.org/www-project-cyclonedx/](https://owasp.org/www-project-cyclonedx/) 125 | 126 | Docker Slim: 127 | [https://github.com/docker-slim/docker-slim](https://github.com/docker-slim/docker-slim) 128 | 129 | Open Policy Agent: 130 | [https://www.openpolicyagent.org/](https://www.openpolicyagent.org/) 131 | 132 | in-toto: [https://in-toto.io](https://in-toto.io) 133 | 134 | SLSA: [https://slsa.dev](https://slsa.dev) 135 | -------------------------------------------------------------------------------- /2022/en/src/K03-overly-permissive-rbac.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: "K03: Overly Permissive RBAC" 5 | --- 6 | 7 | ## Overview 8 | 9 | [Role-Based Access 10 | Control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) 11 | is the primary authorization mechanism in Kubernetes and is responsible for 12 | permissions over resources. These permissions combine verbs (get, create, 13 | delete, etc.) with resources (pods, services, nodes, etc.) and can be namespace 14 | or cluster scoped. A set of out of the box roles are provided that offer 15 | reasonable default separation of responsibility depending on what actions a 16 | client might want to perform. Configuring RBAC with least privilege enforcement 17 | is a challenge for reasons we will explore below. 18 | 19 | ![Overly Permissive RBAC - Illustration](../../../assets/images/K03-2022.gif) 20 | 21 | ## Description 22 | 23 | RBAC is an extremely powerful security enforcement mechanism in Kubernetes when 24 | appropriately configured but can quickly become a massive risk to the cluster 25 | and increase the blast radius in the event of a compromise. Below are a few 26 | examples of misconfigured RBAC: 27 | 28 | ## Unnecessary use of `cluster-admin` 29 | 30 | When a subject such as a Service Account, User, or Group has access to the 31 | built-in Kubernetes “superuser” called `cluster-admin` they are able to perform 32 | any action on any resource within a cluster. This level of permission is 33 | especially dangerous when used in a `ClusterRoleBinding` which grants full 34 | control over every resource across the entire cluster. `cluster-admin` can also 35 | be used as a `RoleBinding` which may also pose significant risk. 36 | 37 | Below you will find the RBAC configuration of a popular OSS Kubernetes 38 | development platform. It showcases a very dangerous `ClusterRoleBinding` which 39 | is bound to the `default` service account. Why is this dangerous? It grants the 40 | all-powerful `cluster-admin` privilege to every single Pod in the `default` 41 | namespace. If a pod in the default namespace is compromised (think, Remote Code 42 | Execution) then it is trivial for the attacker to compromise the entire cluster 43 | by impersonating the service 44 | 45 | ```yaml 46 | apiVersion: rbac.authorization.k8s.io/v1 47 | kind: ClusterRoleBinding 48 | metadata: 49 | name: redacted-rbac 50 | subjects: 51 | - kind: ServiceAccount 52 | name: default 53 | namespace: default 54 | roleRef: 55 | kind: ClusterRole 56 | name: cluster-admin 57 | apiGroup: rbac.authorization.k8s.io 58 | ``` 59 | 60 | ### How to Prevent 61 | 62 | To reduce the risk of an attacker abusing RBAC configurations, it is important 63 | to analyze your configurations continuously and ensure the principle of least 64 | privilege is always enforced. Some recommendations are below: 65 | 66 | - Reduce direct cluster access by end users when possible 67 | - Don’t use Service Account Tokens outside of the cluster 68 | - Avoid automatically mounting the default service account token 69 | - Audit RBAC included with installed third-party components 70 | - Deploy centralized polices to detect and block risky RBAC permissions 71 | - Utilize `RoleBindings` to limit scope of permissions to particular namespaces 72 | vs. cluster-wide RBAC policies 73 | - Follow the official [RBAC Good 74 | Practices](https://kubernetes.io/docs/concepts/security/rbac-good-practices/) 75 | in the Kubernetes docs 76 | 77 | ### Example Attack Scenarios 78 | 79 | An OSS cluster observability tool is installed inside of a private Kubernetes 80 | cluster by the platform engineering team. This tool has an included web UI for 81 | debugging and analyzing traffic. The UI is accidentally exposed to the internet 82 | through it’s included Service manifest - it uses type: LoadBalancer which spins 83 | up an AWS ALB load balancer with a **public** IP address. 84 | 85 | This hypothetical tool uses the following RBAC configuration: 86 | 87 | ```yaml 88 | apiVersion: rbac.authorization.k8s.io/v1 89 | kind: RoleBinding 90 | metadata: 91 | name: default-sa-namespace-admin 92 | namespace: prd 93 | roleRef: 94 | apiGroup: rbac.authorization.k8s.io 95 | kind: ClusterRole 96 | name: admin 97 | subjects: 98 | - apiGroup: rbac.authorization.k8s.io 99 | kind: User 100 | name: system:serviceaccount:prd:default 101 | ``` 102 | 103 | An attacker finds the open web UI and is able to get a shell on the running 104 | container in the cluster. The default service account token in the `prd` 105 | namespace is used by the web UI and the attacker is able to impersonate it to 106 | call the Kubernetes API and perform elevated actions such as `describe secrets` 107 | in the `kube-system` namespace. This is due to the `roleRef` which gives that 108 | service account the built-in privilege `admin` in the entire cluster. 109 | 110 | ### References 111 | 112 | Kubernetes RBAC: 113 | 114 | RBAC Police Scanner: 115 | 116 | Kubernetes RBAC Good Practices: 117 | 118 | 119 | ## Unnecessary use of `LIST` permission 120 | 121 | The list response contains all items in full, not just their name. Accounts with 122 | `LIST` permission cannot get a specific item from the API, but will get all of 123 | them in full when they list. 124 | 125 | kubectl hides this by default by choosing to only show you the object names, but 126 | it has all attributes of those objects. 127 | 128 | ### How to Prevent 129 | 130 | Only grant `LIST` permission if you are also allowing that account to `GET` all 131 | of that resource 132 | 133 | ### Example Attack Scenario 134 | 135 | ```bash 136 | 137 | # Create example A, which can only list secrets in the default namespace 138 | # It does not have the GET permission 139 | kubectl create serviceaccount only-list-secrets-sa 140 | kubectl create role only-list-secrets-role --verb=list --resource=secrets 141 | kubectl create rolebinding only-list-secrets-default-ns \ 142 | --role=only-list-secrets-role --serviceaccount=default:only-list-secrets-sa 143 | # Now to impersonate that service account 144 | kubectl proxy & 145 | # Create a secret to get 146 | kubectl create secret generic abc --from-literal=secretAuthToken=verySecure123 147 | # Prove we cannot get that secret 148 | curl http://127.0.0.1:8001/api/v1/namespaces/default/secrets/abc \ 149 | -H "Authorization: Bearer $(kubectl -n default get secrets -ojson | jq '.items[]| select(.metadata.annotations."kubernetes.io/service-account.name"=="only-list-secrets-sa")| \ 150 | .data.token' | tr -d '"' | base64 -d)" 151 | { 152 | "kind": "Status", 153 | "apiVersion": "v1", 154 | "metadata": { 155 | }, 156 | "status": "Failure", 157 | "message": "secrets \"abc\" is forbidden: User \"system:serviceaccount:default:only-list-secrets-sa\" cannot get resource \"secrets\" in API group \"\" in the namespace \"default\"", 158 | "reason": "Forbidden", 159 | "details": { 160 | "name": "abc", 161 | "kind": "secrets" 162 | }, 163 | "code": 403 164 | } 165 | # Now to get all secrets in the default namespace, despite not having "get" permission 166 | curl http://127.0.0.1:8001/api/v1/namespaces/default/secrets?limit=500 -H \ 167 | "Authorization: Bearer $(kubectl -n default get secrets -ojson | jq '.items[]| select(.metadata.annotations."kubernetes.io/service-account.name"=="only-list-secrets-sa")| \ 168 | .data.token' | tr -d '"' | base64 -d)" 169 | { 170 | "kind": "SecretList", 171 | "apiVersion": "v1", 172 | "metadata": { 173 | "selfLink": "/api/v1/namespaces/default/secrets", 174 | "resourceVersion": "17718246" 175 | }, 176 | "items": [ 177 | REDACTED : REDACTED 178 | ] 179 | } 180 | # Cleanup 181 | kubectl delete serviceaccount only-list-secrets-sa 182 | kubectl delete role only-list-secrets-role 183 | kubectl delete rolebinding only-list-secrets-default-ns 184 | kubectl delete secret abc 185 | # Kill backgrounded kubectl proxy 186 | kill "%$(jobs | grep "kubectl proxy" | cut -d [ -f 2| cut -d ] -f 1)" 187 | ``` 188 | 189 | ### References 190 | 191 | Why list is a scary permission on k8s: 192 | 193 | Kubernetes security recommendations for developers: 194 | 195 | 196 | ## Unnecessary use of `WATCH` permission 197 | 198 | The watch response contains all items in full, not just their name when they're 199 | updated. Accounts with `WATCH` permission cannot get a specific item or list all 200 | items from the API, but will get all of them in full when during the watch call, 201 | and get all new items if the watch isn't interrupted. 202 | 203 | ### How to Prevent 204 | 205 | Only grant `WATCH` permission if you are also allowing that account to `GET` and 206 | `LIST` all of that resource 207 | 208 | ![Overly Permissive RBAC - 209 | Mitigations](../../../assets/images/K03-2022-mitigation.gif) 210 | 211 | ### Example Attack Scenarios 212 | 213 | ```bash 214 | 215 | # Create example A, which can only watch secrets in the default namespace 216 | # It does not have the GET permission 217 | kubectl create serviceaccount only-watch-secrets-sa 218 | kubectl create role only-watch-secrets-role --verb=watch --resource=secrets 219 | kubectl create rolebinding only-watch-secrets-default-ns --role=only-watch-secrets-role --serviceaccount=default:only-watch-secrets-sa 220 | # Now to impersonate that service account 221 | kubectl proxy & 222 | # Create a secret to get 223 | kubectl create secret generic abcd --from-literal=secretPassword=verySecure 224 | # Prove we cannot get that secret 225 | curl http://127.0.0.1:8001/api/v1/namespaces/default/secrets/abcd \ 226 | -H "Authorization: Bearer $(kubectl -n default get secrets -ojson | jq '.items[]| select(.metadata.annotations."kubernetes.io/service-account.name"=="only-watch-secrets-sa")| \ 227 | .data.token' | tr -d '"' | base64 -d)" 228 | { 229 | "kind": "Status", 230 | "apiVersion": "v1", 231 | "metadata": { 232 | }, 233 | "status": "Failure", 234 | "message": "secrets \"abc\" is forbidden: User \"system:serviceaccount:default:only-watch-secrets-sa\" cannot get resource \"secrets\" in API group \"\" in the namespace \"default\"", 235 | "reason": "Forbidden", 236 | "details": { 237 | "name": "abcd", 238 | "kind": "secrets" 239 | }, 240 | "code": 403 241 | } 242 | 243 | # Prove we cannot list the secrets either 244 | curl http://127.0.0.1:8001/api/v1/namespaces/default/secrets?limit=500 \ 245 | -H "Authorization: Bearer $(kubectl -n default get secrets -ojson | jq '.items[]| select(.metadata.annotations."kubernetes.io/service-account.name"=="only-watch-secrets-sa")| \ 246 | .data.token' | tr -d '"' | base64 -d)" 247 | { 248 | "kind": "Status", 249 | "apiVersion": "v1", 250 | "metadata": { 251 | 252 | }, 253 | "status": "Failure", 254 | "message": "secrets is forbidden: User \"system:serviceaccount:default:only-watch-secrets-sa\" cannot list resource \"secrets\" in API group \"\" in the namespace \"default\"", 255 | "reason": "Forbidden", 256 | "details": { 257 | "kind": "secrets" 258 | }, 259 | "code": 403 260 | } 261 | 262 | # Now to get all secrets in the default namespace, despite not having "get" permission 263 | curl http://127.0.0.1:8001/api/v1/namespaces/default/secrets?watch=true \ 264 | -H "Authorization: Bearer $(kubectl -n default get secrets -ojson | jq '.items[]| select(.metadata.annotations."kubernetes.io/service-account.name"=="only-watch-secrets-sa")| \ 265 | .data.token' | tr -d '"' | base64 -d)" 266 | 267 | { 268 | "type": "ADDED", 269 | "object": { 270 | "kind": "Secret", 271 | "apiVersion": "v1", 272 | "metadata": { 273 | "name": "abcd", 274 | "namespace": "default", 275 | "selfLink": "/api/v1/namespaces/default/secrets/abcd", 276 | "uid": "725c84ee-8dc7-41ef-a03e-193225e228b2", 277 | "resourceVersion": "1903164", 278 | "creationTimestamp": "2022-09-09T13:39:43Z", 279 | "managedFields": [ 280 | { 281 | "manager": "kubectl-create", 282 | "operation": "Update", 283 | "apiVersion": "v1", 284 | "time": "2022-09-09T13:39:43Z", 285 | "fieldsType": "FieldsV1", 286 | "fieldsV1": { 287 | "f:data": { 288 | ".": {}, 289 | "f:secretPassword": {} 290 | }, 291 | "f:type": {} 292 | } 293 | } 294 | ] 295 | }, 296 | "data": { 297 | "secretPassword": "dmVyeVNlY3VyZQ==" 298 | }, 299 | "type": "Opaque" 300 | } 301 | } 302 | REDACTED OTHER SECRETS 303 | # crtl+c to stop curl as this http request will continue 304 | 305 | # Proving that we got the full secret 306 | echo "dmVyeVNlY3VyZQ==" | base64 -d 307 | verySecure 308 | 309 | # Cleanup 310 | kubectl delete serviceaccount only-watch-secrets-sa 311 | kubectl delete role only-watch-secrets-role 312 | kubectl delete rolebinding only-watch-secrets-default-ns --role=only-list-secrets-role --serviceaccount=default:only-list-secrets-sa 313 | kubectl delete secret abcd 314 | # Kill backgrounded kubectl proxy 315 | kill "%$(jobs | grep "kubectl proxy" | cut -d [ -f 2| cut -d ] -f 1)" 316 | ``` 317 | 318 | ### References 319 | 320 | Kubernetes security recommendations for developers: 321 | 322 | -------------------------------------------------------------------------------- /2022/en/src/K04-policy-enforcement.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: "K04: Policy Enforcement" 5 | --- 6 | 7 | ## Overview 8 | 9 | Distributing and enforcing security policies across multiple clusters, clouds, 10 | and risk tolerances quickly becomes unmanageable for security teams. The 11 | inability to detect, remediate, and prevent misconfigurations from a central 12 | location can leave clusters open to compromise. 13 | 14 | ![Policy Enforcement - Illustration](../../../assets/images/K04-2022.gif) 15 | 16 | ## Description 17 | 18 | Kubernetes policy enforcement can and should take place in a few places 19 | throughout the software delivery lifecycle. Policy enforcement gives security 20 | and compliance teams the ability to apply governance, compliance, and security 21 | requirements throughout a multi-cluster / multi-cloud infrastructure. 22 | 23 | Example Enforcement Policies: 24 | 25 | *Disallowing Images from Untrusted Registries:* To prevent rogue images from 26 | running in certain clusters, it is recommended to distribute a blocking 27 | admission control policy that explicitly allows image registries. An example OPA 28 | Gatekeeper Rego policy that would block all workloads using images from 29 | registries that don’t match open-policy-agent and ubuntu is below: 30 | 31 | ```yaml 32 | # Allowed repos 33 | apiVersion: constraints.gatekeeper.sh/v1beta1 34 | kind: K8sAllowedRepos 35 | metadata: 36 | name: allowed-repos 37 | spec: 38 | match: 39 | kinds: 40 | - apiGroups: [""] 41 | kinds: ["Pod"] 42 | namespaces: 43 | - "sbx" 44 | - "prd" 45 | parameters: 46 | repos: 47 | - "open-policy-agent" 48 | - "ubuntu" 49 | ``` 50 | 51 | ## How to Prevent 52 | 53 | Detecting misconfigured workloads is not enough. Teams need the assurance that 54 | misconfigured Kubernetes objects can be blocked upon admission. This is 55 | typically handled by an [Admission 56 | Controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) 57 | on the Kubernetes API itself. Built-in functionality exists as part of the 58 | Kubernetes API itself called Pod Security Standards to enforce policy as part of 59 | the [Pod Security Admission 60 | Controller](https://kubernetes.io/docs/concepts/security/pod-security-admission/) 61 | in the cluster itself. It offers three modes - Privileged, Baseline, and 62 | Restricted. 63 | 64 | Other OSS projects such as Open Policy Agent Gatekeeper, Kyverno, and Kubewarden 65 | all offer policy enforcement capabilities as well to prevent misconfigured pods 66 | from being scheduled on a cluster. 67 | 68 | ![Policy Enforcement - 69 | Mitigations](../../../assets/images/K04-2022-mitigation.gif) 70 | 71 | ## Example Attack Scenarios 72 | 73 | Example #1: Container Breakout 1-Liner 74 | 75 | The following command if run against the Kubernetes API will create a very 76 | special pod that is running a highly privileged container. First we 77 | see `"hostPID": true`, which breaks down the most fundamental isolation of 78 | containers, letting us see all processes as if we were on the host. The 79 | `nsenter` command switches to a different `mount` namespace where `pid 1` is 80 | running which is the host `mount` namespace. Finally, we ensure the workload is 81 | `privileged` allowing us to prevent permissions errors. Boom. Container breakout 82 | in a [tweet](https://twitter.com/mauilion/status/1129468485480751104)! 83 | 84 | ```bash 85 | kubectl run r00t --restart=Never -ti --rm --image lol \ 86 | --overrides '{"spec":{"hostPID": true, 87 | "containers":[{"name":"1","image":"alpine", 88 | "command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"], 89 | "stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent", 90 | "securityContext":{"privileged":true}}]}}' \ 91 | / 92 | ``` 93 | 94 | ## References 95 | 96 | OPA Gatekeeper: 97 | [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper) 98 | 99 | Pod Security Admission Controller: 100 | [https://kubernetes.io/docs/concepts/security/pod-security-admission/](https://kubernetes.io/docs/concepts/security/pod-security-admission/) 101 | 102 | Kyverno: [https://kyverno.io/](https://kyverno.io/) 103 | -------------------------------------------------------------------------------- /2022/en/src/K05-inadequate-logging.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: "K05: Inadequate Logging" 5 | --- 6 | 7 | ## Overview 8 | 9 | A Kubernetes environment has the ability to generate logs at a variety of levels 10 | from many different components. When logs are not captured, stored, or actively 11 | monitored attackers have the ability to exploit vulnerabilities while going 12 | largely undetected. The lack of logging and monitoring also presents challenges 13 | during incident investigation and response efforts. 14 | 15 | ![Inadequate Logging - Illustration](../../../assets/images/K05-2022.gif) 16 | 17 | ## Description 18 | 19 | Inadequate logging in the context of Kubernetes occurs any time: 20 | 21 | - Relevant events such as failed authentication attempts, access to sensitive 22 | resources, manual deletion or modification of Kubernetes resources are not 23 | logged. 24 | - Logs and traces of running workloads are not monitored for suspicious 25 | activity. 26 | - Alerting thresholds are not in place or escalated appropriately. 27 | - Logs are not centrally stored and protected against tampering. 28 | - Logging infrastructure is disabled completely. 29 | 30 | ## How to Prevent 31 | 32 | The following logging sources should be enabled and configured appropriately: 33 | 34 | **Kubernetes Audit Logs: [Audit 35 | logging](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/)** is 36 | a Kubernetes feature that records actions taken by the API for later analysis. 37 | Audit logs help answer questions pertaining to events occurring on the API 38 | server itself. 39 | 40 | Ensure logs are monitoring for anomalous or unwanted API calls, especially any 41 | authorization failures (these log entries will have a status message 42 | “Forbidden”). Authorization failures could mean that an attacker is trying to 43 | abuse stolen credentials. 44 | 45 | Managed Kubernetes providers, including AWS, Azure, and GCP provide optional 46 | access to this data in their cloud console and may allow you to set up alerts on 47 | authorization failures. 48 | 49 | **Kubernetes Events:** Kubernetes events can indicate any Kubernetes resource 50 | state changes and errors, such as exceeded resource quota or pending pods, as 51 | well as any informational messages. 52 | 53 | **Application & Container Logs:** Applications running inside of Kubernetes 54 | generate useful logs from a security perspective. The easiest method for 55 | capturing these logs is to ensure the output is written to standard output 56 | `stdout` and standard error `stderr` streams. Persisting these logs can be 57 | carried out in a number of ways. It is common for operators to configure 58 | applications to write logs to a log file which is then consumed by a sidecar 59 | container to be shipped and processed centrally. 60 | 61 | **Operating System Logs**: Depending on the OS running the Kubernetes nodes, 62 | additional logs may be available for processing. Logs from programs such as 63 | `systemd` are available using the `journalctl -u` command. 64 | 65 | **Cloud Provider Logs:** If you are operating Kubernetes in a managed 66 | environment such as AWS EKS, Azure AKS, or GCP GKE you can find a number of 67 | additional logging streams available for consumption. One example, is within 68 | [Amazon EKS](https://aws.amazon.com/eks/) there exists a log stream specifically 69 | for the 70 | [Authenticator](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html) 71 | component. These logs represent the control plane component that EKS uses for 72 | RBAC authentication using AWS IAM credentials and can be a rich source of data 73 | for security operations teams. 74 | 75 | **Network Logs:** Network logs can be captured within Kubernetes at a number of 76 | layers. If you are working with traditional proxy or ingress components such as 77 | nginx or apache, you should use the standard out `stdout` and standard error 78 | `stderr` pattern to capture and ship these logs for further investigation. Other 79 | projects such as [eBPF](https://ebpf.io/) aim to provide consumable network and 80 | kernel logs to greater enhance security observability within the cluster. 81 | 82 | As outlined above, there is no shortage of logging mechanisms available within 83 | the Kubernetes ecosystem. A robust security logging architecture should not only 84 | capture relevant security events, but also be centralized in a way that is 85 | queryable, long term, and maintains integrity. 86 | 87 | ![Inadequate Logging - 88 | Mitigations](../../../assets/images/K05-2022-mitigation.gif) 89 | 90 | ## Example Attack Scenarios 91 | 92 | Scenario #1: Rouge Insider (anomalous number of “delete” events) 93 | 94 | Scenario #2: Service Account Token Compromise 95 | 96 | ## References 97 | 98 | [https://developer.squareup.com/blog/threat-hunting-with-kubernetes-audit-logs/](https://developer.squareup.com/blog/threat-hunting-with-kubernetes-audit-logs/) 99 | 100 | [https://kubernetes.io/docs/concepts/cluster-administration/logging/](https://kubernetes.io/docs/concepts/cluster-administration/logging/) 101 | 102 | [https://www.cncf.io/blog/2021/12/21/extracting-value-from-the-kubernetes-events-feed/](https://www.cncf.io/blog/2021/12/21/extracting-value-from-the-kubernetes-events-feed/) 103 | -------------------------------------------------------------------------------- /2022/en/src/K06-broken-authentication.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: "K06: Broken Authentication" 5 | --- 6 | 7 | ## Overview 8 | 9 | Authentication in Kubernetes takes on my many forms and is extremely flexible. 10 | This emphasis on being highly configurable makes Kubernetes work in a number of 11 | different environments but also presents challenges when it comes to cluster and 12 | cloud security posture. 13 | 14 | ![Broken Authentication - Illustration](../../../assets/images/K06-2022.gif) 15 | 16 | ## Description 17 | 18 | Several entities need to access the Kubernetes API. Authentication is the first 19 | hurdle for these requests. Authentication to the Kubernetes API is via HTTP 20 | request and the authentication method can vary from cluster to cluster. If a 21 | request cannot be authenticated, it is rejected with an HTTP status of 401. 22 | 23 | ![Kubernetes Authentication](../../../assets/images/kubernetes-auth.png) 24 | 25 | Source: 26 | [https://kubernetes.io/docs/concepts/security/controlling-access/](https://kubernetes.io/docs/concepts/security/controlling-access/) 27 | 28 | Let’s dive into the different types of subjects who need to authenticate to the 29 | Kubernetes API. 30 | 31 | ### Human Authentication 32 | 33 | People need to interact with Kubernetes for a number of reasons. Developers 34 | debugging their running application in a staging cluster, platform engineers 35 | building and testing new infra, and more. There are several methods available to 36 | authenticate to a cluster as a human such as OpenID Connect (OIDC), 37 | Certificates, cloud IAM, and even ServiceAccount tokens. Some of these offer 38 | much more robust security than others as we will explore in the prevention 39 | section below. 40 | 41 | ### Service Account Authentication 42 | 43 | Service account (SA) tokens can be presented to the Kubernetes API as an 44 | authentication mechanism when configured with RBAC appropriately. A SA is a 45 | simple authentication mechanism typically reserved for container-to-api 46 | authentication from *inside* the cluster. 47 | 48 | ## How to Prevent 49 | 50 | ### Avoid using certificates for end user authentication 51 | 52 | Certificates are convenient to use for authenticating to the Kubernetes API but 53 | should be used with extreme caution. At this time, the API has no way to revoke 54 | certificates making for a scramble to re-key the cluster in the event of a 55 | compromise or leak of private key material. Certificates are also more 56 | cumbersome to configure, sign, and distribute. A certificate may be used as a 57 | “Break Glass” authentication mechanism but not for primary auth. 58 | 59 | ### Never roll your own authentication 60 | 61 | Just like crypto, you should not build something novel when it isn’t necessary. 62 | Use what is supported and widely adopted. 63 | 64 | ### Enforce MFA when possible 65 | 66 | No matter the auth mechanism chosen, force humans to provide a second method of 67 | authentication (typically part of OIDC). 68 | 69 | ### Don’t use Service Account tokens from outside of the cluster 70 | 71 | For use inside the cluster, Kubernetes Service Account tokens are 72 | obtained directly using the TokenRequest API, and are mounted into Pods 73 | using a projected volume. For use outside the cluster, these tokens must be 74 | manually provisioned via a [Kubernetes Secret](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-long-lived-api-token-for-a-serviceaccount) 75 | and have no expiration. Using long-lived SA tokens from outside of the cluster 76 | opens your cluster up to significant risk. 77 | 78 | If a token based approach is required, short-lived tokens can be provisioned 79 | by the [TokenRequest API](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) 80 | or using [`kubectl create token` with the `--duration` 81 | flag](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/). 82 | 83 | ### Authenticate users and external services using short-lived tokens 84 | 85 | All authentication tokens should be as short-lived as tolerable. This way if 86 | (and when) a credential is leaked, it is possible that it may not be replayed in 87 | the time necessary to compromise the account. 88 | 89 | ![Broken Authentication - 90 | Mitigations](../../../assets/images/K06-2022-mitigation.gif) 91 | 92 | ## Example Attack Scenarios 93 | 94 | ***Accidental Git Leak:*** A developer accidentally checks their `.kubeconfig` 95 | file from their laptop which holds Kubernetes authentication credentials for 96 | their clusters at work. Someone scanning GitHub finds the credentials and 97 | replays them to the target API (unfortunately, sitting on the internet) and 98 | because the cluster is configured to authenticate using certificates, the leaked 99 | file has all of the information needed to successfully authenticate to the 100 | target cluster. 101 | 102 | ## References 103 | 104 | Tremlo Blog Post: 105 | [https://www.tremolosecurity.com/post/what-the-nsa-and-cisa-left-out-of-their-kubernetes-hardening-guide](https://www.tremolosecurity.com/post/what-the-nsa-and-cisa-left-out-of-their-kubernetes-hardening-guide) 106 | 107 | Kubernetes Authentication: 108 | [https://kubernetes.io/docs/concepts/security/controlling-access/](https://kubernetes.io/docs/concepts/security/controlling-access/) 109 | -------------------------------------------------------------------------------- /2022/en/src/K07-network-segmentation.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: "K07: Network Segmentation" 5 | --- 6 | 7 | ## Overview 8 | 9 | When operating Kubernetes with multiple microservices and tenants, a key area of 10 | concern is around control of network traffic. Isolating traffic within the 11 | context of a Kubernetes cluster can happen on a few levels including between 12 | pods, namespaces, labels, and more. 13 | 14 | ![Network Segmentation - Illustration](../../../assets/images/K07-2022.gif) 15 | 16 | ## Description 17 | 18 | Kubernetes networking is flat by default. Meaning that, when no additional 19 | controls are in place any workload can communicate to another without 20 | constraint. Attackers who exploit a running workload can leverage this default 21 | behavior to probe the internal network, traverse to other running containers, or 22 | invoke private APIs. 23 | 24 | ## How to Prevent 25 | 26 | Workloads in a cluster eventually need to communicate to one another as well as 27 | a variety of internal and external endpoints. The goal of network segmentation 28 | within Kubernetes is to minimize the blast radius if a container is compromised 29 | and stop lateral movement while allowing valid traffic to route as expected. 30 | 31 | ***Native Controls (Multi-Cluster)***: One way to truly enforce network 32 | isolation within Kubernetes is to utilize separate clusters when appropriate. 33 | This adds complexity when working with tightly coupled microservices but is a 34 | viable option when separating different tenants based on risk. 35 | 36 | ***Native Controls (NetworkPolicies):*** Network policies are built into 37 | Kubernetes itself and behave like firewall rules. They control how pods 38 | communicate. Without network policies, any pod can talk to any other pod. 39 | Network Policies should be defined as to limit pod communication to only defined 40 | assets while denying everything that isn’t explicitly configured. Below is an 41 | example of a network policy prevents backend egress between pods running the 42 | “default” namespace: 43 | 44 | ```yaml 45 | apiVersion: networking.k8s.io/v1 46 | kind: NetworkPolicy 47 | metadata: 48 | name: deny-backend-egress 49 | namespace: default 50 | 51 | spec: 52 | podSelector: 53 | matchLabels: 54 | tier: backend 55 | policyTypes: 56 | - Egress 57 | egress: 58 | - to: 59 | - podSelector: 60 | matchLabels: 61 | tier: backend 62 | ``` 63 | 64 | ***Service Mesh:*** There are a number of different service mesh projects 65 | available for different use cases including [Istio](https://istio.io/), 66 | [Linkerd](https://linkerd.io/), and [Hashicorp 67 | Consul](https://www.consul.io/docs/k8s). Each of these service mesh technologies 68 | offer different ways to segment network traffic within a Kubernetes cluster and 69 | all come with pros and cons. Below is an example of an Istio 70 | `AuthorizationPolicy`: 71 | 72 | ```yaml 73 | apiVersion: "security.istio.io/v1beta1" 74 | kind: "AuthorizationPolicy" 75 | metadata: 76 | name: "shoes-writer" 77 | namespace: default 78 | spec: 79 | selector: 80 | matchLabels: 81 | app: shoes 82 | rules: 83 | - from: 84 | - source: 85 | principals: ["cluster.local/ns/default/sa/inventory-sa"] 86 | to: 87 | - operation: 88 | methods: ["POST"] 89 | ``` 90 | 91 | - The **`selector`** on **`shoes`** means we're enforcing all Deployments 92 | labeled with **`app:shoes`**. 93 | - The **`source`** workload we're allowing has the **`inventory-sa`** identity. 94 | In a Kubernetes environment, this means that only pods with 95 | the **`inventory-sa`** [Service 96 | Account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) 97 | can access shoes. 98 | - The only allowed HTTP operation is **`POST`**, meaning that other HTTP 99 | operations, like **`GET and PUT`** will be denied. 100 | 101 | ***CNI Plugins:*** 102 | 103 | Container Network Interface (CNI) is an open source 104 | [specification](http://github.com/containernetworking/cni) that is used to 105 | configure access to networking resources. CNI is a software-defined mechanism 106 | for allowing or disallowing network access within Kubernetes and has a wide 107 | variety of supported plugins. Solutions such as [Project 108 | Calico](https://www.tigera.io/project-calico/) and [Cilium](https://cilium.io/) 109 | all offer different mechanisms for isolating network traffic within the context 110 | of Kubernetes. A CNI is typically needed if an operator would like to implement 111 | Kubernetes Network Policies (above). 112 | 113 | When choosing a CNI, it is most important to understand the feature-set that you 114 | are seeking from a security perspective and the resource overhead and 115 | maintenance related to using the plugin. 116 | 117 | ![Network Segmentation - 118 | Mitigation](../../../assets/images/K07-2022-mitigation.gif) 119 | 120 | ## Example Attack Scenarios 121 | 122 | A WordPress pod is compromised on a cluster that has no network segmentation and 123 | the attacker is able to utilize built-in networking utilities such as `dig` and 124 | `curl` to explore the network (it is an Ubuntu base image after all). They 125 | discover an internally accessible API running on port `6379` which is typically 126 | Redis. They are able to probe the Redis microservice which was intended to be 127 | internal and only used by backend APIs using `curl`. Data is stolen and 128 | modified. 129 | 130 | A locked-down `NetworkPolicy` or service mesh implementation would have made the 131 | network connectivity to Redis from something like WordPress impossible. 132 | 133 | A not-so-critical web application gets compromised on a cluster which has no 134 | network segmentation and the attacker is able to make a request to metadata URL 135 | to grab kube-env file containing certificate keys which has all the details for 136 | the bootstrap process. The attack can be performed to register itself as a node 137 | and steal secrets for further escalation. 138 | 139 | A simple `NetworkPolicy` mentioned below can block users from making calls to 140 | metadata URL 141 | 142 | ```yaml 143 | apiVersion: networking.k8s.io/v1 144 | kind: NetworkPolicy 145 | metadata: 146 | name: block-1 147 | spec: 148 | egress: 149 | - to: 150 | - ipBlock: 151 | cidr: 0.0.0.0/0 152 | except: 153 | - 169.254.169.254/32 154 | podSelector: {} 155 | policyTypes: 156 | - Egress 157 | ``` 158 | 159 | ## References 160 | 161 | Istio Authorization: 162 | [https://istiobyexample.dev/authorization/](https://istiobyexample.dev/authorization/) 163 | 164 | Kubernetes CNI Explained: 165 | [https://www.tigera.io/learn/guides/kubernetes-networking/kubernetes-cni/](https://www.tigera.io/learn/guides/kubernetes-networking/kubernetes-cni/) 166 | 167 | Kubernetes Network Policies: 168 | [https://kubernetes.io/docs/concepts/services-networking/network-policies/](https://kubernetes.io/docs/concepts/services-networking/network-policies/) 169 | 170 | Hacking kubelet on GKE: 171 | [https://www.4armed.com/blog/hacking-kubelet-on-gke/](https://www.4armed.com/blog/hacking-kubelet-on-gke/) 172 | -------------------------------------------------------------------------------- /2022/en/src/K08-secrets-management.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: "K08: Secrets Management" 5 | --- 6 | 7 | ## Overview 8 | 9 | In Kubernetes, a Secret is a small object that contains sensitive data, like a 10 | password or token. It is necessary to assess how sensitive data such as 11 | credentials and keys are stored and accessed. Secrets are a useful features in 12 | the Kubernetes ecosystem but need to be handled with extreme caution. 13 | 14 | ![Secrets Management - Illustration](../../../assets/images/K08-2022.gif) 15 | 16 | ## Description 17 | 18 | Kubernetes secrets are a standalone API object in Kubernetes used to store small 19 | objects. They are created like any other Kubernetes object. Below is a `.yaml` 20 | manifest that creates a secret called `top-secret`: 21 | 22 | ```yaml 23 | apiVersion: v1 24 | kind: Secret 25 | metadata: 26 | name: top-secret 27 | data: 28 | username: bXktdXNlcm5hbWUK 29 | password: bXktcGFzc3dvcmQK 30 | type: Opaque 31 | ``` 32 | 33 | The `username` and `password` values in the example manifest above are *base64* 34 | encoded and thus not encrypted (by default). This makes checking secrets into 35 | version control or other systems very dangerous. We will explore below how to 36 | prevent secrets leaking to unwanted locations. 37 | 38 | ## How to Prevent 39 | 40 | **Encrypt secrets at 41 | rest[¶](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html#encrypt-secrets-at-rest)** 42 | 43 | The etcd database in general contains any information accessible via the 44 | Kubernetes API and may grant an attacker significant visibility into the state 45 | of your cluster. 46 | 47 | Always encrypt your backups using a well reviewed backup and encryption 48 | solution, and consider using full disk encryption where possible. 49 | 50 | Kubernetes supports encryption at rest, a feature introduced in 1.7, and v1 beta 51 | since 1.13. This will encrypt Secret resources in etcd, preventing parties that 52 | gain access to your etcd backups from viewing the content of those secrets. 53 | While this feature is currently beta, it offers an additional level of defense 54 | when backups are not encrypted or an attacker gains read access to etcd. 55 | 56 | ### Address Security Misconfigurations 57 | 58 | In order to keep secrets safe and protected, it is important to start with 59 | rock-solid configuration across all of your clusters. Vulnerabilities, image 60 | security, and policy enforcement need to be in place to ultimately protect the 61 | applications from compromise. 62 | 63 | RBAC configuration should be locked down as well. Keep all Service Account and 64 | end user access to least privilege - especially when it comes to accessing 65 | secrets. Always audit the RBAC configuration of third-party plugins and software 66 | installed in the cluster to ensure access to Kubernetes secrets is not granted 67 | unnecessarily. 68 | 69 | ### Ensure Logging and Auditing is in Place 70 | 71 | Kubernetes clusters generate useful metrics around activities that can help 72 | detect malicious or anomalous behavior including access to secrets. Make sure to 73 | enable and configure [Kubernetes 74 | Audit](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/) 75 | records and centralize their storage. 76 | 77 | ![Secrets Management - 78 | Mitigations](../../../assets/images/K08-2022-mitigation.gif) 79 | 80 | ## Example Attack Scenarios 81 | 82 | An attacker compromises a web application running in a Kubernetes and is able to 83 | get a shell. They run the following command to ensure Kubernetes secrets are 84 | mounted: 85 | 86 | ```bash 87 | ls /var/run/secrets/kubernetes.io/serviceaccount 88 | ``` 89 | 90 | The attacker installs `kubectl` in the compromised pod which by default will 91 | attempt to use the default service account located in the above directory. The 92 | attacker can then communicate with the Kubernetes API from the inside leveraging 93 | the default service account’s RBAC access. Depending on how that RBAC is 94 | configured, the attacker may be able to read secrets or deploy malicious 95 | workloads into the cluster. 96 | 97 | ## References 98 | 99 | OWASP Kubernetes Cheatsheet: 100 | [https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html#securing-data](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html#securing-data) 101 | -------------------------------------------------------------------------------- /2022/en/src/K09-misconfigured-cluster-components.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: "K09: Misconfigured Cluster Components" 5 | --- 6 | 7 | ## Overview 8 | 9 | A Kubernetes cluster is compromised of many different components ranging from 10 | key-value storage within etcd, the kube-apiserver, the kubelet, and more. Each 11 | of these components are highly configurable have important security 12 | responsibilities. 13 | 14 | ![Misconfigured Cluster Components - 15 | Illustration](../../../assets/images/K09-2022.gif) 16 | 17 | ## Description 18 | 19 | Misconfigurations in core Kubernetes components can lead to complete cluster 20 | compromise or worse. In this section we will explore some of the components that 21 | exist on the Kubernetes control plane and nodes which can easily be 22 | misconfigured: 23 | 24 | **kubelet:** Agent that runs on each node in the cluster and ensures that 25 | containers run as expected and are healthy. Some dangerous configurations to 26 | watch out for on the kubelet itself are as follows: 27 | 28 | Anonymous authentication allows non-authenticated requests to the Kubelet. Check 29 | your Kubelet configuration and ensure the flag below is set to **false**: 30 | 31 | ```bash 32 | #bad 33 | --anonymous-auth=true 34 | #good 35 | --anonymous-auth=false 36 | ``` 37 | 38 | Authorization checks should always be performed when communicating with the 39 | Kubelets. It is possible to set the Authorization mode to explicitally allow 40 | unauthorized requests. Inspect the following to ensure this is not the case in 41 | your Kubelet config. The mode should be set to anything other than 42 | **AlwaysAllow**: 43 | 44 | ```bash 45 | #bad 46 | --authorization-mode=AlwaysAllow 47 | #good 48 | --authorization-mode=Webhook 49 | ``` 50 | 51 | **etcd:** A highly available key-value store that Kubernetes uses to centrally 52 | house all cluster data. It is important to keep etcd safe as it stores config 53 | data as well as secrets. 54 | 55 | **kube-apiserver:** The API server is a component of the Kubernetes [control 56 |  plane](https://kubernetes.io/docs/reference/glossary/?all=true#term-control-plane) 57 |  that exposes the Kubernetes API. The API server is the front end for the 58 |  Kubernetes control plane. 59 | 60 | A simple security check you can perform is to inspect the internet accessibility 61 | of the API server itself. It is recommended to keep the Kubernetes API off of 62 | public network as seen in recent 63 | [news](https://www.bleepingcomputer.com/news/security/over-900-000-kubernetes-instances-found-exposed-online/). 64 | 65 | ![Misconfigured Cluster Components - 66 | Mitigations](../../../assets/images/K09-2022-mitigation.gif) 67 | 68 | ## How to Prevent 69 | 70 | A good start is to perform regular CIS Benchmark scans and audits focused on 71 | component misconfigurations. A strong culture of Infrastructure-as-Code can also 72 | help centralize Kubernetes configuration and remediation giving security teams 73 | visibility into how clusters are created and maintained. Using managed 74 | Kubernetes such as EKS or GKE can also help limit some of the options for 75 | component configuration as well as guide operators into more secure defaults. 76 | 77 | ## References 78 | 79 | CIS Benchmark: 80 | [https://www.cisecurity.org/benchmark/kubernetes](https://www.cisecurity.org/benchmark/kubernetes) 81 | 82 | Kubernetes Cluster Components: 83 | [https://kubernetes.io/docs/concepts/overview/components/](https://kubernetes.io/docs/concepts/overview/components/) 84 | -------------------------------------------------------------------------------- /2022/en/src/K10-vulnerable-components.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: "K10: Vulnerable Components" 5 | --- 6 | 7 | ## Overview 8 | 9 | Vulnerabilities exist in Kubernetes and it is up to administrators to follow CVE 10 | databases, disclosures, and updates closely and have a plan for patch 11 | management. 12 | 13 | ![Vulnerable Components - Illustration](../../../assets/images/K10-2022.gif) 14 | 15 | ## Description 16 | 17 | A Kubernetes cluster is an extremely complex software ecosystem that can present 18 | challenges when it comes to traditional patch and vulnerability management. 19 | 20 | ***ArgoCD CVEs***: ArgoCD is a an extremely popular declarative GitOps tool used 21 | to continuously deliver software into one or more clusters. ArgoCD has had a few 22 | CVEs over the years including 23 | [CVE-2022-24348](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24348) 24 | which allows malicious actors to load a malicious Kubernetes Helm Chart (YAML). 25 | ArgoCD runs inside of the cluster and is responsible for deploying these charts 26 | automatically. This Helm chart exploits a parsing vulnerability to access 27 | restricted information such as API keys, secrets, and more. This data can then 28 | be used by the attacker to pivot within the Kubernetes cluster or dump further 29 | sensitive data. 30 | 31 | ***Kubernetes CVEs:*** In October 2021, the popular Kubernetes ingress 32 | `ingress-nginx` had a CVE released 33 | () which allowed users 34 | who had the ability to create or update ingress objects the ability to obtain 35 | all secrets in a cluster. This leveraged a supported feature called “custom 36 | snippets”. This issue was not addressable by solely upgrading the 37 | `ingress-nginx` version which made it a scramble for security teams to address 38 | at scale. 39 | 40 | ***Istio CVEs:*** One of the core pieces of functionality of Istio is to 41 | provided service-to-service authN / authZ. In 2020 an authentication bypass 42 | vulnerability was discovered 43 | ([https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8595](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8595)) 44 | which abused Istio’s Authentication Policy exact path matching logic. This 45 | allowed unauthorized access to resources without a valid JWT token. Attackers 46 | could bypass the JWT validation all-together by appending `?` or `#` characters 47 | after the protected paths. 48 | 49 | *Minimum Kubernetes Version*: If multiple clusters and running in different 50 | cloud or on-prem environments, it is important to maintain an accurate inventory 51 | of those clusters and ensure conformance with minimum Kubernetes versions. Using 52 | OSS IaC platforms such as Terraform, it is possible to audit the versions of the 53 | Kubernetes APIs across multiple clusters and patch when appropriate. 54 | 55 | ## How to Prevent 56 | 57 | Due to the sheer amount of third-party software running inside of a Kubernetes 58 | cluster, it takes a multi-pronged approach to eliminate vulnerable components: 59 | 60 | **Track CVE databases:** First and foremost, Kubernetes and the associated 61 | components cannot be left out of your existing CVE vulnerability scanning 62 | process 63 | 64 | **Continuous scanning:** Tools such as OPA Gatekeeper can be used to write 65 | custom rules which discover vulnerable components in a cluster. These should be 66 | run on a regular cadence and tracked by the security operations team. 67 | 68 | **Minimize third-party dependencies:** All third-party software should be 69 | audited independently before deployment for overly permissive RBAC, low-level 70 | kernel access, and historical vulnerability disclosure records. 71 | 72 | ![Vulnerable Components - 73 | Mitigations](../../../assets/images/K10-2022-mitigation.gif) 74 | 75 | ## Example Attack Scenarios 76 | 77 | CVEs can be abused in a myriad of ways. If an attacker is able to interact with 78 | any of the components within a cluster and exploit the CVE the ramifications can 79 | be full cluster compromise. Imagine an attacker taking advantage of a remote 80 | code execution vulnerability in a web application and gaining a shell in a 81 | cluster. They notice that they are not able to make an HTTP call to an adjacent 82 | microservice due to it being protected by an Istio policy. The attacker appends 83 | the `?` character to the end of the request which bypasses the JWT validation 84 | entirely and is able to pivot to the next protected API. 85 | 86 | ## References 87 | 88 | ArgoCD CVE Database: 89 | [https://www.cvedetails.com/vulnerability-list/vendor_id-11448/product_id-81059/version_id-634305/Linuxfoundation-Argo-cd--.html](https://www.cvedetails.com/vulnerability-list/vendor_id-11448/product_id-81059/version_id-634305/Linuxfoundation-Argo-cd--.html) 90 | 91 | CVE Database Keyword “Kubernetes”: 92 | [https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=kubernetes](https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=kubernetes) 93 | 94 | Istio Security Bulletins: 95 | [https://istio.io/latest/news/security/](https://istio.io/latest/news/security/) 96 | 97 | Kubernetes Security and Disclosure Information: 98 | [https://kubernetes.io/docs/reference/issues-security/security/](https://kubernetes.io/docs/reference/issues-security/security/) 99 | -------------------------------------------------------------------------------- /2022/en/src/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: "Top 10 Kubernetes Risks" 5 | --- 6 | 7 | 8 | # Welcome to the OWASP Kubernetes Top Ten 9 | -------------------------------------------------------------------------------- /2022/en/src/info.md: -------------------------------------------------------------------------------- 1 | 2 | ### Relevant Links 3 | 4 | - [OWASP Kubernetes Top 10 Project](../../../) 5 | - [Introduction](index) 6 | - [Other Risks to Consider](other-risks) 7 | 8 | ### Top 10 Kubernetes Risks 9 | 10 | - [K01: Insecure Workload Configuration](K01-insecure-workload-configurations) 11 | - [K02: Supply Chain Vulnerabilities](K02-supply-chain-vulnerabilities) 12 | - [K03: Overly Permissive RBAC](K03-overly-permissive-rbac) 13 | - [K04: Policy Enforcement](K04-policy-enforcement) 14 | - [K05: Inadequate Logging](K05-inadequate-logging) 15 | - [K06: Broken Authentication](K06-broken-authentication) 16 | - [K07: Network Segmentation](K07-network-segmentation) 17 | - [K08: Secrets Management](K08-secrets-management) 18 | - [K09: Misconfigured Cluster Components](K09-misconfigured-cluster-components) 19 | - [K10: Vulnerable Components](K10-vulnerable-components) 20 | -------------------------------------------------------------------------------- /2022/en/src/leaders.md: -------------------------------------------------------------------------------- 1 | 2 | ### Leaders 3 | 4 | - [Jimmy Mesta](mailto:jimmy@ksoc.com) 5 | -------------------------------------------------------------------------------- /2022/en/src/other-risks.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: "Other Risks to Consider" 5 | --- 6 | 7 | :warning: *Coming soon.* :warning: 8 | -------------------------------------------------------------------------------- /404.html: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | title: 404 - Not Found 4 | layout: col-generic 5 | 6 | --- 7 | 8 |
9 |

10 |

WHOA THAT PAGE CANNOT BE FOUND

11 |

Try the SEARCH function in the main navigation to find something. If you are looking for chapter information, please see Chapters for the correct chapter. For information about OWASP projects see Projects. For common attacks, vulnerabilities, or information about other community-led contributions see Contributed Content.

12 | 13 |
14 |

If all else fails you can search our historical site.

15 |
16 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. 6 | 7 | ## OWASP Code of Ethics 8 | 9 | Each of us is expected to behave according to the principles contained in the following Code of Ethics. Breaches of the Code of Ethics may result in the foundation taking disciplinary action. Membership Revocation 10 | 11 | * Perform all professional activities and duties in accordance with all applicable laws and the highest ethical principles; 12 | * Promote the implementation of and promote compliance with standards, procedures, controls for application security; 13 | * Maintain appropriate confidentiality of proprietary or otherwise sensitive information encountered in the course of professional activities; 14 | * Discharge professional responsibilities with diligence and honesty; 15 | * To communicate openly and honestly; 16 | * Refrain from any activities which might constitute a conflict of interest or otherwise damage the reputation of employers, the information security profession, or the Association; 17 | * To maintain and affirm our objectivity and independence; 18 | * To reject inappropriate pressure from industry or others; 19 | * Not intentionally injure or impugn the professional reputation of practice of colleagues, clients, or employers; 20 | * Treat everyone with respect and dignity; and 21 | * To avoid relationships that impair — or may appear to impair — OWASP's objectivity and independence. 22 | 23 | ## OWASP Core Values 24 | 25 | * Free & Open 26 | * Governed by rough consensus & running code 27 | * Abide by a code of ethics (see ethics) 28 | * Not-for-profit 29 | * Not driven by commercial interests 30 | * Risk based approach 31 | 32 | ## Our Standards 33 | 34 | Examples of behavior that contributes to creating a positive environment include: 35 | 36 | * Using welcoming and inclusive language 37 | * Being respectful of differing viewpoints and experiences 38 | * Gracefully accepting constructive criticism 39 | * Focusing on what is best for the community 40 | * Showing empathy towards other community members 41 | 42 | Examples of unacceptable behavior by participants include: 43 | 44 | * The use of sexualized language or imagery and unwelcome sexual attention or advances 45 | * Trolling, insulting/derogatory comments, and personal or political attacks 46 | * Public or private harassment 47 | * Publishing others' private information, such as a physical or electronic address, without explicit permission 48 | * Other conduct which could reasonably be considered inappropriate in a professional setting 49 | 50 | ## Our Responsibilities 51 | 52 | Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. 53 | 54 | Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. 55 | 56 | ## Scope 57 | 58 | This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. 59 | 60 | ## Enforcement 61 | 62 | Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at owasp.foundation@owasp.org. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. 63 | 64 | Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. 65 | 66 | ## Attribution 67 | 68 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version] 69 | 70 | [homepage]: http://contributor-covenant.org 71 | [version]: http://contributor-covenant.org/version/1/4/ -------------------------------------------------------------------------------- /Gemfile: -------------------------------------------------------------------------------- 1 | source 'https://rubygems.org' 2 | group :jekyll_plugins do 3 | gem "github-pages" 4 | end 5 | 6 | gem "webrick", "~> 1.7" -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Creative Commons Attribution-ShareAlike 4.0 International Public License 2 | 3 | By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. 4 | 5 | Section 1 – Definitions. 6 | 7 | Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. 8 | Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License. 9 | BY-SA Compatible License means a license listed at creativecommons.org/compatiblelicenses, approved by Creative Commons as essentially the equivalent of this Public License. 10 | Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. 11 | Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. 12 | Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. 13 | License Elements means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike. 14 | Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License. 15 | Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. 16 | Licensor means the individual(s) or entity(ies) granting rights under this Public License. 17 | Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. 18 | Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. 19 | You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning. 20 | 21 | Section 2 – Scope. 22 | 23 | License grant. 24 | Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: 25 | reproduce and Share the Licensed Material, in whole or in part; and 26 | produce, reproduce, and Share Adapted Material. 27 | Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. 28 | Term. The term of this Public License is specified in Section 6(a). 29 | Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material. 30 | Downstream recipients. 31 | Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. 32 | Additional offer from the Licensor – Adapted Material. Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply. 33 | No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. 34 | No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). 35 | 36 | Other rights. 37 | Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. 38 | Patent and trademark rights are not licensed under this Public License. 39 | To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. 40 | 41 | Section 3 – License Conditions. 42 | 43 | Your exercise of the Licensed Rights is expressly made subject to the following conditions. 44 | 45 | Attribution. 46 | 47 | If You Share the Licensed Material (including in modified form), You must: 48 | retain the following if it is supplied by the Licensor with the Licensed Material: 49 | identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); 50 | a copyright notice; 51 | a notice that refers to this Public License; 52 | a notice that refers to the disclaimer of warranties; 53 | a URI or hyperlink to the Licensed Material to the extent reasonably practicable; 54 | indicate if You modified the Licensed Material and retain an indication of any previous modifications; and 55 | indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. 56 | You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. 57 | If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. 58 | ShareAlike. 59 | 60 | In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply. 61 | The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License. 62 | You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material. 63 | You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply. 64 | 65 | Section 4 – Sui Generis Database Rights. 66 | 67 | Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: 68 | 69 | for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database; 70 | if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and 71 | You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. 72 | 73 | For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. 74 | 75 | Section 5 – Disclaimer of Warranties and Limitation of Liability. 76 | 77 | Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You. 78 | To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You. 79 | 80 | The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. 81 | 82 | Section 6 – Term and Termination. 83 | 84 | This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. 85 | 86 | Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 87 | automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 88 | upon express reinstatement by the Licensor. 89 | For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. 90 | For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. 91 | Sections 1, 5, 6, 7, and 8 survive termination of this Public License. 92 | 93 | Section 7 – Other Terms and Conditions. 94 | 95 | The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. 96 | Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License. 97 | 98 | Section 8 – Interpretation. 99 | 100 | For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. 101 | To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. 102 | No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. 103 | Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. 104 | 105 | Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” The text of the Creative Commons public licenses is dedicated to the public domain under the CC0 Public Domain Dedication. Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at creativecommons.org/policies, Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses. 106 | 107 | Creative Commons may be contacted at creativecommons.org. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ![OWASP Logo](https://owasp.org/assets/images/logo.png) 2 | 3 | # [OWASP Kubernetes Top 10](https://owasp.org/www-project-kubernetes-top-ten/) 4 | 5 | ## About the Kubernetes Top 10 6 | 7 | When adopting [Kubernetes](https://kubernetes.io), we introduce new risks to our applications and infrastructure. The *OWASP Kubernetes Top 10* is aimed at helping security practitioners, system administrators, and software developers prioritize risks around the Kubernetes ecosystem. The Top Ten is a prioritized list of these risks. In the future we hope for this to be backed by data collected from organizations varying in maturity and complexity. 8 | 9 | ### ToC 10 | 11 | * K00:2022 [Welcome to the Kubernetes Security Top Ten](2022/en/src/K00-introduction.md) 12 | * K01:2022 [Insecure Workload Configurations](2022/en/src/K01-insecure-workload-configurations.md) 13 | * K02:2022 [Supply Chain Vulnerabilities](2022/en/src/K02-supply-chain-vulnerabilities.md) 14 | * K03:2022 [Overly Permissive RBAC Configurations](2022/en/src/K03-overly-permissive-rbac.md) 15 | * K04:2022 [Lack of Centralized Policy Enforcement](2022/en/src/K04-policy-enforcement.md) 16 | * K05:2022 [Inadequate Logging and Monitoring](2022/en/src/K05-inadequate-logging.md) 17 | * K06:2022 [Broken Authentication Mechanisms](2022/en/src/K06-broken-authentication.md) 18 | * K07:2022 [Missing Network Segmentation Controls](2022/en/src/K07-network-segmentation.md) 19 | * K08:2022 [Secrets Management Failures](2022/en/src/K08-secrets-management.md) 20 | * K09:2022 [Misconfigured Cluster Components](2022/en/src/K09-misconfigured-cluster-components.md) 21 | * K10:2022 [Outdated and Vulnerable Kubernetes Components](2022/en/src/K10-vulnerable-components.md) 22 | * [Other Risks to Consider](2022/en/src/other-risks.md) 23 | 24 | 25 | ## Get Involved! 26 | 27 | Development of this document take place within the source repository on [GitHub](https://github.com/OWASP/www-project-kubernetes-top-ten). 28 | 29 | * We are actively looking for organizations and individuals that will provide Kubernetes vulnerability and misconfiguration data. 30 | * Translation efforts 31 | * Assisting in the development of related tools and projects 32 | - [OWASP Kubernetes Security Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) 33 | - [OWASP Kubernetes Security Testing Guide](https://github.com/owasp/www-project-kubernetes-security-testing-guide) 34 | - [OWASP Docker Security Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html) 35 | 36 | 37 | [Slack](https://owasp.slack.com): [#project-k8s-top10](https://owasp.slack.com/messages/project-k8s-top10) channel (Coming Soon!) 38 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | remote_theme: "owasp/www--site-theme@main" 2 | 3 | # core files/folders to exclude 4 | exclude: 5 | - README.md 6 | 7 | plugins: 8 | - jekyll-include-cache-0.2.0 9 | - jemoji -------------------------------------------------------------------------------- /assets/images/K01-2022-mitigation.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K01-2022-mitigation.gif -------------------------------------------------------------------------------- /assets/images/K01-2022.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K01-2022.gif -------------------------------------------------------------------------------- /assets/images/K02-2022-mitigation.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K02-2022-mitigation.gif -------------------------------------------------------------------------------- /assets/images/K02-2022.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K02-2022.gif -------------------------------------------------------------------------------- /assets/images/K03-2022-mitigation.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K03-2022-mitigation.gif -------------------------------------------------------------------------------- /assets/images/K03-2022.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K03-2022.gif -------------------------------------------------------------------------------- /assets/images/K04-2022-mitigation.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K04-2022-mitigation.gif -------------------------------------------------------------------------------- /assets/images/K04-2022.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K04-2022.gif -------------------------------------------------------------------------------- /assets/images/K05-2022-mitigation.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K05-2022-mitigation.gif -------------------------------------------------------------------------------- /assets/images/K05-2022.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K05-2022.gif -------------------------------------------------------------------------------- /assets/images/K06-2022-mitigation.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K06-2022-mitigation.gif -------------------------------------------------------------------------------- /assets/images/K06-2022.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K06-2022.gif -------------------------------------------------------------------------------- /assets/images/K07-2022-mitigation.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K07-2022-mitigation.gif -------------------------------------------------------------------------------- /assets/images/K07-2022.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K07-2022.gif -------------------------------------------------------------------------------- /assets/images/K08-2022-mitigation.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K08-2022-mitigation.gif -------------------------------------------------------------------------------- /assets/images/K08-2022.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K08-2022.gif -------------------------------------------------------------------------------- /assets/images/K09-2022-mitigation.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K09-2022-mitigation.gif -------------------------------------------------------------------------------- /assets/images/K09-2022.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K09-2022.gif -------------------------------------------------------------------------------- /assets/images/K10-2022-mitigation.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K10-2022-mitigation.gif -------------------------------------------------------------------------------- /assets/images/K10-2022.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/K10-2022.gif -------------------------------------------------------------------------------- /assets/images/README.md: -------------------------------------------------------------------------------- 1 | # placeholder 2 | 3 | Put images you wish to link to in this folder 4 | 5 | link would be in form /assets/images/ 6 | -------------------------------------------------------------------------------- /assets/images/kubernetes-auth.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/www-project-kubernetes-top-ten/a82de70b7d5c717e6673cc178cb6bdaacf1df1bb/assets/images/kubernetes-auth.png -------------------------------------------------------------------------------- /index.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: OWASP Kubernetes Top Ten 5 | tags: kubernetes 6 | level: 2 7 | type: 8 | pitch: Welcome to the OWASP Top Ten for Kubernetes 9 | 10 | --- 11 | ## About the Kubernetes Top 10 12 | 13 | When adopting [Kubernetes](https://kubernetes.io), we introduce new risks to our applications and infrastructure. The *OWASP Kubernetes Top 10* is aimed at helping security practitioners, system administrators, and software developers prioritize risks around the Kubernetes ecosystem. The Top Ten is a prioritized list of these risks. In the future we hope for this to be backed by data collected from organizations varying in maturity and complexity. 14 | 15 | ## Top 10 Kubernetes Risks - 2022 16 | 17 | - [K00: Welcome to the Kubernetes Security Top Ten](./2022/en/src/) 18 | - [K01: Insecure Workload Configurations](./2022/en/src/K01-insecure-workload-configurations) 19 | - [K02: Supply Chain Vulnerabilities](./2022/en/src/K02-supply-chain-vulnerabilities) 20 | - [K03: Overly Permissive RBAC Configurations](./2022/en/src/K03-overly-permissive-rbac) 21 | - [K04: Lack of Centralized Policy Enforcement](./2022/en/src/K04-policy-enforcement) 22 | - [K05: Inadequate Logging and Monitoring](./2022/en/src/K05-inadequate-logging) 23 | - [K06: Broken Authentication Mechanisms](./2022/en/src/K06-broken-authentication) 24 | - [K07: Missing Network Segmentation Controls](./2022/en/src/K07-network-segmentation) 25 | - [K08: Secrets Management Failures](./2022/en/src/K08-secrets-management) 26 | - [K09: Misconfigured Cluster Components](./2022/en/src/K09-misconfigured-cluster-components) 27 | - [K10: Outdated and Vulnerable Kubernetes Components](./2022/en/src/K10-vulnerable-components) 28 | - [Other Risks to Consider](./2022/en/src/other-risks) 29 | 30 | ## Getting Involved 31 | 32 | Development, issues, and discussion all take place on the OWASP Kubernetes Top Ten [GitHub](https://github.com/OWASP/www-project-kubernetes-top-ten) repository. Join the conversation! 33 | 34 | ## Licensing 35 | 36 | The Kubernetes OWASP Top 10 document is licensed under the CC BY-NC-SA 4.0, the Creative Commons Attribution-ShareAlike 4.0 license. Some rights reserved. 37 | 38 | ## Project Leaders 39 | 40 | - [Jimmy Mesta, Co-founder & CTO at KSOC](https://twitter.com/jimmesta) 41 | -------------------------------------------------------------------------------- /info.md: -------------------------------------------------------------------------------- 1 | 2 | ### Project Information 3 | 4 | 5 | - 6 | Incubator Project 7 | 8 | - Defender 9 | - Builder 10 | 11 | - Documentation 12 | 13 | 14 | ### Talks 15 | 16 | - [KubeCon 2019: Attacking and Defending Kubernetes Clusters](https://www.youtube.com/watch?v=UdMFTdeAL1s) 17 | - [Hiding in Plain Sight: Stopping Kubernetes Attacks](https://www.youtube.com/watch?v=8LWHzP72ln4) 18 | - [AKS Security Explained](https://www.youtube.com/watch?v=JD3mj5bTOuk) 19 | 20 | ### Code Repository 21 | 22 | - [GitHub Repo](https://github.com/OWASP/www-project-kubernetes-top-ten) 23 | -------------------------------------------------------------------------------- /leaders.md: -------------------------------------------------------------------------------- 1 | ### Leaders 2 | * [Jimmy Mesta, Co-founder & CTO at KSOC](mailto:jimmy@ksoc.com) 3 | -------------------------------------------------------------------------------- /markdown-link-check-config.json: -------------------------------------------------------------------------------- 1 | { 2 | "ignorePatterns": [ 3 | { 4 | "pattern": "^bundle.zip" 5 | }, 6 | { 7 | "pattern": "^News.xml" 8 | }, 9 | { 10 | "pattern": "^/" 11 | }, 12 | { 13 | "pattern": "vincent.bernat.im" 14 | }, 15 | { 16 | "pattern": "developer.android.com" 17 | }, 18 | { 19 | "pattern": "csrc.nist.gov" 20 | }, 21 | { 22 | "pattern": "www.exploit-db.com" 23 | } 24 | ], 25 | "httpHeaders": [ 26 | { 27 | "urls": ["https://", "http://"], 28 | "headers": { 29 | "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0" 30 | } 31 | } 32 | ] 33 | } 34 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "www-project-kubernetes-top-ten", 3 | "version": "0.0.1", 4 | "description": "OWASP Kubernetes Top Ten", 5 | "dependencies": {}, 6 | "devDependencies": { 7 | "markdownlint-cli": "^0.32.2", 8 | "textlint": "^12.5.1", 9 | "textlint-filter-rule-comments": "^1.2.2", 10 | "textlint-filter-rule-allowlist": "^4.0.0", 11 | "textlint-rule-terminology": "^3.0.4", 12 | "markdown-link-check": "^3.10.3" 13 | }, 14 | "scripts": { 15 | "test": "npm run lint-markdown && npm run lint-terminology", 16 | "lint-terminology": "textlint ./2022", 17 | "lint-markdown": "markdownlint ./2022", 18 | "link-check": "find 2022 -name \\*.md -exec markdown-link-check -c markdown-link-check-config.json 1> log 2> err {} \\; && if [ -e err ] && grep -q \"ERROR:\" err ; then exit 113 ; else echo -e \"All good\"; fi" 19 | }, 20 | "repository": { 21 | "type": "git", 22 | "url": "git+https://github.com/OWASP/www-project-kubernetes-top-ten.git" 23 | }, 24 | "author": "OWASP", 25 | "license": "CC-BY-SA-4.0", 26 | "bugs": { 27 | "url": "https://github.com/OWASP/www-project-kubernetes-top-ten/issues" 28 | }, 29 | "homepage": "https://github.com/OWASP/www-project-kubernetes-top-ten#readme" 30 | 31 | } 32 | -------------------------------------------------------------------------------- /tab_example.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Example 3 | layout: null 4 | tab: true 5 | order: 1 6 | tags: example-tag 7 | --- 8 | 9 | ## Example 10 | 11 | Put whatever you like here: news, screenshots, features, supporters, or remove this file and don't use tabs at all. --------------------------------------------------------------------------------