confluence v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-confluence-basic-header

Custody

customer_vault

Injection

header (Authorization)

The value stored under this reference is the complete Authorization header value (scheme included): the scheme 'Basic', one separating space, then the base64 encoding of 'email:api-token' for a dedicated Atlassian account — 'Basic <base64(email:api-token)>', exactly as Atlassian's basic-auth documentation constructs it. The API token is created at id.atlassian.com/manage/api-tokens and placed in the client's own secret manager by an external deployment process; the executor injects the stored value verbatim and performs no token lifecycle itself. Be honest about the trade-off: Atlassian documents basic auth as not as secure as other methods and recommends it for scripts and manual calls, and Atlassian's security requirements for cloud apps and acceptable-use policy do not permit apps that collect customers' API tokens — a production integration that other parties operate should be a single distributable OAuth 2.0 (3LO) app, whose consent screen grants explicit scopes (read:page:confluence, read:space:confluence, write:page:confluence for these capabilities) and whose calls go to api.atlassian.com/ex/confluence/{cloudid}/... as a 'Bearer <token>' value under a different registered reference and egress entry; that model is not interchangeable with this one and switching to it is a reviewed change, not a silent substitution. API tokens are unscoped by default: this registration uses an unscoped API token, which acts as the creating user with that user's full permissions until revoked or expired, so least privilege is achieved through the account, not the token: create the token on a dedicated account holding view permission (and create permission only where page creation is required) on exactly the spaces in scope. Scoped API tokens exist, but they call through api.atlassian.com/ex/confluence/{cloudid}/... rather than the site host, so adopting them is a reviewed authentication change (new egress entry and registered reference), not a drop-in substitution for this one. Tokens are revoked at id.atlassian.com/manage/api-tokens and a revoked value fails closed. Atlassian documents a finite token lifecycle: tokens created after 2024-12-15 expire one year after creation by default, and the creator chooses an expiry of 1 to 365 days at creation, so rotation is mandatory, not optional — the external process must replace the stored value before its expiry date, and ownership of that replacement sits with the external process. customer_vault is the only generally-supported production custody model here — identity_federation and customer_broker are refused at startup and inline is lab-only. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• confluence-pages (site, internal): https://atlassian-site.invalid/wiki/api/v2/pages
• confluence-spaces (site, internal): https://atlassian-site.invalid/wiki/api/v2/spaces

The endpoint host 'atlassian-site.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's own Confluence Cloud site host before enabling, in the endpoints, the resource locators and the egress allowlist — the allowlist matches exactly, so all three must be substituted together, substitution is a required deployment step, and allowlisting the reserved host does not make an unsubstituted pack safe. Every endpoint here is on the customer site host, not a shared Atlassian host, so the allowlist moves with the tenant. SPACE_ID in the space-pages endpoint path is a placeholder the deployment binds to a concrete numeric space id before enabling. This pack registers only endpoints the official Atlassian Confluence Cloud REST API v2 documentation publishes: get pages, get spaces, get pages in space, and create page. Documented exclusions: this pack does not register page update, title update or deletion (PUT/DEL /wiki/api/v2/pages/{id}, whose delete only trashes and whose purge is permanent), blog posts, comments, attachments, labels, likes, tasks, whiteboards, custom content and databases, space creation (POST /wiki/api/v2/spaces, which Atlassian documents as available only on tenants with role-based access control), space permissions, properties and roles, user and admin-key operations, the CQL search API, and the entire v1 content API — a documented exclusion, not an approximated capability. Tiering rationale: the three reads sit at the R0 floor of read at the internal class — page titles, bodies, authors and space metadata are unpublished collaboration content, and a deployment whose spaces hold client or personal data should raise the class; confluence.pages.create registers create+share at the R3 floor of share: pages are created as published unless the caller sets status to draft, so a successful call immediately publishes content to everyone with view permission on the space — that publication is a sharing effect under the IRREVERSIBLE ACTIONS vocabulary (delete, send, pay, deploy, approve, share and transfer), which carries an R3 floor. Confluence permission checks are performed server-side as the authenticating user: only pages and spaces that user may view are returned, and only spaces where that user has create permission accept a page — the account behind the credential is the real access boundary, so use a dedicated least-privilege account.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://developer.atlassian.com/cloud/confluence/rest/v2/api-group-page/ (retrieved 2026-09-21)
• https://developer.atlassian.com/cloud/confluence/rest/v2/api-group-space/ (retrieved 2026-09-21)
• https://developer.atlassian.com/cloud/confluence/basic-auth-for-rest-apis/ (retrieved 2026-09-21)
• https://developer.atlassian.com/cloud/confluence/oauth-2-3lo-apps/ (retrieved 2026-09-21)
• https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/ (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.