Best practice policies are recommended policies that can be applied to your Kubernetes clusters with minimal changes. To import these policies [install Kyverno](../documentation/installation.md) and import the resources as follows:
By default, processes in a container run as a root user (uid 0). To prevent compromising the host, a best practice is to specify a least-privileged user ID when building the container image, and require that application containers run as non-root users.
One can access the API from inside a pod using automatically mounted service account credentials by default. To restrict access, opt-out of automounting API credentials for any pod by setting `automountServiceAccountToken` to `false`.
Namespaces are a way to divide cluster resources between multiple users. When multiple users or teams are sharing a single cluster, it is recommended to isolate different workloads and avoid using default namespace.
The volume of type `hostpath` bounds the pods to host, and data persisted in the volume is based on the life of the node. It is suggested to disable the use of a volume of type hostpath.
NetworkPolicy resources can currently only control NodePorts by allowing or disallowing all traffic on them. Unless required, it is recommended to disable use to service type `NodePort`.
A process within privileged containers gets almost the same privileges that are available to processes outside a container providing almost unrestricted host access. With `securityContext.allowPrivilegeEscalation` enabled the process can gain ore privileges that its parent.
When no policies exist in a namespace, Kubernetes allows all ingress and egress traffic to and from pods in that namespace. A "default" isolation policy for a namespace denies any ingress traffic to the pods in that namespace, this ensures that even pods that aren’t selected by any other NetworkPolicy will still be isolated.
Using the `:latest` tag when deploying containers in production makes it harder to track which version of the image is running and more challenging to roll back properly. Specifying a none latest image tag prevents a lot of errors from occurring when versions are inconsistent.
To limit the number of objects, as well as the total amount of compute resources that may be consumed by an application, it is essential to create one resource quota for each namespace by the cluster administrator.
As workloads share the host cluster, it is essential to administer and limit resources requested and consumed by the pod. It is a good practice always to specify `resources.requests` and `resources.limits` per pod.
A read-only root file system helps to enforce an immutable infrastructure strategy; the container only needs to write on the mounted volume that persists the state. An immutable root filesystem can also prevent malicious binaries from writing to the host system.
Images from the unrecognized registry can introduce complexity to maintain the application. By specifying trusted registries help to reduce such complexity. Follow instructions [here](https://github.com/nirmata/kyverno/blob/master/documentation/writing-policies-validate.md#operators) to add allowed registries using `OR` operator.
Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled or disabled by listing them in `securityContext.capabilites`.
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.
The Sysctl interface allows to modify kernel parameters at runtime and in the pod can be specified under `securityContext.sysctls`. If kernel parameters in the pod are to be modified, should be handled cautiously, and policy with rules restricting these options will be helpful. We can control minimum and maximum port that a network connection can use as its source(local) port by checking net.ipv4.ip_local_port_range
