Security best practices

SSH hygiene, security groups, RBAC and team invites, integrations, and secrets for dFlow workloads.

Written By Zoro

Last updated 3 days ago

SSH keys

  • Prefer Ed25519 when your servers and policies allow it; keep RSA where you must support older stacks.
  • Store private key material in a password manager or secure vault if you export it from dFlow; anyone with the private key can authenticate as that key on the server.
  • Rotate keys on a schedule or after people leave: create a new key, attach it to Worker Nodes, then remove the old key.
  • Remove keys that are no longer used so the attack surface stays small.

Security groups and cloud access

  • Avoid SSH open to 0.0.0.0/0; scope to office IPs, a VPN CIDR, or bastion patterns your organisation already trusts.
  • Keep outbound rules as tight as practical (for example HTTPS only) unless you know the workload needs wider egress.
  • Use least-privilege IAM for AWS (or other) accounts you link in dFlow; link accounts dedicated to automation rather than personal admin keys when possible.
  • Review groups when you decommission Worker Nodes so stale rules do not linger.

Team, roles, and invites

  • Grant team.update and team.delete only to people who should invite, change roles, or remove members.
  • Use custom roles instead of handing Admin to everyone; start from Read-heavy roles for contractors.
  • Prefer short-lived invite links and avoid posting them in public channels.
  • When someone leaves, remove their Organisation membership and rotate infrastructure secrets they may have seen (SSH, registry tokens, database passwords).

Applications, Services, and secrets

  • Keep environment values that are sensitive behind dFlow’s secrets patterns and avoid logging them in build or runtime logs.
  • Separate production and non-production with different Environments (and different roles or accounts where possible).
  • See Operational best practices under Deployments and Operations in the sidebar for deploy and backup habits.

Self-hosted control plane

If you run the dFlow control plane yourself, protect the host, database backups, and admin URLs the same way you would any production management plane. Dashboard RBAC does not limit someone with shell access to your servers.

Related