[Feature Request]: Allow users to opt-out of IAM permission management when providing existing execution role

[mknoth197]

Problem:

The modules/ecs_fargate/iam.tf currently assumes that any user-provided execution role lacks the necessary permissions to access Datadog API key secrets. When both execution_role and dd_api_key_secret are provided, the module unconditionally creates and attaches a new IAM policy for secretsmanager:GetSecretValue permissions.

Why This Is Problematic

1. Redundant IAM Resources: Organizations with centralized IAM management may already have these permissions configured. This creates unnecessary policy proliferation.

2. No Opt-Out Mechanism: There's no way to tell the module "I've already configured these permissions" without removing the dd_api_key_secret variable entirely.

3. Separation of Concerns: Users who want to separate IAM management from ECS task definition management are forced to accept module-managed IAM changes.

4. Policy Accumulation: Each task definition family creates a separate policy, even if they access the same secret.

Code Reference

locals {
  create_dd_secret_perms = var.dd_api_key_secret != null
  edit_execution_role    = var.execution_role != null && local.create_dd_secret_perms
  create_execution_role  = var.execution_role == null && local.create_dd_secret_perms
}

# This attachment happens unconditionally when edit_execution_role is true
resource "aws_iam_role_policy_attachment" "existing_role_dd_secret" {
  count      = local.edit_execution_role ? 1 : 0
  role       = local.parsed_exec_role_name
  policy_arn = aws_iam_policy.dd_secret_access[0].arn
}

Proposed Solution

Add a new variable to allow users to opt-out of automatic IAM permission management:

variable "manage_execution_role_secret_permissions" {
  type        = bool
  default     = true
  description = "Whether to create and attach secret access permissions to the execution role. Set to false if your execution role already has the necessary secretsmanager:GetSecretValue permissions."
}

Update the locals:

locals {
  create_dd_secret_perms = var.dd_api_key_secret != null && var.manage_execution_role_secret_permissions
  edit_execution_role    = var.execution_role != null && local.create_dd_secret_perms
  create_execution_role  = var.execution_role == null && local.create_dd_secret_perms
}

Use Case

Our organization manages IAM roles centrally with broad secretsmanager:GetSecretValue permissions scoped to specific secret ARN patterns. When using this module with our pre-configured execution roles, we end up with duplicate policies that our security team flags during audits.

Impact

This change would benefit:

• Organizations with centralized IAM management
• Users following least-privilege principles with pre-configured roles
• Multi-environment setups where IAM is managed separately from ECS resources