fix: add scoped queue publisher and consumer grants

[alongubkin]

Why

A queue consumer with queue/data-read cannot call queue.ack on AWS because the set lacks DeleteMessage. A publisher using queue/data-write also receives delete and visibility actions it does not need. Older installations can inherit both sets through implicit link grants, hiding the mismatch.

Change

• Add an opt-in queue/publish set for AWS SQS, GCP Pub/Sub, and Azure Service Bus.
• Make AWS queue/data-read sufficient to receive, acknowledge, and change message visibility.
• Preserve queue/data-write and the existing implicit queue-link defaults for installed applications. Explicit per-role profiles can adopt queue/publish after the normal CLI release.
• Document that a plain queue link still gets combined access. Direction-aware defaults require a separate migration because some linked workloads poll queues and stored permission profiles are checked on update.

Verification

• cargo test -p alien-permissions passed, including generated AWS IAM actions/resource scope, GCP publisher topic binding, and Azure sender/receiver roles.
• cargo test -p alien-preflights passed, including explicit publisher-link preservation.
• The opt-in alien-bindings AWS integration test passed with one disposable SQS queue and separate generated publisher/consumer IAM roles. It used the real binding under each assumed role: send was allowed only for the publisher; receive and ack only for the consumer; the acknowledged message did not redeliver. The test removed its queue and roles, and independent AWS listings found none remaining.
• This validates the permission sets and binding on real AWS. A composed application setup package and its deployed workload roles still need separate qualification after release.

ALIEN-1014

[greptile-apps]

Confidence Score: 5/5

[Critical risk] Adds new queue permission sets that control who can publish or consume messages.

The PR appears safe to merge; no outstanding previous findings or actionable new issues remain.

Summary

The PR adds opt-in publisher permissions for AWS, GCP, and Azure queues, makes AWS consumer permissions sufficient to acknowledge messages, and preserves existing implicit queue-link grants.

• Adds permission-generation tests and an opt-in AWS binding test.
• Documents how applications can adopt one-way queue profiles.
• The changes since the previous review update the worker Bun image and the ts-proto Renovate rule; neither establishes a new actionable issue.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Profile[Explicit queue profile] -->|queue/publish| Publisher[Publisher grant]
  Profile -->|queue/data-read| Consumer[Consumer grant]
  Link[Implicit queue link] --> Legacy[Existing combined grants]
  Publisher --> Queue[Queue]
  Consumer --> Queue
  Legacy --> Queue

Loading

_{Reviews (6) · Last reviewed commit: "Merge remote-tracking branch 'origin/mai..."}

[alongubkin]

Greptile’s observation is correct for a queue link with no explicit profile. This PR deliberately adds a narrow permission set and makes queue/data-read sufficient for acknowledgement; it does not claim to migrate implicit link defaults. Changing a plain queue link from bidirectional access to publish-only in this patch release could break workloads that poll a linked queue, and stored mutated permission profiles would differ during update compatibility checks. BCS already declares explicit per-role queue profiles, so its adoption of queue/publish will use the narrow path. I verified the default mutation path in alien-preflights/src/mutations/resource_link_permissions.rs and the update check in compatibility/permission_profiles_unchanged.rs. I’ll track direction-specific queue-link defaults and a safe migration separately rather than silently change existing deployments in this PR.

[alongubkin]

@greptileai Please re-review the latest commit. The implicit queue-link default is intentionally unchanged for compatibility; publisher-only access is selected through an explicit queue/publish profile. Your inline review withdrew that finding. The latest commit adds a real AWS IAM smoke test for the explicit publisher and consumer grants. Please refresh the overall score against the current head.

[alongubkin]

@greptileai Please review commit 667785d. I addressed both new comments on the AWS IAM smoke test, reran it against real AWS, verified teardown, and resolved the threads with details.

[alongubkin]

CI on the prior head stopped before compilation because Renovate #733 left two Node 22 fixtures resolved to Node 24 types in the lockfile. I merged current main and restored the pre-existing Node 22 lock entries for those fixtures; pnpm install --frozen-lockfile --lockfile-only --ignore-scripts now passes. @greptileai Please review the current head 0152bd4, including this narrow lockfile reconciliation.

[alongubkin]

@greptileai Please re-review current head 5caba71. This merge resolves the lockfile conflict by taking the already-reviewed fix from main (#737); the PR diff is now limited to the queue-permission changes. No queue implementation changed since your 5/5 review.

[alongubkin]

@greptileai Please re-review current head b1d6fc1. This merge takes the generated-code CI fix from main (#741); the PR diff remains limited to the eight queue-permission files, with no queue behavior changes since the prior 5/5 review.