Skip to content

Security

This page defines a practical security baseline for MeshFlows Engine deployments.

Security Boundaries

  • Edge/API boundary: Gateway as the primary external entrypoint.
  • Internal service boundary: cluster-internal service-to-service communication.
  • Data boundary: storage and secret persistence layers.
  • Operations boundary: admin and internal endpoints.

Authentication and Authorization

  • Prefer OAuth2/JWT-based invocation control for workflow execution.
  • Use scoped tokens and least-privilege role models.
  • Protect admin endpoints (/admin/*, /internal/*) with dedicated controls.
  • Restrict schedule invocation with explicit token or JWT policy.

Secrets Handling

  • Store sensitive values in secret stores, not in workflow files.
  • Use connection secret references and runtime secret resolution.
  • Rotate credentials and signing keys regularly.
  • Mask secret headers/values in logs and traces.

Network and Exposure Controls

  • Expose only required public routes (normally Gateway).
  • Keep Orchestrator, Storage, Scheduler, and internal endpoints private.
  • Apply Kubernetes network policies between namespaces/services.
  • Prefer TLS for ingress and broker connections.

Egress SSH/SFTP Allowlist

The egress-ssh service enforces an allowlist for outbound SSH/SFTP targets. You can manage it via environment variables or via the Dashboard Settings panel (global runtime config).

Example global runtime config (Dashboard → Admin → Settings → Global):

{
  "egress": {
    "ssh": {
      "allowed_hosts": ["sftp.example.com", "10.0.0.5"],
      "allow_unrestricted": false
    }
  }
}
  • allowed_hosts can be a list or a comma-separated string.
  • allow_unrestricted: true temporarily disables the allowlist and host key checks.
  • For dashboard-driven settings, egress-ssh must have STORAGE_SERVICE_URL and a read token (SSH_EGRESS_CONFIG_READ_TOKEN, typically the same value as STORAGE_SERVICE_READ_TOKEN).

Egress SSH known_hosts (Host Key Verification)

Host key verification can be managed via the Dashboard Settings panel using egress.ssh.known_hosts. This is useful to avoid the "not found in known_hosts" error when connecting to new SSH/SFTP servers.

Example (YAML format or multiline string in JSON):

egress:
  ssh:
    known_hosts: |
      example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA...
      github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMq9N8IMPrW8NzsvxQHfS1BY29lpS2WCgAt14mULv49
  • Generate entries with ssh-keyscan -H <host>.
  • You can also provide a list of lines instead of a single string.
  • If ssh-keyscan returns no output, fetch the key by connecting once and then read it from your local known_hosts:
  • ssh <host> (accept the fingerprint)
  • ssh-keygen -F <host> to print the exact line to copy

Egress HTTP Allowlist

The egress-http service enforces an allowlist for outbound HTTP hosts. You can manage it via environment variables or via the Dashboard Settings panel.

Example global runtime config:

{
  "egress": {
    "http": {
      "allowed_hosts": ["api.example.com", "httpbin.org"],
      "allow_unrestricted": false
    }
  }
}
  • allowed_hosts can be a list or a comma-separated string.
  • allow_unrestricted: true temporarily disables the allowlist.
  • Requires STORAGE_SERVICE_URL and a read token (HTTP_EGRESS_CONFIG_READ_TOKEN).

Egress FTP/FTPS Allowlist

The egress-ftp service enforces an allowlist for outbound FTP/FTPS hosts. You can manage it via environment variables or via the Dashboard Settings panel.

Example global runtime config:

{
  "egress": {
    "ftp": {
      "allowed_hosts": ["ftp.example.com"],
      "allow_unrestricted": false
    }
  }
}
  • allowed_hosts can be a list or a comma-separated string.
  • allow_unrestricted: true temporarily disables the allowlist.
  • Requires STORAGE_SERVICE_URL and a read token (FTP_EGRESS_CONFIG_READ_TOKEN).

Runtime Hardening

  • Use immutable images and pinned versions where possible.
  • Enforce non-root containers and minimal permissions.
  • Limit pod/service account privileges.
  • Enable resource requests/limits to reduce blast radius.

Operational Security Practices

  • Enable audit trails for workflow invocation and admin actions.
  • Monitor auth failures, unusual request patterns, and secret access events.
  • Run regular dependency and image vulnerability scans.
  • Validate workflows before activation and gate deploys with CI checks.