mirrors/kyverno
mirrors/kyverno
1
0
Fork 0
mirror of https://github.com/kyverno/kyverno.git synced 2025-03-13 11:18:47 +00:00
Code Activity

manifest fixes; typos; linting

Browse source
This commit is contained in:
Chip Zoller 2020-11-11 13:07:01 -05:00
parent 851561723f
commit 16dc96b898
24 changed files with 107 additions and 124 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
samples/AddDefaultNetworkPolicy.md
View file

@ -1,10 +1,10 @@
# Default deny all ingress traffic
By default, Kubernetes allows communications across all pods within a cluster. Network policies and, a CNI that supports network policies, must be used to restrict communinications.
By default, Kubernetes allows communications across all pods within a cluster. Network policies and, a CNI that supports network policies, must be used to restrict communications.
A default `NetworkPolicy` should be configured for each namespace to default deny all ingress traffic to the pods in the namespace. Application teams can then configure additional `NetworkPolicy` resources to allow desired traffic to application pods from select sources.
## Policy YAML
## Policy YAML
[add_network_policy.yaml](best_practices/add_network_policy.yaml)
@ -17,7 +17,7 @@ spec:
rules:
- name: default-deny-ingress
match:
resources:
resources:
kinds:
- Namespace
name: "*"
@ -27,7 +27,7 @@ spec:
- "default"
- "kube-public"
- "kyverno"
generate:
generate:
kind: NetworkPolicy
name: default-deny-ingress
namespace: "{{request.object.metadata.name}}"
@ -35,7 +35,7 @@ spec:
spec:
# select all pods in the namespace
podSelector: {}
policyTypes:
policyTypes:
- Ingress
````
````

19
samples/AddNamespaceQuotas.md
View file

@ -4,11 +4,11 @@ To limit the number of resources like CPU and memory, as well as objects that ma
## Additional Information
* [Resource Quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/)
* [Resource Quotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/)
## Policy YAML
## Policy YAML
[add_ns_quota.yaml](best_practices/add_ns_quota.yaml)
[add_ns_quota.yaml](best_practices/add_ns_quota.yaml)
````yaml
apiVersion: kyverno.io/v1
@ -23,11 +23,12 @@ spec:
kinds:
- Namespace
exclude:
namespaces:
- "kube-system"
- "default"
- "kube-public"
- "kyverno"
resources:
namespaces:
- "kube-system"
- "default"
- "kube-public"
- "kyverno"
generate:
kind: ResourceQuota
name: default-resourcequota
@ -58,4 +59,4 @@ spec:
cpu: 200m
memory: 256Mi
type: Container
````
````

34
samples/AddSafeToEvict.md
View file

