From faabbb13ae1ed73fb3c7a3882f735f6c69c540fd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Petazzoni?= <jerome.petazzoni@gmail.com>
Date: Fri, 5 Nov 2021 13:38:38 +0100
Subject: [PATCH] =?UTF-8?q?=F0=9F=93=83=20Update=20Kyverno=20section?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 slides/k8s/kyverno.md | 78 ++++++++++++++++++++++++-------------------
 1 file changed, 43 insertions(+), 35 deletions(-)

diff --git a/slides/k8s/kyverno.md b/slides/k8s/kyverno.md
index b0ed828f..1fdc0897 100644
--- a/slides/k8s/kyverno.md
+++ b/slides/k8s/kyverno.md
@@ -181,11 +181,31 @@
 
 ---
 
+## Painting pods
+
+- As an example, we'll implement a policy regarding "Pod color"
+
+- The color of a Pod is the value of the label `color`
+
+- Example: `kubectl label pod hello color=yellow` to paint a Pod in yellow
+
+- We want to implement the following policies:
+
+  - color is optional (i.e. the label is not required)
+
+  - if color is set, it *must* be `red`, `green`, or `blue`
+
+  - once the color has been set, it cannot be changed
+
+  - once the color has been set, it cannot be removed
+
+---
+
 ## Immutable primary colors, take 1
 
-- Our pods can have an optional `color` label
+- First, we will add a policy to block forbidden colors
 
-- If the label exists, it *must* be `red`, `green`, or `blue`
+  (i.e. only allow `red`, `green`, or `blue`)
 
 - One possible approach:
 
@@ -197,6 +217,14 @@
 
 ---
 
+.small[
+```yaml
+@@INCLUDE[k8s/kyverno-pod-color-1.yaml]
+```
+]
+
+---
+
 ## Testing without the policy
 
 - First, let's create a pod with an "invalid" label
@@ -221,16 +249,6 @@
 
 ---
 
-## Our first Kyverno policy
-
-.small[
-```yaml
-@@INCLUDE[k8s/kyverno-pod-color-1.yaml]
-```
-]
-
----
-
 ## Load and try the policy
 
 .exercise[
@@ -258,7 +276,7 @@
 
 ## Immutable primary colors, take 2
 
-- New rule: once a `color` label has been added, it cannot be changed
+- Next rule: once a `color` label has been added, it cannot be changed
 
   (i.e. if `color=red`, we can't change it to `color=blue`)
 
@@ -276,6 +294,14 @@
 
 ---
 
+.small[
+```yaml
+@@INCLUDE[k8s/kyverno-pod-color-2.yaml]
+```
+]
+
+---
+
 ## Invalid references
 
 - We can access the `color` label through `{{ request.object.metadata.labels.color }}`
@@ -296,16 +322,6 @@
 
 ---
 
-## Our second Kyverno policy
-
-.small[
-```yaml
-@@INCLUDE[k8s/kyverno-pod-color-2.yaml]
-```
-]
-
----
-
 ## Load and try the policy
 
 .exercise[
@@ -391,7 +407,7 @@
 
 ## Immutable primary colors, take 3
 
-- New rule: once a `color` label has been added, it cannot be removed
+- Last rule: once a `color` label has been added, it cannot be removed
 
 - Our approach is to match all pods that:
 
@@ -405,8 +421,6 @@
 
 ---
 
-## Our third Kyverno policy
-
 .small[
 ```yaml
 @@INCLUDE[k8s/kyverno-pod-color-3.yaml]
@@ -582,8 +596,6 @@ Note: the `apiVersion` field appears to be optional.
 
 - It offers both namespaced and cluster-scope policies
 
-  (same thing for the policy violations)
-
 - The policy language leverages existing constructs
 
   (e.g. `matchExpressions`)
@@ -592,9 +604,9 @@ Note: the `apiVersion` field appears to be optional.
 
 ## Caveats
 
-- By default, the webhook failure policy is `Ignore`
+- The `{{ request }}` context is powerful, but difficult to validate
 
-  (meaning that there is a potential to evade policies if we can DOS the webhook)
+  (Kyverno can't know ahead of time how it will be populated)
 
 - Advanced policies (with conditionals) have unique, exotic syntax:
   ```yaml
@@ -604,11 +616,7 @@ Note: the `apiVersion` field appears to be optional.
 	        path: "!/var/run/docker.sock"
   ```
 
-- The `{{ request }}` context is powerful, but difficult to validate
-
-  (Kyverno can't know ahead of time how it will be populated)
-
-- Policy validation is difficult
+- Writing and validating policies can be difficult
 
 ---