Admin: New server guide

2026-04-12T20:01:27Z

New server guide

New page

= Container Security Best Practices =

This guide outlines essential security practices for running containers in production environments. We will cover image scanning, running containers as non-root users, and secure secrets management.

== Prerequisites ==
* Basic understanding of Docker or a similar container runtime.
* Access to a Linux server with Docker installed.
* Familiarity with the command line.
* Optional: Access to a cloud GPU provider like [https://en.immers.cloud/signup/r/20241007-8310688-334/ Immers Cloud] if your containerized applications require GPU acceleration. Immers Cloud offers GPU servers starting from $0.23/hr for inference up to $4.74/hr for H200 instances.

== Understanding Container Security Risks ==
Containers, while providing isolation, are not inherently secure out-of-the-box. Common risks include:
* '''Vulnerable Images:''' Container images can contain outdated software with known security flaws.
* '''Root Privileges:''' Running containers as root inside the container grants them extensive privileges, which can be exploited if the container is compromised.
* '''Secrets Exposure:''' Hardcoding sensitive information like API keys or database passwords directly into container images or environment variables is a major security risk.
* '''Insecure Network Configurations:''' Poorly configured networks can expose container services to unauthorized access.

== 1. Image Scanning for Vulnerabilities ==
Regularly scanning your container images for known vulnerabilities is a critical first step. Tools like Trivy or Clair can help identify these issues.

=== Using Trivy ===
Trivy is a simple and comprehensive scanner that detects vulnerabilities in OS packages and application dependencies.

# '''Install Trivy:'''
<pre>
sudo apt-get update
sudo apt-get install wget apt-transport-https gnupg lsb-release
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo "deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install trivy
</pre>

# '''Scan a Docker Image:'''
To scan an image from Docker Hub (e.g., `nginx:latest`):
<pre>
trivy image nginx:latest
</pre>

# '''Scan a Local Image:'''
If you have a locally built image, you can scan it by its ID or name:
<pre>
trivy image <your_image_name>:<tag>
</pre>

# '''Scan a Running Container:'''
You can also scan a running container:
<pre>
trivy container <container_id_or_name>
</pre>

=== Best Practices for Image Scanning ===
* '''Automate:''' Integrate image scanning into your CI/CD pipeline to catch vulnerabilities before deployment.
* '''Regular Scans:''' Schedule regular scans of deployed images to detect newly discovered vulnerabilities.
* '''Remediate:''' Prioritize and fix vulnerabilities based on their severity. Update base images and application dependencies.

== 2. Running Containers as Non-Root Users ==
By default, many container images run processes as the root user (UID 0) inside the container. This is a security anti-pattern. If an attacker gains access to the container, they will have root privileges within that container's namespace, which can lead to privilege escalation.

=== Modifying Dockerfiles ===
The most effective way to run containers as non-root is to configure your Dockerfile.

# '''Create a new user and group:'''
Add the following lines to your Dockerfile:
<pre>
# Create a non-root user and group
RUN addgroup --gid 1000 appgroup && \
adduser --uid 1000 --ingroup appgroup --shell /bin/sh --disabled-password appuser
</pre>

# '''Switch to the non-root user:'''
Use the `USER` instruction to switch to the newly created user before running your application:
<pre>
USER appuser
</pre>

# '''Set appropriate file permissions:'''
Ensure that the non-root user has the necessary permissions to access application files and directories.
<pre>
# Example: Change ownership of application directory
RUN chown -R appuser:appgroup /app
</pre>

# '''Build and run your image:'''
<pre>
docker build -t my-secure-app .
docker run -d -p 8080:80 my-secure-app
</pre>

=== Verifying Non-Root Execution ===
After running your container, you can verify that it's running as a non-root user.

# '''Find your container ID:'''
<pre>
docker ps
</pre>

# '''Execute a command inside the container:'''
<pre>
docker exec -it <container_id> id
</pre>
The output should show a UID other than 0.

== 3. Secrets Management ==
Handling sensitive data like API keys, database credentials, and TLS certificates requires careful attention. Never hardcode secrets directly into your Dockerfile or container images.

=== Docker Secrets ===
Docker Swarm provides a built-in mechanism for managing secrets.

# '''Create a secret:'''
<pre>
echo "your_database_password" | docker secret create db_password -
</pre>

# '''Deploy a service with secrets:'''
When deploying a service in Docker Swarm, you can mount secrets into the container.
<pre>
docker service create \
--name my-app-service \
--secret db_password \
my-secure-app
</pre>

# '''Accessing secrets inside the container:'''
Secrets are mounted as files in `/run/secrets/` within the container.
<pre>
# Inside the container, your application can read the password from /run/secrets/db_password
</pre>

=== Environment Variables (with caution) ===
While not as secure as Docker Secrets for sensitive data, environment variables can be used for less sensitive configuration. For sensitive data, always use a dedicated secrets management solution.

# '''Set environment variables during runtime:'''
<pre>
docker run -d -p 8080:80 \
-e DATABASE_URL="postgres://user:your_password@host:port/db" \
my-secure-app
</pre>
'''Note:''' Sensitive data passed via environment variables can be inspected by anyone with access to the Docker daemon or by using `docker inspect`.

=== External Secrets Management Tools ===
For more robust secrets management, consider integrating with external tools like HashiCorp Vault, AWS Secrets Manager, or Kubernetes Secrets. These tools offer features like encryption, auditing, and fine-grained access control.

== 4. Network Security ===
Securing your container's network is crucial to prevent unauthorized access.

=== Using Docker Networks ===
Create custom Docker networks for your containers instead of relying on the default bridge network. This provides better isolation.

# '''Create a custom network:'''
<pre>
docker network create my-app-network
</pre>

# '''Run containers on the custom network:'''
<pre>
docker run -d --network my-app-network --name webserver nginx
docker run -d --network my-app-network --name app my-secure-app
</pre>
Containers on the same custom network can communicate with each other using their container names as hostnames.

=== Limiting Port Exposure ===
Only expose ports that are absolutely necessary.

# '''Publish specific ports:'''
<pre>
docker run -d -p 8080:80 my-secure-app
</pre>
This publishes port 80 inside the container to port 8080 on the host.

== Troubleshooting ==
* '''Container exits immediately:''' This often indicates a problem with the application running inside the container, such as incorrect permissions or a missing dependency. Check container logs using `docker logs <container_id>`.
* '''Cannot access application:''' Ensure the correct ports are published (`docker ps`) and that firewall rules on the host are not blocking access.
* '''Permission denied errors:''' Verify that the non-root user has the necessary read/write permissions for application directories and files.
* '''Secrets not accessible:''' Double-check the secret name and ensure it's correctly passed to the service or container. For Docker Secrets, confirm the service is running in Swarm mode.

== Further Reading ==
* [[Docker Security Best Practices]]
* [[Kubernetes Security]]

[[Category:Containerization]]
[[Category:Security]]
[[Category:Linux Administration]]

{{Exchange Box}}

Container Security Best Practices - Revision history

Admin: New server guide