@ -6,7 +6,7 @@ The Kubernetes cluster autoscaler does not evict pods that use `hostPath` or `em
cluster-autoscaler.kubernetes.io/safe-to-evict: true
````
This policy matches and mutates pods with `emptyDir` and `hostPath` volumes, to add the `safe-to-evict` annotation if it is not specified.
This policy matches and mutates pods with `emptyDir` and `hostPath` volumes to add the `safe-to-evict` annotation if it is not specified.
## Policy YAML
@ -15,36 +15,36 @@ This policy matches and mutates pods with `emptyDir` and `hostPath` volumes, to
````yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
metadata:
name: add-safe-to-evict
spec:
rules:
spec:
rules:
- name: "annotate-empty-dir"
match:
resources:
kinds:
match:
resources:
kinds:
- Pod
mutate:
mutate:
patchStrategicMerge:
metadata:
annotations:
+(cluster-autoscaler.kubernetes.io/safe-to-evict): "true"
spec:
volumes:
spec:
volumes:
- (emptyDir): {}
- name: annotate-host-path
match:
resources:
kinds:
match:
resources:
kinds:
- Pod
mutate:
mutate:
patchStrategicMerge:
metadata:
annotations:
+(cluster-autoscaler.kubernetes.io/safe-to-evict): "true"
spec:
volumes:
spec:
volumes:
- (hostPath):
path: "*"
````
````

6
samples/CheckUserGroup.md
View file

@ -1,8 +1,8 @@
# Check userID, groupIP & fsgroup
All processes inside the pod can be made to run with specific user and groupID by setting `runAsUser` and `runAsGroup` respectively. `fsGroup` can be specified to make sure any file created in the volume with have the specified groupID. These options can be used to validate the IDs used for user and group.
All processes inside the pod can be made to run with a specific user and groupID by setting `runAsUser` and `runAsGroup`, respectively. `fsGroup` can be specified to make sure any file created in the volume will have the specified groupID. These options can be used to validate the IDs used for user and group.
## Policy YAML
## Policy YAML
[policy_validate_user_group_fsgroup_id.yaml](more/restrict_usergroup_fsgroup_id.yaml)
@ -46,4 +46,4 @@ spec:
spec:
securityContext:
fsGroup: '2000'
````
````

22
samples/DisallowBindMounts.md
View file

@ -2,27 +2,27 @@
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
[disallow_bind_mounts.yaml](best_practices/disallow_bind_mounts.yaml)
[disallow_bind_mounts.yaml](best_practices/disallow_bind_mounts.yaml)
````yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
metadata:
name: disallow-bind-mounts
spec:
validationFailureAction: audit
rules:
rules:
- name: validate-hostPath
match:
resources:
kinds:
match:
resources:
kinds:
- Pod
validate:
validate:
message: "Host path volumes are not allowed"
pattern:
spec:
=(volumes):
pattern:
spec:
=(volumes):
- X(hostPath): "null"
````

14
samples/DisallowDefaultNamespace.md
View file

@ -2,9 +2,9 @@
Kubernetes namespaces are an optional feature that provide a way to segment and isolate cluster resources across multiple applications and users. As a best practice, workloads should be isolated with namespaces. Namespaces should be required and the default (empty) namespace should not be used.
## Policy YAML
## Policy YAML
[disallow_default_namespace.yaml](best_practices/disallow_default_namespace.yaml)
[disallow_default_namespace.yaml](best_practices/disallow_default_namespace.yaml)
````yaml
apiVersion: kyverno.io/v1
@ -12,12 +12,12 @@ kind: ClusterPolicy
metadata:
name: disallow-default-namespace
annotations:
pod-policies.kyverno.io/autogen-controllers: none
pod-policies.kyverno.io/autogen-controllers: none
policies.kyverno.io/category: Workload Isolation
policies.kyverno.io/description: Kubernetes namespaces are an optional feature
that provide a way to segment and isolate cluster resources across multiple
applications and users. As a best practice, workloads should be isolated with
namespaces. Namespaces should be required and the default (empty) namespace
policies.kyverno.io/description: Kubernetes namespaces are an optional feature
that provide a way to segment and isolate cluster resources across multiple
applications and users. As a best practice, workloads should be isolated with
namespaces. Namespaces should be required and the default (empty) namespace
should not be used.
spec:
validationFailureAction: audit

8
samples/DisallowDockerSockMount.md
View file

@ -1,12 +1,10 @@
# Disallow Docker socket bind mount
The Docker socket bind mount allows access to the
Docker daemon on the node. This access can be used for privilege escalation and
to manage containers outside of Kubernetes, and hence should not be allowed.
The Docker socket bind mount allows access to the Docker daemon on the node. This access can be used for privilege escalation and to manage containers outside of Kubernetes, and hence should not be allowed.
## Policy YAML
## Policy YAML
[disallow_docker_sock_mount.yaml](best_practices/disallow_docker_sock_mount.yaml)
[disallow_docker_sock_mount.yaml](best_practices/disallow_docker_sock_mount.yaml)
````yaml
apiVersion: kyverno.io/v1

9
samples/DisallowHelmTiller.md
View file

@ -1,10 +1,10 @@
# Disallow Helm Tiller
Tiller has known security challenges. It requires adminstrative privileges and acts as a shared resource accessible to any authenticated user. Tiller can lead to privilge escalation as restricted users can impact other users.
Tiller, in the [now-deprecated Helm v2](https://helm.sh/blog/helm-v2-deprecation-timeline/), has known security challenges. It requires adminstrative privileges and acts as a shared resource accessible to any authenticated user. Tiller can lead to privilge escalation as restricted users can impact other users.
## Policy YAML
## Policy YAML
[disallow_helm_tiller.yaml](best_practices/disallow_helm_tiller.yaml)
[disallow_helm_tiller.yaml](best_practices/disallow_helm_tiller.yaml)
````yaml
apiVersion : kyverno.io/v1
@ -26,5 +26,4 @@ spec:
containers:
- name: "*"
image: "!*tiller*"
````
````

6
samples/DisallowHostNetworkPort.md
View file

@ -1,13 +1,12 @@
# Disallow `hostNetwork` and `hostPort`
Using `hostPort` and `hostNetwork` allows pods to share the host networking stack allowing potential snooping of network traffic across application pods.
Using `hostPort` and `hostNetwork` allows pods to share the host networking stack allowing potential snooping of network traffic across application pods.
## Policy YAML
[disallow_host_network_port.yaml](best_practices/disallow_host_network_port.yaml)
````yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
@ -39,5 +38,4 @@ spec:
- name: "*"
=(ports):
- X(hostPort): null
````
````

6
samples/DisallowHostPIDIPC.md
View file

@ -1,10 +1,10 @@
# Disallow `hostPID` and `hostIPC`
Sharing the host's PID namespace allows an application pod to gain visibility of processes on the host, potentially exposing sensitive information. Sharing the host's IPC namespace also allows the container process to communicate with processes on the host.
Sharing the host's PID namespace allows an application pod to gain visibility of processes on the host, potentially exposing sensitive information. Sharing the host's IPC namespace also allows the container process to communicate with processes on the host.
To avoid pod container from having visibility to host process space, validate that `hostPID` and `hostIPC` are set to `false`.
To avoid the pod container from having visibility to the host process space, validate that `hostPID` and `hostIPC` are set to `false`.
## Policy YAML
## Policy YAML
[disallow_host_pid_ipc.yaml](best_practices/disallow_host_pid_ipc.yaml)

6
samples/DisallowLatestTag.md
View file

@ -1,12 +1,11 @@
# Disallow latest image tag
The `:latest` tag is mutable and can lead to unexpected errors if the upstream image changes. A best practice is to use an immutable tag that maps to a specific and tested version of an application pod.
The `:latest` tag is mutable and can lead to unexpected errors if the upstream image changes. A best practice is to use an immutable tag that maps to a specific and tested version of an application image.
## Policy YAML
## Policy YAML
[disallow_latest_tag.yaml](best_practices/disallow_latest_tag.yaml)
````yaml
apiVersion : kyverno.io/v1
kind: ClusterPolicy
@ -37,5 +36,4 @@ spec:
spec:
containers:
- image: "!*:latest"
````

7
samples/DisallowNewCapabilities.md
View file

@ -1,10 +1,6 @@
# Disallow new capabilities
Linux allows defining fine-grained permissions using
capabilities. With Kubernetes, it is possible to add capabilities that escalate the
level of kernel access and allow other potentially dangerous behaviors. This policy
enforces that containers cannot add new capabilities. Other policies can be used to set
default capabilities.
Linux allows defining fine-grained permissions using capabilities. With Kubernetes, it is possible to add capabilities that escalate the level of kernel access and allow other potentially dangerous behaviors. This policy enforces that containers cannot add new capabilities. Other policies can be used to set default capabilities.
## Policy YAML
@ -34,5 +30,4 @@ spec:
=(securityContext):
=(capabilities):
X(add): null
````

4
samples/DisallowPrivilegedContainers.md
View file

@ -1,10 +1,10 @@
# Diallow privileged containers
Privileged containers are defined as any container where the container uid 0 is mapped to the host’s uid 0. A process within a privileged container can get unrestricted host access. With `securityContext.allowPrivilegeEscalation` enabled, a process can gain privileges from its parent.
Privileged containers are defined as any container where the container uid 0 is mapped to the host's uid 0. A process within a privileged container can get unrestricted host access. With `securityContext.allowPrivilegeEscalation` enabled, a process can gain privileges from its parent.
To disallow privileged containers and privilege escalation, run pod containers with `securityContext.privileged` set to `false` and `securityContext.allowPrivilegeEscalation` set to `false`.
## Policy YAML
## Policy YAML
[disallow_privileged.yaml](best_practices/disallow_privileged.yaml)

6
samples/DisallowRootUser.md
View file

@ -1,14 +1,14 @@
# Run as non-root user
By default, all processes in a container run as the root user (uid 0). To prevent potential compromise of container hosts, specify a non-root and least privileged user ID when building the container image and require that application containers run as non root users i.e. set `runAsNonRoot` to `true`.
By default, all processes in a container run as the root user (uid 0). To prevent potential compromise of container hosts, specify a non-root user and least privileged user ID when building the container image and require that application containers run as non-root users (i.e. set `runAsNonRoot` to `true`).
## Additional Information
* [Pod Security Context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
## Policy YAML
## Policy YAML
[disallow_root_user.yaml](best_practices/disallow_root_user.yaml)
[disallow_root_user.yaml](best_practices/disallow_root_user.yaml)
````yaml
apiVersion: kyverno.io/v1

5
samples/DisallowSysctls.md
View file

@ -1,11 +1,10 @@
# Disallow changes to kernel parameters
The Sysctl interface allows modifications to kernel parameters at runtime. In a Kubernetes pod these parameters can be specified under `securityContext.sysctls`. Kernel parameter modifications can be used for exploits and should be restricted.
The Sysctl interface allows modifications to kernel parameters at runtime. In a Kubernetes, pod these parameters can be specified under `securityContext.sysctls`. Kernel parameter modifications can be used for exploits and should be restricted.
## Additional Information
* [List of supported namespaced sysctl interfaces](https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/)
* [List of supported namespaced sysctl interfaces](https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/)
## Policy YAML

8
samples/RequirePodProbes.md
View file

@ -1,10 +1,10 @@
# Require `livenessProbe` and `readinessProbe`
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 pod's 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 receive network traffic.
## Policy YAML
## Policy YAML
[require_probes.yaml](best_practices/require_probes.yaml)
@ -29,9 +29,7 @@ spec:
spec:
containers:
- livenessProbe:
periodSeconds: ">0"
periodSeconds: ">0"
readinessProbe:
periodSeconds: ">0"
````

6
samples/RequirePodRequestsLimits.md
View file

@ -1,10 +1,10 @@
# Require pod resource requests and limits
Application workloads share cluster resources. Hence, it is important to manage resources assigned for each pod. It is recommended that `resources.requests` and `resources.limits` are configured per pod and include CPU and memory resources. Other resources such as, GPUs, may also be specified as needed.
Application workloads share cluster resources. Hence, it is important to manage resources assigned to each pod. It is recommended that `resources.requests` and `resources.limits` are configured per pod and include CPU and memory resources. Other resources such as GPUs may also be specified as needed.
If a namespace level request or limit is specified, defaults will automatically be applied to each pod based on the `LimitRange` configuration.
If a namespace level request or limit is specified, defaults will automatically be applied to each pod based on the `LimitRange` configuration.
## Policy YAML
## Policy YAML
[require_pod_requests_limits.yaml](best_practices/require_pod_requests_limits.yaml)

5
samples/RequireReadOnlyRootFS.md
View file

@ -1,12 +1,11 @@
# 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 filesystem helps to enforce an immutable infrastructure strategy; the container only needs to write to 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.
## Policy YAML
## Policy YAML
[require_ro_rootfs.yaml](best_practices/require_ro_rootfs.yaml)
````yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy

7
samples/RestrictAutomountSAToken.md
View file

@ -2,9 +2,9 @@
Kubernetes automatically mounts service account credentials in each pod. The service account may be assigned roles allowing pods to access API resources. To restrict access, opt out of auto-mounting tokens by setting `automountServiceAccountToken` to `false`.
## Policy YAML
## Policy YAML
[restrict_automount_sa_token.yaml](more/restrict_automount_sa_token.yaml)
[restrict_automount_sa_token.yaml](more/restrict_automount_sa_token.yaml)
````yaml
apiVersion : kyverno.io/v1
@ -25,6 +25,3 @@ spec:
spec:
automountServiceAccountToken: false
````

6
samples/RestrictImageRegistries.md
View file

@ -1,12 +1,12 @@
# Disallow unknown image registries
Images from unknown registries may not be scanned and secured. Requiring the use of trusted registries helps reduce threat exposure.
Images from unknown registries may not be scanned and secured. Requiring the use of trusted registries helps reduce threat exposure.
You can customize this policy to allow image registries that you trust.
## Policy YAML
## Policy YAML
[restrict_image_registries.yaml](more/restrict_image_registries.yaml)
[restrict_image_registries.yaml](more/restrict_image_registries.yaml)
````yaml
apiVersion : kyverno.io/v1

4
samples/RestrictIngressClasses.md
View file

@ -2,9 +2,9 @@
It can be useful to restrict Ingress resources to a set of known ingress classes that are allowed in the cluster. You can customize this policy to allow ingress classes that are configured in the cluster.
## Policy YAML
## Policy YAML
[restrict_ingress_classes.yaml](more/restrict_ingress_classes.yaml)
[restrict_ingress_classes.yaml](more/restrict_ingress_classes.yaml)
````yaml
apiVersion : kyverno.io/v1

9
samples/RestrictNodePort.md
View file

@ -1,8 +1,8 @@
# Restrict use of `NodePort` services
A Kubernetes service of type `NodePort` uses a host port (on every node in the cluster) to receive traffic from any source.
A Kubernetes service of type `NodePort` uses a host port (on every node in the cluster) to receive traffic from any source.
Kubernetes Network Policies cannot be used to control traffic to host ports.
Kubernetes Network Policies cannot be used to control traffic to host ports.
Although NodePort services can be useful, their use should be limited to services with additional upstream security checks.
@ -26,8 +26,7 @@ spec:
- Service
validate:
message: "Services of type NodePort are not allowed"
pattern:
pattern:
spec:
type: "!NodePort"
````
````

11
samples/best_practices/add_network_policy.yaml
View file

@ -20,11 +20,12 @@ spec:
- Namespace
name: "*"
exclude:
namespaces:
- "kube-system"
- "default"
- "kube-public"
- "kyverno"
resources:
namespaces:
- "kube-system"
- "default"
- "kube-public"
- "kyverno"
generate:
kind: NetworkPolicy
name: default-deny-ingress

11
samples/best_practices/add_ns_quota.yaml
View file

@ -15,11 +15,12 @@ spec:
kinds:
- Namespace
exclude:
namespaces:
- "kube-system"
- "default"
- "kube-public"
- "kyverno"
resources:
namespaces:
- "kube-system"
- "default"
- "kube-public"
- "kyverno"
generate:
kind: ResourceQuota
name: default-resourcequota