This document explains the end-to-end CloudFormation onboarding flow, the IAM model created by the template, why each major permission set exists, what each permission category enables, and what breaks if a permission is removed. It is intended as a customer-facing technical reference for security reviews, architecture discussions, and least-privilege planning.

Scope

This page covers the CloudRanger-style AWS onboarding template model reflected in internal references for dynamic CloudFormation template generation, feature-based permission selection, orchestration/data-plane role separation, EC2/EBS, RDS, S3 air-gap, EFS, DynamoDB, Redshift, EKS, Auto Scaling, VSS/SSM-based scripting, and ADR-style network clone capabilities.

Important note on scope and wildcards

Some AWS actions do not support useful resource-level scoping, some resources do not exist at stack-deploy time, and some workflows create temporary resources dynamically during restore, ADR clone, or helper execution. That is the main reason wildcards appear in some policy statements.

Executive Summary

The CloudFormation template creates AWS roles and policies that let Druva CloudRanger discover resources, orchestrate backups, perform restores, run optional helper workflows, and clean up temporary artifacts. The template is designed to support multiple workload families from one onboarding flow, which is why customers often see more permissions than are required for a single narrow use case.

Control plane permissions are used to discover resources, schedule work, coordinate backups, launch restores, create helper resources, and manage metadata.
Data plane permissions are used to move snapshot data, especially for EBS Direct API workflows and air-gapped restore paths.
Delete permissions usually exist for retention enforcement, failed-job rollback, restore cleanup, ADR teardown, or temporary helper cleanup.
Wildcard resources are typically used where AWS APIs are list/describe oriented, where the target resource is selected at runtime, or where restore targets are not known when the stack is deployed.
Least privilege is possible by disabling unused feature blocks, narrowing KMS keys, constraining bucket prefixes, pre-creating helper roles, and removing ADR/networking permissions if clone or DR testing is not used.

Architecture

The template follows a split-role model. A main orchestration role is assumed by Druva services to manage workflows in the customer AWS account. Separate helper or worker roles are used for special operations such as EBS Direct APIs, VSS/script execution, S3 air-gap workflows, and EFS backup workers.

Component	Purpose	Typical Plane
Orchestration role	Discovery, policy execution, backup orchestration, restore orchestration, feature control	Control plane
EC2 data role	EBS Direct API backup and restore block movement	Data plane
S3 air-gap role	S3 backup and restore operations for air-gapped workflows	Data plane
VSS / script helper role	Application-consistent snapshots and SSM-driven scripts	Helper
EFS worker role	Ephemeral EC2-based EFS backup workflow	Helper

At a high level, the flow is: Druva assumes the orchestration role, discovers resources, creates or coordinates snapshots, optionally copies or archives them, may move data to Druva cloud storage, and later restores data by creating snapshots, volumes, images, instances, databases, or objects back into the customer account.

Trust Relationships

The security boundary begins with the trust policy on the customer-side IAM roles.

Primary cross-account trust: allows the Druva service principal or Druva-owned AWS role to call sts:AssumeRole on the customer orchestration role.
External ID condition: used to reduce confused-deputy risk and bind the trust relationship to the intended customer organization.
Service trust: helper roles for EC2 or Lambda are assumed by AWS services such as ec2.amazonaws.com or lambda.amazonaws.com.
Scoped pass-role pattern: where possible, orchestration permissions pass only specific helper roles to EC2.

Why trust relationships matter
If the trust relationship is missing or the external ID does not match, backups and restores cannot start because Druva cannot assume the customer role.

IAM Design Principles

Separation of duties: orchestration and data movement are split into different roles.
Feature-based permission grouping: EC2, RDS, S3, DynamoDB, ADR, and helper workflows are grouped so they can be selectively included.
Runtime targeting: many restore targets are created only when a job runs, so exact ARNs are not always known in advance.
Cleanup is part of the workflow: delete permissions often exist to remove temporary artifacts or expired recovery points.
AWS API limitations shape policy design: many Describe*, List*, and some service operations are effectively account-wide.

CloudFormation Deployment Steps

