kubernetes
Security checks for kubernetes configuration files.
Run Locally
Rules (11)
In Kubernetes, each pod runs in its own isolated environment with its own set of security policies. However, certain container images may contain `setuid` or `setgid` binaries that could allow an attacker to perform privilege escalation and gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container in the pod, with the parameter `allowPrivilegeEscalation` set to `false`. This will prevent the container from running any privileged processes and limit the impact of any potential attacks. By adding the `allowPrivilegeEscalation` parameter to your the `securityContext`, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.
Exposing host's Docker socket to containers via a volume. The owner of this socket is root. Giving someone access to it is equivalent to giving unrestricted root access to your host. Remove 'docker.sock' from hostpath to prevent this.
Pod is sharing the host IPC namespace. This allows container processes to communicate with processes on the host which reduces isolation and bypasses container protection models. Remove the 'hostIPC' key to disable this functionality.
Pod may use the node network namespace. This gives the pod access to the loopback device, services listening on localhost, and could be used to snoop on network activity of other pods on the same node. Remove the 'hostNetwork' key to disable this functionality.
Pod is sharing the host process ID namespace. When paired with ptrace this can be used to escalate privileges outside of the container. Remove the 'hostPID' key to disable this functionality.
Container or pod is running in privileged mode. This grants the container the equivalent of root capabilities on the host machine. This can lead to container escapes, privilege escalation, and other security concerns. Remove the 'privileged' key to disable this capability.
When running containers in Kubernetes, it's important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container, with the parameter `runAsNonRoot` set to `true`. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a `securityContext` to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.
Container is explicitly disabling seccomp confinement. This runs the service in an unrestricted state. Remove 'seccompProfile: unconfined' to prevent this.
Cluster is disabling TLS certificate verification when communicating with the server. This makes your HTTPS connections insecure. Remove the 'insecure-skip-tls-verify: true' key to secure communication.
Service is disabling TLS certificate verification when communicating with the server. This makes your HTTPS connections insecure. Remove the 'insecureSkipTLSVerify: true' key to secure communication.
Container $CONTAINER is running with a writable root filesystem. This may allow malicious applications to download and run additional payloads, or modify container files. If an application inside a container has to save something temporarily consider using a tmpfs. Add 'readOnlyRootFilesystem: true' to this container to prevent this.