Docker containers should run with non root users

[aaronbrethorst]

A docker best practice is to create a new user and group without super user privileges and run your application with them. We should do that here, too.

Tasks:

• [ ] research docker best practices
• [ ] update the oba/Dockerfile file with the result of research into how to best run OBA server container without super user privileges.
• [ ] update the bundler/Dockerfile file with the result of research into how to best run transit data bundler container without super user privileges.
• [ ] Validate that everything works by creating a new bundle, launching the oba_app container, and running bin/validate.sh

Docs:

The official Docker instructions on this topic are extremely brief (and frankly kind of unhelpful), but they represent a good jumping off point to find other guides on how to do this around the web: https://docs.docker.com/develop/develop-images/instructions/#user

[myselfdeepdas]

To run Docker containers without superuser privileges, you can follow these best practices:

Create a non-root user: Use the USER directive in your Dockerfile to create a non-root user for running the container. Ensure this user has the necessary permissions to execute the required commands.

Use a non-privileged port: Avoid using privileged ports (ports below 1024) for your applications, as these require superuser privileges. Use ports above 1024 instead.

Minimize the use of sudo: Limit the use of sudo within your Dockerfile, as this requires superuser privileges. Try to perform the necessary actions without elevated permissions.

[Stazz0]

We can also use these practices to run Docker containers without superuser privileges:

1. Create a Non-Root User in Dockerfile: Docker containers, by default, run as root, which is equivalent to the root user of the host machine. To mitigate this, you can create a non-root user in your Dockerfile and switch to it before executing your application.

2. Use USER Instruction: The USER instruction in Dockerfile specifies the default user for the container. This user will be used for any RUN, CMD, and ENTRYPOINT instructions that follow in the Dockerfile.

3. Least Privilege Principle: Opt to create a dedicated user and a dedicated group in the Docker image for the application. Use the USER directive in the Dockerfile to ensure the container runs the application with the least privileged access possible.

4. Leverage User Namespaces: Docker allows us to leverage user namespaces to provide additional isolation for users within the container.

@aaronbrethorst can I start work on this issue?

[SudipMukhejee]

Use Goss or Docker Bench Security: Tools like Goss or Docker Bench Security can be incorporated into your Dockerfile to perform security checks and ensure best practices. These tools can help you identify potential security issues, including running containers as the root user.

Docker Security Scanning: Docker provides security scanning tools that can analyze your Docker images for vulnerabilities. By addressing these vulnerabilities, you enhance the overall security of your containers.

AppArmor or SELinux: AppArmor or SELinux can be used to enforce security policies on containers. These mandatory access control systems allow you to define fine-grained security policies, restricting the capabilities of containers.

Privilege Separation: Consider breaking your application into multiple containers with different responsibilities. For example, have a separate container for a web server and a separate container for a database. This way, each container runs with the minimum required privileges for its specific role.

Docker Security Tools: Explore other security-focused tools such as Clair for vulnerability analysis, Trivy for container scanning, and Dive for exploring and analyzing container images. These tools can help you identify and address security concerns.

Multi-Stage Builds: Use multi-stage Docker builds to separate the build environment from the runtime environment. This can reduce the number of unnecessary tools and libraries in the final image, potentially minimizing security risks. @aaronbrethorst can I start work on this issue?

[CesarAndrade007]

Assigned.