Generate or download the template
The template can be generated dynamically based on selected feature options. This determines which policy blocks are included.
Create the CloudFormation stack in the target AWS account
The stack creates roles, policies, instance profiles, and any feature-specific supporting resources defined by the template.
Acknowledge IAM resource creation
This is required because the stack creates named IAM resources.
Wait for stack completion
If the stack fails, usually an IAM permission, naming conflict, or trust-policy condition is incorrect.
Complete application-side onboarding
The created role ARN is registered in the Druva platform so the account can be discovered and protected.
Validate access
Druva attempts to assume the orchestration role and run basic discovery APIs.
Enable only required features
Optional blocks such as ADR, Redshift, DynamoDB, EKS, or VSS/script workflows should only be enabled if needed.

Step	Why required	What it does
Template generation	Matches permissions to enabled features	Produces a workload-specific stack definition
Stack creation	Bootstraps customer-side AWS roles	Creates IAM roles, policies, and profiles
Role registration	Connects AWS account to Druva control plane	Stores the role ARN for future assume-role operations
Verification	Confirms trust and minimum access	Runs assume-role and discovery checks

CloudFormation Resources

The exact resource count varies by template version and selected feature options, but commonly includes:

IAM orchestration role
IAM data role for EC2/EBS direct operations
S3 air-gap role
Managed policies for VSS, FLS, archive upload, EFS discovery, and EFS backup
Instance profiles for helper EC2-based workflows
Optional buckets or helper configuration resources for file-level search or staging flows

Control Plane vs Data Plane

Area	Examples	Why it exists
Control plane	Describe, create snapshots, restore instances, modify tags, schedule start/stop, attach helper roles	Coordinates workflows and creates logical recovery artifacts
Data plane	`ebs:StartSnapshot`, `ebs:PutSnapshotBlock`, `ebs:GetSnapshotBlock`	Moves actual protected block data during backup or restore
Helper execution plane	SSM scripts, VSS actions, EFS mount/read, S3 archive upload	Runs specialized actions inside customer compute context

Permission Reference by Service

KMS permissions

Typical permissions: kms:Decrypt, kms:Encrypt, kms:GenerateDataKey*, kms:ReEncrypt*, kms:CreateGrant, kms:RevokeGrant, kms:DescribeKey, kms:ListAliases, kms:ListKeys.
Why they exist: to back up and restore encrypted EBS snapshots, AMIs, RDS snapshots, S3 objects, and EFS or helper workflows that interact with encrypted resources.
What they do: allow AWS services or helper processes to use customer-managed keys while preserving encryption posture.
What breaks if removed: encrypted backup, copy, or restore operations fail; cross-account and cross-region restore flows may fail because grants cannot be created.
Why wildcard is common: the relevant KMS key often depends on the resource selected for backup or restore at runtime.

EC2 permissions

Typical permissions: snapshot/image creation, volume creation, instance launch, attach/detach, tagging, copy, archive tier actions, recycle bin actions, networking helper actions, and instance profile association actions.
Why they exist: EC2 protection relies on creating snapshots or AMIs, then restoring volumes, images, or instances from them.
What they do: create recovery points, copy them, launch restored instances, apply tags, and manage temporary helper infrastructure.
What breaks if removed: no EC2 snapshots, no AMI restore, no volume restore, no instance restore, no copy/archive/recycle-bin support, or no VSS/script automation.

IAM permissions

Typical permissions: iam:PassRole, iam:GetRole, iam:GetInstanceProfile, iam:ListInstanceProfiles, iam:AddRoleToInstanceProfile, iam:RemoveRoleFromInstanceProfile, iam:AttachRolePolicy.
Why they exist: to attach helper instance profiles for VSS/script workflows and to preserve or reapply IAM profiles when restoring EC2 instances.
What they do: allow temporary or restored EC2 instances to use the expected role.
What breaks if removed: VSS consistent snapshots may not work, script execution may fail, and restored instances may come up without their expected IAM role.
Security note: recent internal discussion shows customer concern especially around iam:AttachRolePolicy; template scoping and feature-based removal are key mitigations.

SSM permissions

Typical permissions: ssm:SendCommand, ssm:GetCommandInvocation, ssm:DescribeInstanceInformation, ssm:ListDocuments, ssm:GetDocument, ssm:PutParameter, ssm:GetParameter, ssm:DeleteParameter.
Why they exist: for VSS/application-consistent scripts, helper execution, and temporary parameter storage for workflow state or credentials.
What they do: execute in-guest commands and store short-lived coordination data.
What breaks if removed: VSS/script execution fails; some Druva Cloud or helper credential flows fail; cleanup of temporary parameters may fail.

EBS Direct APIs

