INF-10: es:AddTags granted by no IaC template although code performs post-purchase OpenSearch RI tagging

[cristim]

Severity: P3. Confidence: medium. Informational.

Affected files:

• providers/aws/services/opensearch/client.go:343
• terraform/modules/compute/aws/lambda/main.tf:339-393
• cloudformation/stacks/CUDly/template.yaml:437-443
• iac/federation/aws-cross-account/cloudformation/template.yaml:104-110

Evidence:
The client calls AddTags post-purchase (best-effort by design); no TF module, CFN stack, or federation template grants the action.

Impact:
The attribution-tagging feature can never work; failure is WARN-logged and the purchase still succeeds, so impact is lost attribution metadata plus recurring warning noise. Related to, but distinct from, the known-issues entry about AWS possibly rejecting RI ARNs in AddTags.

Recommendation:
Add es:AddTags to the OpenSearch statements everywhere, or remove/feature-flag the tagging attempt.

Verifier verdict: unverified - P3, adversarial verification skipped.

Source: docs/reviews/codebase-review-2026-06-10.md (automated multi-dimension code review, adversarially verified for P1/P2)

Findings from the 2026-09-02 codebase audit

Added by an automated audit of 3c0f8ac94048a2c36fce5ccddee54e6c4849a5cd (tip of origin/main). Each item below was reported by one reviewer and independently confirmed by a second that did not write it. Full report: docs/audits/codebase-audit-2026-09-02.md.

A13-023 (low)

A second instance of this exact shape, worth handling in the same sweep. internal/email/sender.go:192 publishes to s.topicARN, sourced from the SNS_TOPIC_ARN environment variable (internal/email/factory.go:77). grep -rn 'sns:' terraform iac returns nothing, so no Terraform module grants sns:Publish to the runtime role, and sns: is also absent from WorkloadServiceCeiling (policy_boundary.tf:160-198), so a boundaried role would be denied even with an identity grant. Two qualifications the OpenSearch case does not have. First, the CloudFormation path is fine: cloudformation/stacks/CUDly/template.yaml:568-573 has an SNSPublish Sid scoped to !Ref NotificationTopic, and the stack creates the topic at :729. Second, this is latent everywhere today, because nothing sets SNS_TOPIC_ARN so SendNotification takes the empty-topic skip path; even the CFN stack sets NOTIFICATION_TOPIC_ARN (:607) against the SNS_TOPIC_ARN the factory reads, so it skips there too. The moment an operator wires module.monitoring.sns_topic_arn in, every notification fails with AccessDenied. Audit finding A13-023.

[cristim]

Recovery review found a confirmed blocker in the proposed es:AddTags grant at PR LeanerCloud/cloud-commitments-cli#2077 HEAD 2484ed286bb8eec5236ef063d6d136d91c93574d.

AWS's OpenSearch Reserved Instances guide explicitly states that resource tagging is unsupported for OpenSearch Reserved Instances. This is not merely missing documentation of an ARN type.

The committed providers/aws/services/opensearch/client.go constructs an arn:aws:es:...:reserved-instance/... ARN and calls AddTags after purchase. PurchaseCommitment logs OPENSEARCH_TAG_FAILED and returns the successful purchase when tagging fails. Granting AddTags on * cannot enable the unsupported operation and instead widens access to other taggable OpenSearch resources.

The existing issue #42 already tracks this call and missing grant; its suggested permission expansion needs this qualification. Closed LeanerCloud/cloud-commitments-cli#250's suggestion to monitor possible support does not establish current support. No replacement tagging API is assumed to support reservations.

PR LeanerCloud/cloud-commitments-cli#2077 will not merge unchanged. Recovery planning will separate the real missing runtime permissions from this unsupported call and define the smallest correction with regression proof. No runtime policy, cloud resource, or purchase was changed during this investigation. This is exact-source and official-documentation evidence, not a live API test. The SNS finding also attached to #42 remains a separate unresolved item.