Privileged in Docker Compose with Code Examples

Docker compose allows easily configuring and running multi-service docker applications. A key compose feature is supporting privileged mode for containers – giving extended permissions compared to regular containers.

This guide explains privileged mode, why it‘s used, provides comprehensive examples, analyzes security considerations, and offers expert best practices.

Why Use Privileged Mode

By default, docker restricts containers from accessing sensitive host resources like devices, network stacks, filesystems and kernel capabilities. This enforces security boundaries between containers and hosts.

However, privileged mode mostly disables these restrictions with fine-grained control. Benefits include:

Performance

• Access specialized hardware like GPUs for hardware acceleration. Nvidia tests show up to 113x faster deep learning training versus non-GPU hosts.

• Leverage faster storage devices and advanced kernel features. Database benchmark tests measured 30% reduced query latency for privileged containers.

Functionality

• Use linux capabilities like network traffic control and advanced system tracing
• Support kernel modules for hardware drivers and platform integrations
• Analyze host processes to debug container performance issues

Note privileged containers are still namespaced and firewall protected. So they don‘t provide full host access, but are a midpoint between regular containers and virtual machines.

Enabling Privileged Mode in Compose

Specify the privileged flag under container service definitions:

version: "3.7"  

services:

  webapp:
    image: my_webapp:latest  
    privileged: true

This runs the webapp container in privileged mode.

You can also grant fine-grained privileges using capabilities for what you need rather than full access.

Now let‘s walk through some advanced privileged mode use cases.

Accessing GPU Hardware Acceleration

Hardware acceleration using GPUs or specialist processors can dramatically improve performance for intensive workloads like machine learning.

Here is an example docker compose config running TensorFlow Serving in privileged mode for GPU access:

version: "3.7"

services:

  tfserving:
    image: tensorflow/serving:latest-gpu 
    privileged: true
    volumes:
      - /dev:/dev
    environment: 
      - NVIDIA_VISIBLE_DEVICES=all  

Breaking this down:

• privileged: true permits access to host devices
• /dev volume mounts GPU and other devices
• NVIDIA_VISIBLE_DEVICES enables GPU detection

TensorFlow models running in this container can now leverage GPUs for accelerated matrix math and parallel processing.

Benchmarks show GPUs provide up to 113x lower inference latency versus CPU-only hosts. This performance gain fuels fields like real-time video analysis and autonomous vehicle object detection.

Configuring Extended Network Policies

Containers have basic network stacks enabling host network access by default. However privileged mode allows configuring advanced network policies.

For example, the NET_ADMIN capability permits manipulating host firewall rules, traffic shaping, and other policies. Here is an Nginx proxy instance with extended network control:

services:

  proxy:
    image: nginx:latest
    privileged: true 
    cap_add:
      - NET_ADMIN

Now Nginx can configure iptables firewall policies or use tc qdisc for traffic control on physical host network interfaces. This also applies to other containers sharing those interfaces.

Advanced networking vastly expands policy options – but without care reduces security isolation between containers and hosts.

Debugging Performance via Host Process Metrics

Privileged mode grants access to view and interact with host processes – very useful when debugging container performance issues.

Monitoring tools like top, ps, and strace provide system-wide visibility to help identify noisy neighbor processes interfering with container workloads:

$ docker exec -it <myapp> ps aux
$ docker exec -it <myapp> top
$ docker exec -it <myapp> strace -p <pid>  

Metrics like CPU, memory, IO and syscall tracing reveal if host processes are blocking container resources – without needing to run monitoring agents on the host itself.

These debug techniques help optimize densities for running massively parallel workloads.

Control Groups (cgroups) Isolation

Containers rely on kernel control groups (cgroups) for resource allocation.

Privileged mode allows manipulating container cgroup policies at runtime:

# Limit CPU shares for a container
$ docker exec -it <myapp> cgset -r cpu.shares=512 myapp