Typical permissions: ebs:StartSnapshot, ebs:PutSnapshotBlock, ebs:CompleteSnapshot, ebs:ListSnapshotBlocks, ebs:ListChangedBlocks, ebs:GetSnapshotBlock.
Why they exist: for block-level backup and restore workflows, especially air-gapped or Druva-cloud-backed restore paths.
What they do: read and write snapshot blocks directly.
What breaks if removed: EC2 block-level backup and restore fails.

RDS

Typical permissions: describe, snapshot create/delete, copy, restore, create/delete instance and cluster, parameter groups, option groups, subnet groups, security groups.
Why they exist: to discover, protect, restore, and clean up RDS/Aurora resources.
What breaks if removed: RDS discovery, snapshot retention cleanup, snapshot restore, and advanced restore configuration fail.

DynamoDB

Typical permissions: backup create/delete, restore, table create, replica create, get/query/scan, batch write, update item, delete item, tag and untag.
Why they exist: to create backups, restore tables, and reconcile restored data.
What breaks if removed: DynamoDB backup or restore workflows fail.

Redshift

Typical permissions: describe clusters and snapshots, create snapshot, delete snapshot, authorize snapshot access, revoke snapshot access, copy cluster snapshot, tag management.
Why they exist: Redshift snapshot protection and restore access workflows.
What breaks if removed: Redshift backup, snapshot sharing, and restore-related flows fail.

EKS

Typical permissions: eks:ListClusters, eks:DescribeCluster, eks:ListTagsForResource, eks:TagResource, eks:UnTagResource.
Why they exist: cluster discovery and metadata management for Kubernetes-related features.
What breaks if removed: EKS clusters may not be discovered or managed correctly.

Auto Scaling

Typical permissions: autoscaling:DescribeAutoScalingGroups, autoscaling:UpdateAutoScalingGroup.
Why they exist: scheduling and orchestration for ASG-related workflows.
What breaks if removed: ASG resize or scheduling support fails.

CloudWatch

Typical permissions: cloudwatch:GetMetricStatistics, cloudwatch:ListMetrics.
Why they exist: telemetry, discovery enhancement, and some S3 or workload reporting flows.
What breaks if removed: health, metrics, or some workload analysis views may be incomplete.

CloudFormation

Typical permissions: cloudformation:CreateStack, UpdateStack, DeleteStack, DescribeStacks, DescribeStackEvents, ListStackResources.
Why they exist: mostly for ADR clone workflows and CloudFormation-driven network cloning.
What breaks if removed: ADR clone generation, clone deployment, sync-clone teardown, and some DR testing flows fail.

S3 and Air-Gap

Typical permissions: bucket create/configure, object get/put/delete, versioning, encryption, restore object, lock and tagging reads, bucket posture reads.
Why they exist: to manage Druva-controlled buckets or air-gap restore targets and to read protected S3 objects.
What breaks if removed: S3 backup, S3 restore, archive staging, cleanup, and retention management fail.

ADR / Network Clone permissions

This is the most security-sensitive optional area because it may include VPC, subnet, route table, NAT gateway, IGW, NACL, security group, address, and CloudFormation stack lifecycle permissions.

Why they exist: to clone a network environment for automated disaster recovery testing or environment clone workflows.
What they do: create cloned network infrastructure, then tear it down later.
What breaks if removed: ADR create clone, sync clone, and DR test teardown fail. Regular backup and restore into an existing subnet can still work if ADR is not required.

Customer concern area
Wildcard delete permissions are most commonly questioned in ADR-related blocks because the resources are created dynamically and must later be deleted dynamically.

Why Each Permission Exists

At a practical level, permissions exist for one of five reasons:

Discovery and inventory
Backup creation
Restore creation
Helper execution for consistency or data movement
Cleanup and retention enforcement

If a permission cannot be mapped to one of those functions, it is a candidate for review and removal in a hardened template.

What Breaks if Permissions Are Removed

Permission area	Likely impact if removed
KMS grant / encrypt / decrypt	Encrypted backup and restore fail
EC2 snapshot create/delete	Backup or retention cleanup fails
EC2 run/create volume/register image	Restore fails
IAM pass role / attach helper policy	VSS/script workflows or restored IAM profile handling fail
SSM send command / parameter access	In-guest consistency and helper state management fail
EBS Direct APIs	Block-level restore fails
CloudFormation / VPC clone actions	ADR clone workflows fail
S3 delete object/version	Retention cleanup and restore cleanup fail
RDS delete snapshot / delete temp instance	RDS retention or restore cleanup fail

