Skip to content

Latest commit

 

History

History
164 lines (139 loc) · 9.58 KB

mitigations.md

File metadata and controls

164 lines (139 loc) · 9.58 KB

Mitigation Strategies Analysis for basecamp/kamal

Mitigation Strategy: Secure Image Provenance and Integrity (Kamal Hooks & Configuration)

Description:

  1. Implement Image Signing Verification (Kamal Hook):
    • Create a pre-deploy hook in your Kamal configuration (e.g., in config/deploy.yml or a separate script referenced by it).
    • This hook should use docker trust inspect <your-image>:<tag> (or a similar command for your chosen signing mechanism) to verify the image signature before Kamal pulls it.
    • The hook should exit with a non-zero code if the signature is invalid, preventing the deployment. Example (conceptual, needs adaptation): 
      hooks:
  pre-deploy:
    - command: ./scripts/verify_image_signature.sh
      verify_image_signature.sh: 
      #!/bin/bash
IMAGE="$KAMAL_REGISTRY/$KAMAL_IMAGE_NAME:$KAMAL_VERSION"
docker trust inspect "$IMAGE" >/dev/null 2>&1
if [ $? -ne 0 ]; then
  echo "ERROR: Image signature verification failed for $IMAGE"
  exit 1
fi
  2. Configure Registry Authentication (Kamal Configuration):
    • In config/deploy.yml, configure Kamal to authenticate with your private registry using secure credentials. Do not hardcode credentials. Use environment variables that are populated from a secret manager. 
      registry:
  server: your-registry.example.com
  username: <%= ENV['REGISTRY_USERNAME'] %>
  password: <%= ENV['REGISTRY_PASSWORD'] %>

Threats Mitigated:

  • Malicious Image Injection (Severity: Critical): Prevents deployment of tampered images.
  • Use of Untrusted Images (Severity: High): Enforces the use of images from your controlled registry.

Impact:

  • Malicious Image Injection: Risk significantly reduced (near elimination if signing is properly implemented).
  • Use of Untrusted Images: Risk eliminated (if registry access is properly controlled).

