CloudWiki
Rules
Low

Ensure containers run with a high GID to avoid host conflict

Security & Compliance
No items found.
Description

Running containers with a high GID (Group ID) is a security best practice to avoid conflicts with users and groups on the host system. The GID is a numerical identifier assigned to a group on Linux and other Unix-based operating systems. By default, container processes run with a low GID, which can lead to conflicts with users and groups on the host system that have the same ID. An attacker could potentially exploit this to gain elevated privileges on the host system. Running containers with a high GID ensures that the container processes are isolated from the host system's users and groups, reducing the risk of conflicts and potential security vulnerabilities.

Remediation

To ensure that containers run with a high GID and avoid host conflicts, you can take the following remediation steps:

  1. Define a non-root user and group inside the Dockerfile or container image.
  2. Set the group ID (GID) of the non-root group to a value higher than 1000. This ensures that it doesn't conflict with the host's GID.
  3. Build the Docker image using the non-root user and group.
  4. Run the container using the non-root user and group.

You can also use Kubernetes SecurityContext to set the group ID for a container. In the Pod SecurityContext, set the runAsGroup field to a value higher than 1000. This ensures that the container runs with a non-root group ID, avoiding conflicts with the host's GID.

Additionally, you can also use Pod Security Policies to enforce that all containers in the pod are run with a non-root user and group. This provides an added layer of security to ensure that containers don't run with a root user or group, which can increase the attack surface.

Enforced Resources
Pod
Note: Remediation steps provided by Lightlytics are meant to be suggestions and guidelines only. It is crucial to thoroughly verify and test any remediation steps before applying them to production environments. Each organization's infrastructure and security needs may differ, and blindly applying suggested remediation steps without proper testing could potentially cause unforeseen issues or vulnerabilities. Therefore, it is strongly recommended that you validate and customize any remediation steps to meet your organization's specific requirements and ensure that they align with your security policies and best practices.