Feature-to-Permission Matrix

Feature	Main services used	Key permission families
EC2 snapshots	EC2, KMS, Tagging	CreateSnapshot, CreateImage, Describe*, CreateTags, KMS encrypt/decrypt
EC2 restore	EC2, IAM, KMS	CreateVolume, RunInstances, RegisterImage, PassRole, AttachVolume
VSS / scripts	SSM, IAM, EC2	SendCommand, AssociateIamInstanceProfile, AttachRolePolicy
RDS protection	RDS, KMS	CreateDBSnapshot, RestoreDBInstance, DeleteDBSnapshot
S3 air-gap	S3, KMS, CloudWatch	GetObject, PutObject, DeleteObject, CreateGrant
EFS backup	EC2, EFS, IAM, SSM, S3	RunInstances, ClientMount, PassRole, Put/Get/DeleteParameter
ADR clone	EC2, CloudFormation	CreateVpc, CreateSubnet, CreateRoute, DeleteStack, DeleteVpc

Least-Privilege Guidance

Disable unused feature blocks during template generation.
Remove ADR permissions if no clone or DR network replication is required.
Scope iam:PassRole to named helper roles only.
Scope S3 permissions to specific prefixes or buckets where supported.
Scope KMS permissions to approved CMK ARNs where operationally feasible.
Use tag-based constraints for clone-created resources where supported.
Pre-provision helper roles manually if the customer does not want the template to modify instance profiles at runtime.

Security Review Questionnaire

Which workloads are actually in scope: EC2, RDS, S3, EFS, DynamoDB, Redshift, EKS?
Is ADR / clone functionality required, or only restore into an existing VPC?
Are VSS or application-consistent scripts required for Windows workloads?
Should restored EC2 instances inherit their original IAM instance profile automatically?
Are customer-managed KMS keys used, and can key ARNs be predeclared?
Are tag-based guardrails required for create/delete operations?
Do S3 permissions need to be limited to named buckets?
Is the customer comfortable with helper roles being created by the template, or should they be pre-created manually?

Compliance and Security Mappings

This template design aligns most directly to identity control, least privilege, encryption, change management, logging, and separation-of-duties review themes commonly assessed in security programs.

AWS Well-Architected Security Pillar: least privilege, secure key management, logging, automation, and reduced attack surface are directly relevant.
CIS-style expectations: customer reviews typically focus on wildcard resources, key scoping, role trust restrictions, and logging of sensitive IAM activity.
SOC 2 / ISO 27001 themes: access control, change control, encryption management, role review, and auditability are the most relevant control topics.

Druva compliance context
Internal security references indicate Druva maintains security and compliance programs including SOC 2 and ISO 27001 for relevant cloud services, and internal materials also reference AWS Well-Architected security practices and broader GRC control mapping.

Architecture Diagrams

Recommended diagrams for the published version of this page:

High-level onboarding and assume-role sequence
Control plane vs data plane split
EC2 backup and EBS Direct API restore flow
RDS snapshot and restore flow
S3 air-gap flow
EFS ephemeral worker flow
ADR clone workflow with create and teardown stages

AWS Documentation References

Appendices

Appendix A: Why wildcards are used

AWS action does not support fine-grained resource scoping
Target resource is chosen at runtime
Resource does not yet exist at deployment time
Temporary restore or clone resources are created and later deleted dynamically

Appendix B: Common customer concerns and direct answers

Why do you need delete permissions? For retention cleanup, failed-job rollback, restore cleanup, and ADR teardown.
Why not specify exact names? Many resources are created only during restore or clone execution, so the exact names are not known when the stack is deployed.
Can unused workloads be removed? Yes. Internal design references show the template supports feature-based permission selection.
Can discovery, backup, and restore be separated? Partially yes; the design already separates orchestration and EC2 data roles, and further hardening is possible in custom deployments.

Appendix C: Internal-source-backed observations reflected here

Feature-based template generation and permission grouping are documented in internal CloudFormation template design materials.
Template options explicitly map permissions to features such as snapshots, restore, scripts, FLS, air-gap, RDS, Redshift, DynamoDB, and ADR.
Internal permission review pages confirm active use of EBS Direct APIs and the existence of broader optional policy blocks.
Recent customer escalations specifically highlight concern around wildcard IAM and ADR delete permissions, validating the need for this reference page.

CloudFormation Template Permissions and Deployment Reference