Skip to content
Datamotive

Security

IAM

Identity and access management: how Datamotive authenticates users and integrates with cloud IAM systems.

Product
Datamotive Platform
Version
v1.0
Documentation status
Published
Last updated
Updated
Reading time
2 min read

Datamotive has two distinct IAM layers: user authentication (who can log in to the console and API), and cloud IAM (what permissions the data plane components hold in AWS, Azure, and vCenter).

User authentication

Local accounts

The default authentication method. Users are created in the Datamotive console under Settings then Users. Passwords are hashed with bcrypt (cost factor 12). Local accounts support MFA via TOTP (Google Authenticator, Authy, or compatible apps).

SSO (SAML 2.0 and OIDC)

Enterprise deployments connect Datamotive to an existing identity provider (IdP):

  • SAML 2.0: works with Okta, Azure AD (now Entra ID), Google Workspace, and any SAML-compliant IdP
  • OIDC: works with Okta, Auth0, Azure AD, and any OIDC-compliant IdP

SSO configuration is under Settings then Authentication then SSO. After SSO is enabled, new users who authenticate via the IdP are provisioned automatically. Just-in-time (JIT) provisioning assigns users to a default role; role assignments can be overridden manually.

When SSO is enabled, local account login can be restricted to emergency-use-only accounts.

API authentication

API clients authenticate using API keys generated in Settings then API keys. API keys are scoped to a single user identity and inherit that user's RBAC permissions. Keys can be set to expire after 30, 90, or 365 days, or have no expiration.

Cloud IAM

AWS permissions

The Replication Appliance and Cloud Connector need IAM permissions to operate. Datamotive recommends using an IAM role (instance profile for EC2, or a cross-account role) rather than IAM user access keys.

Minimum permissions for the Replication Appliance (source) on AWS:

  • ec2:DescribeInstances, ec2:DescribeVolumes, ec2:DescribeSnapshots
  • ec2:CreateSnapshot, ec2:CopySnapshot, ec2:DeleteSnapshot
  • ec2:CreateTags

Minimum permissions for the Cloud Connector (target) on AWS:

  • ec2:DescribeInstances, ec2:DescribeVolumes
  • ec2:CreateVolume, ec2:AttachVolume, ec2:DetachVolume, ec2:DeleteVolume
  • ec2:CreateSnapshot, ec2:DeleteSnapshot
  • ec2:RunInstances, ec2:StartInstances, ec2:StopInstances, ec2:TerminateInstances
  • s3:GetObject, s3:PutObject, s3:DeleteObject (staging bucket only)
  • kms:GenerateDataKey, kms:Decrypt (if using CMEK)

A CloudFormation template that creates the exact IAM role with minimum required permissions is available in the Datamotive partner portal.

Azure permissions

The Cloud Connector uses a service principal or managed identity:

  • Contributor role on the target resource group (for VM and disk operations)
  • Storage Blob Data Contributor on the staging storage account
  • Key Vault Crypto User on the Key Vault (if using customer-managed keys)

vCenter permissions

See the Prerequisites page for the VMware vCenter permission list.

Related docs

Related articles

Was this page helpful?