Currently Implemented:

  • (Example - Needs to be filled in with your project's specifics): None

Missing Implementation:

  • (Example - Needs to be filled in with your project's specifics):
    • No pre-deploy hook for signature verification.
    • Registry credentials might be hardcoded or insecurely stored.

Mitigation Strategy: Robust Secret Management (Kamal secrets Feature & Environment Variables)

Description:

  1. Use Kamal's secrets Feature:
    • Store sensitive values in a .env file locally (never commit this file).
    • Use kamal envify to create an encrypted .env.enc file: kamal envify > .env.enc.
    • Generate a strong, random KAMAL_KEY and store it securely (e.g., in a secret manager, not in the repository or a local .env file).
    • Use kamal env push to upload the encrypted secrets to the servers: kamal env push.
    • Ensure your application loads environment variables correctly.
  2. External Secret Manager Integration (Environment Variables):
    • If using an external secret manager (Vault, AWS Secrets Manager, etc.), configure your application to retrieve secrets at runtime.
    • Use Kamal's environment variable handling to pass the necessary connection details (e.g., secret manager endpoint, authentication tokens) to your application. Do not hardcode these in config/deploy.yml. Use the <%= ENV['...'] %> syntax. 
      env:
  clear:
    SECRET_MANAGER_ENDPOINT: <%= ENV['SECRET_MANAGER_ENDPOINT'] %>
    SECRET_MANAGER_TOKEN: <%= ENV['SECRET_MANAGER_TOKEN'] %>
  3. Avoid Hardcoding in config/deploy.yml: Ensure no secrets are directly present in your config/deploy.yml file.

Threats Mitigated:

  • Credential Exposure (Severity: Critical): Protects secrets from being exposed in the repository or configuration.
  • Unauthorized Access (Severity: Critical): Prevents unauthorized access based on leaked credentials.

Impact:

  • Credential Exposure: Risk significantly reduced (near elimination with proper use of kamal secrets and a secure KAMAL_KEY storage).
  • Unauthorized Access: Risk significantly reduced (dependent on the security of the secret manager and access controls).

Currently Implemented:

  • (Example): Using kamal envify and kamal env push, but KAMAL_KEY is stored insecurely.

Missing Implementation:

  • (Example):
    • KAMAL_KEY is not stored in a secret manager.
    • Integration with an external secret manager is not implemented.

Mitigation Strategy: Secure Traefik Configuration (Kamal Configuration)

Description:

  1. Verify TLS/SSL Configuration:
    • Ensure Kamal's Let's Encrypt integration is working correctly. Check that your application is accessible via HTTPS and that the certificate is valid.
    • If using custom certificates, configure them correctly in Kamal's config/deploy.yml.
  2. Customize Traefik Middlewares (Kamal Configuration):
    • Use Traefik middlewares to enhance security. This is done within the traefik.options section of your config/deploy.yml. Examples:
      • Rate Limiting: 
        traefik:
  options:
    "traefik.http.middlewares.ratelimit.ratelimit.average": "100"
    "traefik.http.middlewares.ratelimit.ratelimit.burst": "200"
    "traefik.http.middlewares.ratelimit.ratelimit.period": "1s"
    "traefik.http.routers.my-app.middlewares": "ratelimit"
      • Security Headers: 
        traefik:
  options:
    "traefik.http.middlewares.security-headers.headers.stsSeconds": "31536000"
    "traefik.http.middlewares.security-headers.headers.contentTypeNosniff": "true"
    "traefik.http.middlewares.security-headers.headers.frameDeny": "true"
    "traefik.http.routers.my-app.middlewares": "security-headers"
      • Basic Authentication (if needed): 
        traefik:
  options:
    "traefik.http.middlewares.auth.basicauth.users": "user:hashed_password" # Use htpasswd to generate hashed_password
    "traefik.http.routers.my-app.middlewares": "auth"
    • Consult the Traefik documentation for a complete list of available middlewares and their configuration options.

Threats Mitigated:

  • Man-in-the-Middle Attacks (Severity: Critical): TLS/SSL encryption protects against eavesdropping and data tampering.
  • Cross-Site Scripting (XSS) (Severity: High): Security headers (e.g., Content-Security-Policy) can mitigate XSS attacks.
  • Clickjacking (Severity: Medium): The X-Frame-Options header can prevent clickjacking attacks.
  • Brute-Force Attacks (Severity: Medium): Rate limiting can mitigate brute-force attacks against login forms.
  • Unauthorized access (Severity: High): Basic authentication can protect endpoints.

Impact:

  • Man-in-the-Middle Attacks: Risk eliminated (with proper TLS/SSL configuration).
  • XSS, Clickjacking, Brute-Force Attacks: Risk significantly reduced (dependent on the specific middlewares used).

Currently Implemented:

  • (Example): Basic TLS/SSL configuration via Let's Encrypt.

Missing Implementation:

  • (Example):
    • No custom Traefik middlewares are configured.

Mitigation Strategy: Secure Kamal Hooks

Description:

  1. Review and Minimize Hook Logic: Carefully review all custom Kamal hooks for potential security vulnerabilities. Keep the logic as simple and concise as possible. Avoid complex shell scripting within hooks.
  2. Least Privilege: Ensure hooks run with the minimum necessary privileges. If a hook needs to interact with Docker, it should ideally run as the same user that Kamal uses for deployments (which should not be root). Avoid using sudo within hooks unless absolutely necessary.
  3. Avoid Command Injection: Be extremely careful when constructing commands within hooks, especially if they involve user-supplied input (e.g., environment variables). Use proper quoting and escaping to prevent command injection vulnerabilities. Prefer using built-in Kamal variables (like $KAMAL_VERSION) over constructing commands from scratch.

Threats Mitigated:

  • Malicious Hook Execution (Severity: Critical): Prevents attackers from injecting malicious code via hooks.
  • Privilege Escalation (Severity: High): Limits the potential for attackers to gain elevated privileges through hooks.
  • Command Injection (Severity: Critical): Prevents attackers from executing arbitrary commands on the server.

Impact:

  • Malicious Hook Execution: Risk significantly reduced (with careful review and least privilege).
  • Privilege Escalation: Risk reduced (dependent on hook permissions).
  • Command Injection: Risk significantly reduced (with proper input sanitization and escaping).

Currently Implemented:

  • (Example): None

Missing Implementation:

  • (Example):
    • Hooks are not reviewed for security vulnerabilities.
    • Hooks might run with excessive privileges.
    • Potential command injection vulnerabilities might exist in hooks.