Built-in Configuration Audit Policies
The following sections list built-in configuration audit policies installed with trivy-operator. They are stored in the
trivy-operator-policies-config
ConfigMap created in the installation namespace (e.g. trivy-system
). You can modify
them or add a new policy. For example, follow the Writing Custom Configuration Audit Policies tutorial to add a custom
policy that checks for recommended Kubernetes labels on any resource kind.
The Trivy Operator pulls the information from the trivy-policies respository.
Once the Trivy Operator is installed inside the Kubernetes cluster, it will perform the following processes:
- The node-collector will collect infrastructure data from node filesystem and processes
- It then outputs the data as JSON output
- The the Rego policies (cis-controls) from trivy-policies are executed against the infrastructure data (JSON) and return evaluation results as ConfigAudit and Compliance reports
General
NAME |
DESCRIPTION |
KINDS |
CPU not limited |
Enforcing CPU limits prevents DoS via resource exhaustion. |
Workload |
CPU requests not specified |
When containers have resource requests specified, the scheduler can make better decisions about which nodes to place pods on, and how to deal with resource contention. |
Workload |
SYS_ADMIN capability added |
SYS_ADMIN gives the processes running inside the container privileges that are equivalent to root. |
Workload |
Default capabilities not dropped |
The container should drop all default capabilities and add only those that are needed for its execution. |
Workload |
Root file system is not read-only |
An immutable root file system prevents applications from writing to their local disk. This can limit intrusions, as attackers will not be able to tamper with the file system or write foreign executables to disk. |
Workload |
Memory not limited |
Enforcing memory limits prevents DoS via resource exhaustion. |
Workload |
Memory requests not specified |
When containers have memory requests specified, the scheduler can make better decisions about which nodes to place pods on, and how to deal with resource contention. |
Workload |
hostPath volume mounted with docker.sock |
Mounting docker.sock from the host can give the container full root access to the host. |
Workload |
Runs with low group ID |
Force the container to run with group ID > 10000 to avoid conflicts with the host’s user table. |
Workload |
Runs with low user ID |
Force the container to run with user ID > 10000 to avoid conflicts with the host’s user table. |
Workload |
Tiller Is Deployed |
Check if Helm Tiller component is deployed. |
Workload |
Image tag ':latest' used |
It is best to avoid using the ':latest' image tag when deploying containers in production. Doing so makes it hard to track which version of the image is running, and hard to roll back the version. |
Workload |
Advanced
Pod Security Standard
Baseline
NAME |
DESCRIPTION |
KINDS |
Access to host IPC namespace |
Sharing the host’s IPC namespace allows container processes to communicate with processes on the host. |
Workload |
Access to host network |
Sharing the host’s network namespace permits processes in the pod to communicate with processes bound to the host’s loopback adapter. |
Workload |
Access to host PID |
Sharing the host’s PID namespace allows visibility on host processes, potentially leaking information such as environment variables and configuration. |
Workload |
Privileged container |
Privileged containers share namespaces with the host system and do not offer any security. They should be used exclusively for system containers that require high privileges. |
Workload |
Non-default capabilities added |
Adding NET_RAW or capabilities beyond the default set must be disallowed. |
Workload |
hostPath volumes mounted |
HostPath volumes must be forbidden. |
Workload |
Access to host ports |
HostPorts should be disallowed, or at minimum restricted to a known list. |
Workload |
Default AppArmor profile not set |
A program inside the container can bypass AppArmor protection policies. |
Workload |
SELinux custom options set |
Setting a custom SELinux user or role option should be forbidden. |
Workload |
Non-default /proc masks set |
The default /proc masks are set up to reduce attack surface, and should be required. |
Workload |
Unsafe sysctl options set |
Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed 'safe' subset. A sysctl is considered safe if it is namespaced in the container or the Pod, and it is isolated from other Pods or processes on the same Node. |
Workload |
Restricted
NAME |
DESCRIPTION |
KINDS |
Non-ephemeral volume types used |
In addition to restricting HostPath volumes, usage of non-ephemeral volume types should be limited to those defined through PersistentVolumes. |
Workload |
Process can elevate its own privileges |
A program inside the container can elevate its own privileges and run as root, which might give the program control over the container and node. |
Workload |
Runs as root user |
'runAsNonRoot' forces the running image to run as a non-root user to ensure least privileges. |
Workload |
A root primary or supplementary GID set |
Containers should be forbidden from running with a root primary or supplementary GID. |
Workload |
Default Seccomp profile not set |
The RuntimeDefault seccomp profile must be required, or allow specific additional profiles. |
Workload |
RBAC