mirror of
https://github.com/jpetazzo/container.training.git
synced 2026-07-18 12:29:18 +00:00
📃 Update Kyverno section
This commit is contained in:
@@ -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
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user