Cloud provider accounts

How linked cloud accounts relate to Organisations, AWS today, and least-privilege habits for infrastructure integrations.

Written By Zoro

Last updated 9 days ago

Cloud provider accounts are credentials dFlow stores so the control plane can call provider APIs on your behalf. Today Azure and AWS are the supported cloud providers for Worker Node provisioning in the product UI. Google Cloud Platform and DigitalOcean may appear as Coming soon.

Task steps live in Azure integration and AWS integration under Integrations in the sidebar. This page explains how those accounts fit Organisations, Environments, and security expectations.

What a linked account is used for

Linked accounts typically enable:

  • Creating or managing compute (for example Azure VMs or EC2 instances used as Worker Nodes).

  • Reading regions, resource groups, virtual networks, subnets, or firewall rules when the dashboard needs them for provisioning.

They do not replace Git, Docker registry, or Backup Storage credentials. Those are separate integrations under Integrations overview.

Organisation scope

Connections are stored at the Organisation (tenant) level. Any member who can open Integrations and see secrets depends on Roles and permissions under Security and Team Management in the sidebar and the Tenant access model under Security and Team Management in the sidebar.

Use separate cloud accounts or separate principals per Environment (production vs staging) when your compliance policy requires hard separation. Name connections clearly in dFlow so operators pick the right one.

Least privilege and rotation

AWS

  • Create a dedicated IAM user or role per integration; avoid reusing personal admin keys.

  • Attach the minimum IAM policy that still allows the EC2 (and related) actions the UI performs.

  • Rotate access keys on a schedule and immediately if a key leaks. Update dFlow before deleting the old key in AWS.

Azure

  • Sign in with an identity scoped to the subscriptions and resource groups dFlow should touch; avoid subscription-wide Owner unless your policy requires it.

  • dFlow uses OAuth tokens refreshed automatically. Reconnect the account after role changes or if the integration shows Disconnected.

  • Removing an Azure account in dFlow does not delete VMs already created in your subscription.

See Security best practices under Security and Team Management in the sidebar and Integration permissions and prerequisites.

Network and access layers

Cloud API credentials are not the same as:

  • SSH keys for self-hosted Worker Nodes (SSH keys under Security and Team Management in the sidebar). Azure workers can use SSH keys stored in Azure during provisioning.

  • Security groups (AWS) and network security groups (Azure). AWS groups are managed under Security in dFlow; Azure NSGs are chosen or created when you add an Azure worker.

You need both a healthy cloud account link and correct network paths for provisioned servers to register and run Services.