Redis package v1.0.0

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>"}. Presentation: this registration declares the 'headers' injection mode with inject_headers [x-api-key, x-api-secret-key]; the connector parses the stored object and places each named header on the request, refusing material whose keys are not exactly the declared pair and refusing any caller-supplied spelling of either header, so the two-header contract is what the injector implements.

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 reviewed 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.

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 contract: 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 this pack declares the 'headers' injection mode, which parses the single stored JSON object and places both documented headers on every request; the credential note defines the exact stored value. 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 API reference renders as a client-side Redoc UI, but the OpenAPI 3.0.1 specification backing it was retrieved verbatim for this review and every registered route, method, operationId and the per-operation two-header security requirement were checked against it; the asynchronous TaskStateUpdate responses match the pack's provisioning note.