Repository navigation
INF-10: es:AddTags granted by no IaC template although code performs post-purchase OpenSearch RI tagging #42
Description
Activity
Recovery review found a confirmed blocker in the proposed
es:AddTagsgrant at PR LeanerCloud/cloud-commitments-cli#2077 HEAD2484ed286bb8eec5236ef063d6d136d91c93574d.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.goconstructs anarn: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.
Severity: P3. Confidence: medium. Informational.
Affected files:
providers/aws/services/opensearch/client.go:343terraform/modules/compute/aws/lambda/main.tf:339-393cloudformation/stacks/CUDly/template.yaml:437-443iac/federation/aws-cross-account/cloudformation/template.yaml:104-110Evidence:
The client calls
AddTagspost-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:AddTagsto 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 oforigin/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:192publishes tos.topicARN, sourced from theSNS_TOPIC_ARNenvironment variable (internal/email/factory.go:77).grep -rn 'sns:' terraform iacreturns nothing, so no Terraform module grantssns:Publishto the runtime role, andsns:is also absent fromWorkloadServiceCeiling(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 anSNSPublishSid scoped to!Ref NotificationTopic, and the stack creates the topic at :729. Second, this is latent everywhere today, because nothing setsSNS_TOPIC_ARNsoSendNotificationtakes the empty-topic skip path; even the CFN stack setsNOTIFICATION_TOPIC_ARN(:607) against theSNS_TOPIC_ARNthe factory reads, so it skips there too. The moment an operator wiresmodule.monitoring.sns_topic_arnin, every notification fails with AccessDenied. Audit finding A13-023.