Cloud provider accounts
How linked cloud accounts relate to Organisations, AWS and Azure, and least-privilege habits for infrastructure integrations.
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.
Related
Azure integration
Connect your Azure subscription with Microsoft sign-in so dFlow can provision and manage Worker Nodes in your account.
Integration permissions and prerequisites
Checklist of provider scopes, IAM and Azure RBAC patterns, and Organisation roles before you connect Git, registries, backup storage, or cloud providers.