Overly broad IAM Permission Scope for Datadog Forwarders

[aatif912]

Issue Description

Security concerns regarding the IAM permissions used in the Datadog serverless forwarders and would like guidance on implementing security best practices while maintaining full functionality.

Background

During a security assessment of infrastructure using the community terraform module (terraform-aws-datadog-forwarders), it was discovered that several permissions that appear overly broad from a security perspective. The terraform module is based on official templates, so I want to understand the reasoning behind these permissions and get guidance on potential improvements.

Current Permission Concerns

KMS Decrypt Permissions

Current State in Main Template (template.yaml:670):

- Action:
    - kms:Decrypt
  Resource: "*"
  Effect: Allow

Concern: This allows decryption of ANY KMS-encrypted data in the AWS account, including:

• RDS snapshots
• EBS volumes
• Secrets Manager secrets
• S3 objects
• Any other KMS-encrypted resources

Observed Inconsistency: Specialized templates use more restrictive approaches:

• RDS Enhanced Monitoring: Uses KMSDecryptPolicy with specific KeyId
• VPC Flow Logs: Uses KMSDecryptPolicy with specific KeyId

Questions for the Team

1. KMS Permissions: Is the broad kms:Decrypt on "*" truly necessary for the main log forwarder? Could it be scoped to specific keys like in the RDS/VPC templates?

2. Service Conditions: Would adding service conditions (like kms:ViaService) provide sufficient security while maintaining functionality?

   "Condition": {
     "StringEquals": {
       "kms:ViaService": [
         "lambda.*.amazonaws.com",
         "secretsmanager.*.amazonaws.com", 
         "s3.*.amazonaws.com"
       ]
     }
   }

3. Regional Restrictions: Would regional conditions help reduce cross-region exposure?

4. Documentation: Could you provide guidance on the minimum required permissions for each forwarder type?

Proposed Solutions

Based on RDS/VPC templates, I propose:

Option 1: KMS Key-Specific (Recommended)

{
  "Action": ["kms:Decrypt"],
  "Resource": "arn:aws:kms:*:*:key/${KMSKeyId}",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": ["lambda.*.amazonaws.com", "secretsmanager.*.amazonaws.com", "s3.*.amazonaws.com"]
    }
  }
}

Option 2: Enhanced Service Conditions

{
  "Action": ["kms:Decrypt"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": ["lambda.*.amazonaws.com", "secretsmanager.*.amazonaws.com", "s3.*.amazonaws.com"]
    }
  }
}

Environment Details

• Repository: DataDog/datadog-serverless-functions
• Affected Templates:
  • aws/logs_monitoring/template.yaml
  • Community terraform module policies based on these templates

References

• Main Log Forwarder Template
• RDS Enhanced Monitoring Template
• VPC Flow Log Template
• Terraform Community Module

[perzycharles]

You can use PermissionsBoundaryArn to limit access if needed. Does that meet your use case?
https://github.com/DataDog/datadog-serverless-functions/blob/master/aws/logs_monitoring/template.yaml#L624

[aatif912]

Hi @perzycharles
Thank you for the suggestion!
Unfortunately, using a PermissionsBoundaryArn does not fully address our use case. In our setup, the forwarder module is not consumed directly, we inherit it indirectly through another module, and therefore we cannot modify or override the permission boundaries at this level.
Our goal is to understand whether the broad kms:Decrypt permission is fundamentally required for the forwarder to function, or whether it can be scoped more tightly (similar to the RDS and VPC Flow Log templates). Because we can’t apply a permissions boundary in our module chain, we are specifically looking for guidance on least‑privilege IAM design within the template itself rather than at the deployment boundary.