[aws] Declare required permissions with provider_permissions

[jeniawhite]

Proposed commit message

Adopt the new provider_permissions field (package-spec, format_version 3.6.4) so the AWS integration declares the IAM permissions it actually needs in a machine-readable way, instead of leaving them in prose docs and expecting users to attach a broad managed policy (e.g. SecurityAudit/ReadOnlyAccess).

• Bump format_version 3.4.0 → 3.6.4 and package version 6.19.2 → 6.20.0; add a changelog.yml entry.
• Declare permissions across three layers, placed so that the effective (accumulated-and-deduplicated) permission set for each enabled data stream is minimal and contains no cross-layer duplication:
• package — sts:GetCallerIdentity only; the single call every credentialed AWS collector makes.
• input (50 inputs) — the permissions tied to each collection mechanism: aws/metrics → ec2:DescribeRegions, cloudwatch:ListMetrics, cloudwatch:GetMetricData, tag:GetResources; aws-s3 → s3:GetObject/ s3:ListBucket + SQS notification actions; aws-cloudwatch → logs:DescribeLogGroups/logs:FilterLogEvents; cel/httpjson → the AWS Config / Inspector / GuardDuty API read calls.
• data_stream (26 streams) — every service/resource permission a stream needs for metric enrichment or API collection (e.g. ec2:DescribeInstances on ec2_metrics, rds:Describe* on rds, and the disjoint Security Hub GetFindings vs GetInsights/ListInsights/GetInsightResults reads).
• policy_template — intentionally unused: no permission is common to all of a template's data streams without over-granting a sibling, so placing anything here would either duplicate a lower layer or grant a stream more than it needs.

Permission requirements currently exist only in documentation, so they drift over time and cannot be consumed by tooling. Declaring them with provider_permissions versions them alongside the package and lets tooling generate appropriately scoped infrastructure-as-code rather than a static kitchen-sink policy.

The placement follows the spec's accumulate-and-deduplicate semantics together with least privilege: each permission is declared exactly once, at the broadest layer whose scope matches everything that needs it. This keeps minimal grants when only some data streams are enabled. Concretely:

• a logs-only deployment never receives cloudwatch:* (those live on the aws/metrics input);
• GuardDuty collected via S3/SQS receives only S3/SQS transport permissions - not the GuardDuty API reads, which sit on the httpjson input rather than the guardduty data stream;

No data streams, ingest pipelines, dashboards, or collection behavior change; this is metadata only.

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

Author's Checklist

• provider_permissions are placed at the correct layer (package / input / data_stream) with no cross-layer duplication.
• IAM action names and the per-action descriptions are accurate for each service.
• Effective (aggregated) permission set per data stream is least-privilege.

How to test this PR locally

Related issues

• Requires Add provider_permissions field for declaring integration permission requirements package-spec#1180
• Relates elastic/security-team#16737

Screenshots

[github-actions]

✅ Elastic Docs Style Checker (Vale)

No issues found on modified lines!

---

The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale.

[github-actions]

TL;DR

Two separate failures are blocking this Buildkite run: a wrong PR link in packages/aws/changelog.yml, and an unsupported package spec version (format_version: 3.6.4) in CI. Update the changelog link immediately, then either align CI tooling to a spec that includes 3.6.4 or temporarily use a supported format version.

Remediation

• Fix the changelog entry link at packages/aws/changelog.yml:6 from https://github.com/elastic/integrations/pull/19999 to https://github.com/elastic/integrations/pull/19405.
• Resolve the spec-version mismatch for packages/aws/manifest.yml:1 (format_version: 3.6.4):
  • either update the CI toolchain used by test_one_package.sh to one that includes spec 3.6.4,
  • or temporarily revert to a currently supported format_version until that toolchain update lands.

Investigation details

Root Cause

1. Configuration failure (changelog check):

   • packages/aws/changelog.yml:6 links to PR 19999, but this PR is 19405.
   • The :scroll: Check changelog PR links step fails by design on that mismatch.

2. Dependency/toolchain compatibility failure (aws package check):

   • packages/aws/manifest.yml:1 sets format_version: 3.6.4.
   • The Check integrations aws step fails during lint/spec loading because the CI environment cannot load spec 3.6.4.

Evidence

• Build: https://buildkite.com/elastic/integrations/builds/44226
• Jobs:
  • :scroll: Check changelog PR links
  • Check integrations aws
• Key log excerpts:

ERROR: unexpected link: 'https://github.com/elastic/integrations/pull/19999'
       expected:         'https://github.com/elastic/integrations/pull/19405'
--- 1 changelog link(s) do not match this PR

Error: checking package failed: linting package failed: could not load specification for version [3.6.4]: spec version "3.6.4" not found

Verification

• Not run locally in this detective workflow (read-only analysis from Buildkite logs and PR contents).

Follow-up

• After fixing the changelog link and resolving the spec-version/toolchain mismatch, re-run Buildkite to confirm both failing steps clear.

---

What is this? | From workflow: PR Buildkite Detective

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[elastic-vault-github-plugin-prod]

✅ All changelog entries have the correct PR link.

[elasticmachine]

💔 Build Failed

• Buildkite Build
• Commit: c1ede32

Failed CI Steps

• Check integrations aws

History

• 💔 Build #44226 failed 51a5a3d

[infra-vault-gh-plugin-prod]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)