redis 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-redis-cloud-api-keys

Custody

customer_vault

Injection

header (x-api-key)

Redis Cloud REST API credentials for the customer's own account, held in the client's own secret manager. Authentication requires TWO headers on every request: the account key as 'x-api-key' and a user (secret) key as 'x-api-secret-key'. The stored material is ONE exact value: a single JSON object of the form {"x-api-key":"<account key>","x-api-secret-key":"<user key>"}. Declared connector gap: this registration declares a single-header injector (inject_name: x-api-key), which can place only one stored string into one header and CANNOT split this object into the two documented headers — the two-header contract therefore requires a separately reviewed two-header-capable connector binding before the pack can be enabled, and the injector fields as declared are not a working representation on their own. Issuance: the API is disabled by default; enabling it generates the account key once, and changing or deleting the account key requires contacting Redis support — there is no self-serve rotation of the account key. User keys are personal keys issued to users holding the Owner, Viewer, Billing admin or Logs viewer role, are shown only once at creation, and may be scoped to a CIDR allow list of source IPs. Least privilege: create a dedicated user for this integration with the minimum role that covers the enabled capabilities (a Viewer-role key cannot perform the writes), issue it its own user key so system-log audit attributes requests to this integration, and set the CIDR allow list to the executor's egress addresses. Expiry and revocation: the fetched documentation describes no automatic expiry; a user key stays valid until it is deleted in the console (or the owning user is removed), and disabling the ability to create NEW keys does NOT invalidate already-issued keys — revocation means deleting each issued key, and account-key replacement goes through support. Renewal and rotation ownership sits with an external deployment process; the executor injects the stored values verbatim and performs no key lifecycle itself. Executor hygiene: the values 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.

• redis-cloud-account (api, internal): https://redis-cloud.invalid/v1

The endpoint host 'redis-cloud.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the Redis Cloud REST API host the deployment actually uses (the documented API endpoint URI is https://api.redislabs.com/v1) before enabling, in every endpoint, in the resource locator and in every egress allowlist entry — the allowlist matches exactly, so all three must be substituted together, and substitution is a required deployment step. SUBSCRIPTION_ID and DATABASE_ID in the endpoint paths are placeholders the deployment binds to concrete resources before enabling. Two-header honesty: Redis Cloud authenticates EVERY API request with two headers — the account key in 'x-api-key' and a personal user key in 'x-api-secret-key' — and the credential note defines the exact stored value; because the declared single-header injector cannot place two headers, every capability in this pack carries a declared connector gap — enabling requires a separately reviewed two-header-capable connector binding, which is one of the reasons this pack stays in draft state. The API is disabled on all accounts by default and must be enabled before any capability here works. Provisioning is asynchronous: create, update and delete operations return a task the caller polls (GET /v1/tasks/{taskId}) — this pack registers the initiating operations only, and task polling is a read of the same class the deployment may register separately. Documented exclusions — this pack does not register: user and role management (creating users or assigning roles under /v1/users and ACL endpoints), payment methods and billing operations, cloud account management (cloud accounts hold the customer's own cloud-provider credentials used for Bring-Your-Own-Cloud provisioning), database backup scheduling and especially database import (an import overwrites current database content — destructive to live data and deserving its own review), CRDB / Active-Active subscription management, SSO and SAML configuration, and system log export. The vendor's full API reference is a client-side Swagger UI that could not be retrieved verbatim in this review session; the registered routes follow the documented v1 shapes shown in the fetched getting-started and usage pages (and the public task-status example linking to /v1/subscriptions/{id}), and each route must be re-verified against the live reference before enabling — one reason this pack stays in draft state.

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

• https://redis.io/docs/latest/operate/rc/api/get-started/ (retrieved 2026-09-21)
• https://redis.io/docs/latest/operate/rc/api/get-started/use-rest-api/ (retrieved 2026-09-21)
• https://support.redislabs.com/hc/en-us/articles/27215735376658 (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.