So resources can be restricted based on real-time production load.

However, directly modifying cgroups bypasses docker management so isn‘t generally recommended by Docker. Solutions like Kubernetes provide higher-level abstractions for dynamic resource allocation.

Using Linux Security Modules

Privileged containers can also load Linux Security Modules (LSMs) to reinforce security isolation. Popular LSMs include:

SELinux – Mandatory access control policies severely restricting container actions

Seccomp – Filters permitted syscalls to minimize kernel attack surface

For example:

# Load and configure Seccomp inside a container 
$ docker exec -it <myapp> 
  seccomp-tools get conf > seccomp.json 
$ echo ‘{"default_action": "SCMP_ACT_ERRNO"}‘ >> seccomp.json
$ seccompctl load seccomp.json

This configures Seccomp to deny all syscalls by default within the container – whitelising those explicitly needed.

So LSMs like SELinux and Seccomp combined with privileged mode provide policy-driven security hardening.

Storage and Volume Access

Storage is a common resource needing privileged access:

• Optimizing filesystem performance for databases
• Directly accessing block devices like SAN volumes
• Mounting storage volumes
• Managing volume quotas

For example, an application may need to mount external SAN storage. Privileged mode permits this level of volume administration:

$ docker exec -it <myapp> mount /dev/sdb1 /mnt
$ docker exec -it <myapp> mkfs.ext4 /dev/sdc1

So privileged storage access enables critical performance and management functionality in data-driven systems.

Comparing Isolation Approaches

There are several techniques to isolate Linux applications with differing levels of privilege and security:

Isolation Method	Performance	Security	Complexity	Use Cases
Privileged Containers	High	Medium	Low	Trusted apps needing access specialized hardware
Unprivileged Containers	Medium	High	Low	Default for cloud native applications
Virtual Machines	High	High	High	Strictly isolated services with custom kernels

Key takeaways:

• Privileged containers provide a midway point – faster than VMs with moderate attack surface reduction versus hosts

• They strike a balance between performance and security

• Complexity remains low using docker tooling versus virtualization

So evaluate if privileged docker services fulfill your use case need without necessitating the overhead of virtualization or sacrificing security.

Security Considerations for Privileged Containers

Granting containers increased privileges reduces isolation from vulnerable host kernels and privileged processes. Some risks include:

• Access to decryption keys, sensitive mounts or sockets
• Kernel exploits escalating to compromise other containers or hosts
• Denial-of-service from excessive resource consumption
• Container breakout to gain persistent access if not ephemeral

These underline privileged containers are still risky and not suitable for fully untrusted workloads.

Some best practices suggest:

• Avoid blanket privileged mode in favor of granular capabilities
• Perform extensive auditing and penetration testing
• Extend security monitoring to container internal events
• Rebuild containers frequently and avoid persistent volumes
• Adopt principle of least privilege even inside containers

Ultimately you must balance functionality against security risks for your environment and risk appetite.

Conclusion

Privileged docker extensions like accelerated ML inferencing, advanced networking and storage integrations deliver tangible value.

But with great power comes increased responsibility. Privileged mode grants containers extensive (though not absolute) host access. So risks around vulnerabilities must be weighed against the benefits.

Here are some closing expert recommendations:

• Scrutinize if you actually require privileged mode or could simplify your architecture
• Prefer granting specific capabilities rather than full access where possible
• For production, limit to trusted container images from reputable bases like Distroless
• Architecture systems expecting and resilient to some container compromise
• Institute controls like read-only containers, resource quotas and image scanning to reduce blast radius
• Monitor container events, network traffic and user access for suspicious activity
• Prep incident response plans for container breaches

Overall, privileged docker opens integration opportunities but demands proportionally increased vigilance to operate securely at scale. Yet done diligently, provides a compelling balance of performance and security.

I hope reviewing pros, cons and best practices helps determine if privileged compose services could benefit your docker applications. Let me know if you have any other questions!