mirrors/kyverno
mirrors/kyverno
1
0
Fork 0
mirror of https://github.com/kyverno/kyverno.git synced 2025-03-06 16:06:56 +00:00
Code Activity

Merge branch '452_make_sample_policy_rule_names_consistent' of https://github.com/nirmata/kyverno into 452_make_sample_policy_rule_names_consistent

Browse source
This commit is contained in:
Jim Bugwadia 2019-11-12 23:18:08 -08:00
commit 38f6eb1cff
5 changed files with 9 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
samples/DisallowBindMounts.md
View file

@ -1,6 +1,6 @@
# Disallow use of bind mounts (`hostPath` volumes) # Disallow use of bind mounts (`hostPath` volumes)
The volume of type `hostPath` allows pods to use host bind mounts (i.e. directories and volumes mounted to a host path) in containers. Using host resources can be used to access shared data or escalate priviliges. Also, this couples pods to a specific host and data persisted in the `hostPath` volume is coupled to the life of the node leading to potential pod scheduling failures. It is highly recommeded that applications are designed to be decoupled from the underlying infrstructure (in this case, nodes). The volume of type `hostPath` allows pods to use host bind mounts (i.e. directories and volumes mounted to a host path) in containers. Using host resources can be used to access shared data or escalate privileges. Also, this couples pods to a specific host and data persisted in the `hostPath` volume is coupled to the life of the node leading to potential pod scheduling failures. It is highly recommended that applications are designed to be decoupled from the underlying infrastructure (in this case, nodes).
## Policy YAML ## Policy YAML

2
samples/RequirePodProbes.md
View file

@ -2,7 +2,7 @@
Liveness and readiness probes need to be configured to correctly manage a pods lifecycle during deployments, restarts, and upgrades. Liveness and readiness probes need to be configured to correctly manage a pods lifecycle during deployments, restarts, and upgrades.
For each pod, a periodic `livenessProbe` is performed by the kubelet to determine if the pod's containers are running or need to be restarted. A `readinessProbe` is used by services and deployments to determine if the pod is ready to recieve network traffic. For each pod, a periodic `livenessProbe` is performed by the kubelet to determine if the pod's containers are running or need to be restarted. A `readinessProbe` is used by services and deployments to determine if the pod is ready to receive network traffic.
## Policy YAML ## Policy YAML

4
samples/RequireReadOnlyRootFS.md
View file

@ -1,4 +1,4 @@
# Require Read-only root filesystem # Require read-only root filesystem
A read-only root file system helps to enforce an immutable infrastructure strategy; the container only needs to write on mounted volumes that can persist state even if the container exits. An immutable root filesystem can also prevent malicious binaries from writing to the host system. A read-only root file system helps to enforce an immutable infrastructure strategy; the container only needs to write on mounted volumes that can persist state even if the container exits. An immutable root filesystem can also prevent malicious binaries from writing to the host system.
@ -26,4 +26,4 @@ spec:
containers: containers:
- securityContext: - securityContext:
readOnlyRootFilesystem: true readOnlyRootFilesystem: true
```` ````

8
samples/best_practices/disallow_bind_mounts.yaml
View file

@ -6,10 +6,10 @@ metadata:
policies.kyverno.io/category: Workload Isolation policies.kyverno.io/category: Workload Isolation
policies.kyverno.io/description: The volume of type `hostPath` allows pods to use host bind policies.kyverno.io/description: The volume of type `hostPath` allows pods to use host bind
mounts (i.e. directories and volumes mounted to a host path) in containers. Using host mounts (i.e. directories and volumes mounted to a host path) in containers. Using host
resources can be used to access shared data or escalate priviliges. Also, this couples pods resources can be used to access shared data or escalate privileges. Also, this couples pods
to a specific host and data persisted in the `hostPath` volume is coupled to the life of the to a specific host and data persisted in the `hostPath` volume is coupled to the life of the
node leading to potential pod scheduling failures. It is highly recommeded that applications node leading to potential pod scheduling failures. It is highly recommended that applications
are designed to be decoupled from the underlying infrstructure (in this case, nodes). are designed to be decoupled from the underlying infrastructure (in this case, nodes).
spec: spec:
rules: rules:
@ -23,4 +23,4 @@ spec:
pattern: pattern:
spec: spec:
volumes: volumes:
- X(hostPath): null - X(hostPath): null

2
samples/best_practices/require_probes.yaml
View file

@ -8,7 +8,7 @@ metadata:
correctly manage a pods lifecycle during deployments, restarts, and upgrades. For each correctly manage a pods lifecycle during deployments, restarts, and upgrades. For each
pod, a periodic `livenessProbe` is performed by the kubelet to determine if the pod's pod, a periodic `livenessProbe` is performed by the kubelet to determine if the pod's
containers are running or need to be restarted. A `readinessProbe` is used by services containers are running or need to be restarted. A `readinessProbe` is used by services
and deployments to determine if the pod is ready to recieve network traffic. and deployments to determine if the pod is ready to receive network traffic.
spec: spec:
rules: rules:
- name: validate-livenessProbe-readinessProbe - name: validate-livenessProbe-readinessProbe