mitigations.md

Mitigation Strategies Analysis for docker/compose

Mitigation Strategy: Implement Secret Management using Docker Secrets

Description:

• Step 1: Identify sensitive information (passwords, API keys, database credentials) in your docker-compose.yml or .env files.
• Step 2: Create Docker Secrets using docker secret create for each secret (e.g., echo "secret_value" | docker secret create my_secret -).
• Step 3: Define secrets in the top-level secrets section of your docker-compose.yml:

  secrets:
    my_secret:
      external: true

• Step 4: In services needing secrets, declare them and mount as files:

  services:
    app:
      image: your-app-image
      secrets:
        - my_secret
      environment:
        MY_SECRET_FILE: /run/secrets/my_secret

• Step 5: Update application code to read secrets from mounted file paths (e.g., /run/secrets/my_secret).

Threats Mitigated:

• Exposure of Secrets in Version Control - Severity: High
• Unauthorized Access to Secrets in Configuration Files - Severity: High

Impact:

• Exposure of Secrets in Version Control: High Risk Reduction
• Unauthorized Access to Secrets in Configuration Files: High Risk Reduction

Currently Implemented: Partial - Database passwords in production use external secret management (Vault), but Docker Secrets are not consistently used for other secrets or across all environments.

Missing Implementation:

• Extend Docker Secrets usage to development and staging environments.
• Apply Docker Secrets for API keys, service account credentials, and other sensitive data.
• Standardize secret management across all services defined in docker-compose.yml.

Mitigation Strategy: Apply Least Privilege Principles using user directive

Description:

• Step 1: Determine the least privileged user to run application processes within containers.
• Step 2: Ensure your Dockerfile creates a non-root user and group (if not in base image). Example Dockerfile:

  RUN groupadd -r appuser && useradd -r -g appuser appuser

• Step 3: In docker-compose.yml, use the user directive in each service to specify the non-root user:

  services:
    app:
      image: your-app-image
      user: "appuser:appuser"

• Step 4: Verify file permissions in container images and volumes allow the non-root user access to necessary files and directories.

Threats Mitigated:

• Container Escape and Host Compromise - Severity: High
• Privilege Escalation within Container - Severity: High

Impact:

• Container Escape and Host Compromise: High Risk Reduction
• Privilege Escalation within Container: High Risk Reduction

Currently Implemented: Partial - user directive is used for the main web application container in production, but not consistently for all services in all environments.

Missing Implementation:

• Apply user directive to all services in docker-compose.yml across development, staging, and production.
• Review and adjust file permissions to ensure non-root user functionality for all services.

Mitigation Strategy: Utilize Distinct Compose Networks for Service Isolation

Description:

• Step 1: Define separate networks in the networks section of your docker-compose.yml. Example:

  networks:
    frontend-net:
    backend-net:
    db-net:
      internal: true

• Step 2: Assign services to appropriate networks in their networks section within docker-compose.yml:

  services:
    web:
      image: your-web-app-image
      networks:
        - frontend-net
        - backend-net
    api:
      image: your-api-app-image
      networks:
        - backend-net
        - db-net
    db:
      image: db-image
      networks:
        - db-net

• Step 3: Design network architecture to restrict inter-service communication to necessary paths, enhancing isolation.

Threats Mitigated:

• Lateral Movement within Compose Environment - Severity: Medium
• Network-based Attacks between Containers - Severity: Medium

Impact:

• Lateral Movement within Compose Environment: Medium Risk Reduction
• Network-based Attacks between Containers: Medium Risk Reduction

Currently Implemented: Yes - Distinct networks are defined in production and staging docker-compose.yml to separate tiers (frontend, backend, database).

Missing Implementation:

• Consistently use network segmentation in development environments.
• Document the intended network architecture and service communication flows.

Mitigation Strategy: Implement Resource Limits in Compose

Description:

• Step 1: Analyze resource requirements (CPU, memory) for each service in your Compose application.
• Step 2: In docker-compose.yml, use resource limit directives (cpu_limit, mem_limit, memswap_limit) within each service definition to constrain resource usage. Example:

  services:
    app:
      image: your-app-image
      deploy:
        resources:
          limits:
            cpus: '0.5'
            memory: 512M

