Implement verifier integration

[jeniawhite]

Proposed commit message

Adds the Permission Verifier integration package (verifier_otel) so Cloud Connectors can run permission checks for their integrations and send results to Elasticsearch via the OTEL Collector’s Verifier receiver.

Cloud Connector deployments need to confirm that IAM/API credentials have the permissions required by each attached integration. This integration configures the Elastic distribution’s Verifier receiver so that:

• Verification runs (on-demand or scheduled) with the connector’s credentials.
• Results are sent as OTEL logs to Elasticsearch with policy/integration/permission context.
• Users can see which permissions are granted, denied, or errored and fix configuration.

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

• [ ]

How to test this PR locally

Related issues

Screenshots

[github-actions]

Vale Linting Results

Summary: 2 warnings, 2 suggestions found

⚠️ Warnings (2)

File	Line	Rule	Message
packages/verifier_otel/_dev/build/docs/README.md	34	Elastic.Latinisms	Latin terms and abbreviations are a common source of confusion. Use 'versus' instead of 'vs'.
packages/verifier_otel/docs/README.md	34	Elastic.Latinisms	Latin terms and abbreviations are a common source of confusion. Use 'versus' instead of 'vs'.

💡 Suggestions (2)

File	Line	Rule	Message
packages/verifier_otel/_dev/build/docs/README.md	34	Elastic.Wordiness	Consider using 'because' instead of 'since'.
packages/verifier_otel/docs/README.md	34	Elastic.Wordiness	Consider using 'because' instead of 'since'.

---

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.

[Omolola-Akinleye]

Thinking about the Integration Type field — would it make sense to map this directly to policy_template from manifest.yml instead? Since Fleet's package policy API already models around policy_template, we'd get consistency end-to-end and avoid any mapping logic on the Kibana side.

Would also propose embedding package metadata alongside the integration

{
  "policy_template": "guardduty",
  "package_policy_id": "",
  "package": {
    "name": "aws",
    "title": "AWS",
    "version": "6.2.0"
  }
  "namespace": "default"
}

This makes the Agentless API request fully self-describing — no lookups needed, clean audit trail, and the vocabulary stays consistent with Fleet. One thing worth noting in the spec: policy_template alone isn't globally unique across packages, so the safe unique key is the composite of package.name + policy_template (which this shape already captures).

[Omolola-Akinleye]

Prefixing will add maintenance overhead on the Kibana side. We've already had to deal with mapping prefixes for AWS package fields that are named differently across CSPM, Asset Inventory, and AWS packages. A lot of work went into normalizing these down to role_arn, external_id, and default_region across both the AWS package and Cloud Connector saved object — prefixing would undo that.

Suggestion: keep the normalized snake_case fields as-is and add a provider meta field to carry the context that would otherwise be encoded in prefixes:

{
  "provider": "aws",
  "role_arn": "",
  "external_id": "",
  "default_region": ""
}

OR

If some namespacing is preferred, a credentials_ snake_case prefix is a reasonable middle ground — it's consistent, flat, and readable without introducing a new translation layer:

{
  "provider": "aws",
  "credentials_role_arn": "",
  "credentials_external_id": "",
  "default_region": ""
}

default_region sits outside the prefix since it's config, not auth. Hopefully, this keeps the shape flat while still giving credential fields a clear grouping and keeps fields stable and reusable across integrations without Kibana needing to own a translation layer for every package's naming conventions.

[Omolola-Akinleye]

Assuming a role behaves differently depending on whether you're targeting a single account vs an organization (management) account in cloudbeat. How about when verifying permissions?

Do you need additional account_type as metadata to help verify permissions?

// Cloud connector SO Model
{
        mappings: {
        dynamic: false,
        properties: {
          name: { type: 'keyword' },
          namespace: { type: 'keyword' },
          cloudProvider: { type: 'keyword' },
          accountType: { type: 'keyword' },
          vars: { type: 'flattened' },
          created_at: { type: 'date' },
          updated_at: { type: 'date' },
        },
   }
}

[Omolola-Akinleye]

So is the permission matrix base on least-privilege principle so each permission will be scope to integration type as opposed global permissions shared by integration package?

[jeniawhite]

@claude

[Omolola-Akinleye]

Looks great so far! This is my early feedback and I'm verifying if anything is need on Kibana side, I will have subsequent review soon.

[Omolola-Akinleye]

Temporary blocked merge until we align on data model changes to avoid accidental merge.

[Omolola-Akinleye]

@jeniawhite just one more thought when I sync'd with Oleg. He mentioned there can be IAM Policy with multiple permissions which I didn't think about. What is the relationship between verification and handling IAM Policy/permissions.

For instance,if user could update IAM policy include multiple permissions. Will each verification doc check multiple permissions?

IAM Policy AmazonS3ReadOnlyAccess for Amazon S3.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*",
        "s3:Describe*",
        "s3-object-lambda:Get*",
        "s3-object-lambda:List*"
      ],
      "Resource": "*"
    }
  ]
}

[jeniawhite]

Current state of the verifier maps the required actions per integration and these are the actions that are being verified and send as events. If we'd like we can verify the IAM roles as well by attempting to assume them (without triggering actions). This would require changes to the verifier by adding an additional type of verification (non API...). We'll need to understand what we want to verify for the integration and have it as part of the registry. If we decide to only assume then there are cons like SCP rules that might block requests and misaligned action configurations. Should I create discussion around this topic? @Omolola-Akinleye @olegsu

[olegsu]

When we ask customers in documentation page that in order for an integration to work properly we need an access to builtit, support by aws role, this is how I expect it to be reflected in case the trust was revoked.

[Omolola-Akinleye]

credentials_workload_identity_provider makes sense but I notice our integrations use term audience can we keep it consistent here as well? I think GCP Docs treats the url as audience as well.

[Omolola-Akinleye]

Thinking about scale how are we going verify a cloud connector that have mutilple packages such as CSPM and Asset Inventory) or single package with multiple policy templates (guard duty and cloud trail)

• If we want verify permission for multiple integration types for AWS which Guard Duty and Cloud trail. Should policy templates be an array in this case?

• We have edge case where two packages that share the same IAM Policy Security Audit; hence, can use the same cloud connector. How should we verifying multiple packages that share a cloud connector?

[Omolola-Akinleye]

LGTM! Thanks for the changes!

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: bc1fd6d

History

• 💔 Build #40132 failed a5accb8
• 💚 Build #39576 succeeded 0a5cb5e
• 💔 Build #39435 failed d9dc915
• 💔 Build #39357 failed c6a3938
• 💚 Build #39258 succeeded 187c61f
• 💚 Build #39208 succeeded c41bd90