• Step 3: Test resource limits in staging to ensure application stability and performance within defined boundaries.
• Step 4: Monitor resource usage in production to detect and address potential resource exhaustion issues.

Threats Mitigated:

• Denial of Service due to Resource Exhaustion - Severity: Medium
• Resource Starvation of Other Services - Severity: Medium

Impact:

• Denial of Service due to Resource Exhaustion: Medium Risk Reduction
• Resource Starvation of Other Services: Medium Risk Reduction

Currently Implemented: Partial - Resource limits are defined for some services in production docker-compose.yml, but not comprehensively applied to all services or environments.

Missing Implementation:

• Define and apply resource limits consistently to all services in docker-compose.yml across all environments.
• Regularly review and adjust resource limits based on performance monitoring and application needs.

Mitigation Strategy: Apply Security Context at Runtime using security_opt and privileged

Description:

• Step 1: Identify necessary security capabilities and constraints for each service.
• Step 2: In docker-compose.yml, use the security_opt directive to configure security settings like seccomp profiles and apparmor profiles. Example:

  services:
    app:
      image: your-app-image
      security_opt:
        - seccomp:unconfined # Example - use a specific profile instead of unconfined in production

• Step 3: Carefully consider and avoid using privileged: true unless absolutely necessary. If required, document the justification and security implications.
• Step 4: For capability management, use cap_drop to remove unnecessary capabilities and cap_add to grant only essential capabilities. Example:

  services:
    app:
      image: your-app-image
      cap_drop:
        - ALL
      cap_add:
        - NET_BIND_SERVICE

• Step 5: Test security context configurations in staging to ensure application functionality is not broken by restrictions.

Threats Mitigated:

• Container Escape and Host Compromise - Severity: High
• Privilege Escalation within Container - Severity: High
• Reduced Attack Surface - Severity: Medium

Impact:

• Container Escape and Host Compromise: High Risk Reduction
• Privilege Escalation within Container: High Risk Reduction
• Reduced Attack Surface: Medium Risk Reduction

Currently Implemented: Partial - security_opt and cap_drop/cap_add are not systematically used across all services in docker-compose.yml. privileged: true is avoided in production.

Missing Implementation:

• Implement security_opt (specifically seccomp and apparmor profiles) for relevant services in docker-compose.yml.
• Consistently apply cap_drop to remove ALL capabilities and selectively add only necessary ones.
• Conduct a security review to identify optimal security context configurations for each service.

Mitigation Strategy: Secure Compose File Management and Image Sources

Description:

• Step 1: Store docker-compose.yml files in version control (e.g., Git) to track changes and enable rollback.
• Step 2: Implement access control for the repository containing docker-compose.yml files, limiting access to authorized personnel.
• Step 3: Utilize trusted and reputable image registries for pulling container images defined in docker-compose.yml. Prefer official images or verified publishers.
• Step 4: For internal images, use a private registry with access control to manage and distribute trusted images within the organization.
• Step 5: Consider using Docker Content Trust (DCT) to verify image integrity and publisher authenticity when pulling images in Compose.

Threats Mitigated:

• Unauthorized Modification of Compose Configuration - Severity: Medium
• Use of Malicious or Vulnerable Images - Severity: High
• Supply Chain Attacks via Compromised Images - Severity: Medium

Impact:

• Unauthorized Modification of Compose Configuration: Medium Risk Reduction
• Use of Malicious or Vulnerable Images: High Risk Reduction
• Supply Chain Attacks via Compromised Images: Medium Risk Reduction

Currently Implemented: Yes - docker-compose.yml files are version controlled and stored in private repositories with access control. Private registry is used for internal images.

Missing Implementation:

• Enforce Docker Content Trust (DCT) for image pulls in Compose environments.
• Regularly audit and review access control for docker-compose.yml repositories and image registries.
• Establish a process for verifying the integrity and security of third-party images used in Compose applications.