> ## Documentation Index
> Fetch the complete documentation index at: https://help.dsalta.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Redis Cloud

> Managed Redis — users & access

<Tabs>
  <Tab title="Overview">
    Connect Redis Cloud with an Account key and a user key secret to sync account users, subscriptions and databases, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists your Redis Cloud **account users** — the team that can sign in to the Redis Cloud console. Redis Cloud has no guest or external-collaborator class on this API, so every row is a team member. Redis Cloud reports no account status, so every user is shown as **Active**; users who sign in through SAML SSO have their user type shown next to their role. Unlike most integrations, Redis Cloud does report per-user MFA, so the **MFA** column shows **Yes** or **No** for each user, and **Unknown** for a user whose record carries no MFA value.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Redis Cloud account user roster — names, email addresses, roles, sign-up dates, user type and MFA status — which appears on your **Access** page; and your Redis Cloud subscriptions and databases, which appear on your **Inventory** page. Both subscription plan families are read, **Pro** and **Essentials**, because Redis Cloud lists them on separate endpoints; each subscription row carries its plan family, status and region, Essentials rows also carry their plan name, and each database row carries its status and memory limit.

    It calls these Redis Cloud endpoints:

    * `/v1/` (the account, used to validate the key pair)
    * `/v1/users`
    * `/v1/subscriptions`
    * `/v1/fixed/subscriptions`
    * `/v1/subscriptions/{id}/databases`
    * `/v1/fixed/subscriptions/{id}/databases`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Redis Cloud environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The Account key and the user key secret must belong to the same Redis Cloud account, and the REST API must be enabled for that account. A user key that was deleted on the **API Keys** tab, or one whose **CIDR allow list** does not include DSALTA's servers, is rejected the same way. Create a fresh user key and connect again.
      </Accordion>

      <Accordion title="Inventory lists subscriptions but no databases">
        Database listing is best-effort per subscription: a subscription still appears on the Inventory page when its database listing fails, so a subscription with no database rows is not necessarily empty. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Redis Cloud Account key plus a user key secret. Both are sent on every API call. Read-only.

    **Before you begin**

    * A Redis Cloud account.
    * **Owner** access to that account. Only an account owner can enable the REST API and create user keys.

    You will need:

    | Field               | Where to find it                                             | Example                         |
    | ------------------- | ------------------------------------------------------------ | ------------------------------- |
    | **Account key**     | **Team & API → API Keys** tab, shown once the API is enabled | Masked until you click **Show** |
    | **User key secret** | **Team & API → API Keys** tab, created with **Add**          | Shown once, at creation         |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Redis Cloud**, and click **Connect** to open the connect panel. Leave it open — you create both values in the steps below.
      </Step>

      <Step title="Open Team & API">
        Sign in to the [Redis Cloud console](https://cloud.redis.io) as an account owner. In the left menu, under **ACCOUNT**, click **Team & API**. The screen that opens is titled **Access Management** (Redis's own documentation refers to it by that name). Select the **API Keys** tab.
      </Step>

      <Step title="Enable the API and copy the Account key">
        If you see an **Enable API** button, click it — the REST API is off by default, and only an account owner can turn it on. Once enabled, the **API account key** is shown masked: click **Show** to reveal it or **Copy** to copy it.

        <Warning>
          **Treat both keys as passwords.** Redis Cloud states that anyone who sends a request with a valid key pair can make changes to your account. DSALTA only ever reads, but the Account key itself is not read-only — the user key you create in the next step is what limits what the pair can do.
        </Warning>
      </Step>

      <Step title="Create a user key">
        Still on the **API Keys** tab, click **Add** under **API user keys**. Enter a **Key name** (10 to 50 characters, letters, numbers, hyphens and underscores only) and pick the **User name** the key belongs to. Click **Create**, then copy the secret from the **API user key** dialog — the **Finish** button stays inactive until you do.

        <Tip>
          Pick a user with the **Viewer** role. Redis Cloud allows Viewer keys to make GET requests only, which is exactly what DSALTA does, so the key cannot be used to change anything even if it leaks. An **Owner**'s key also works.
        </Tip>

        <Info>
          The secret is shown exactly once. If you lose it, delete the key and create a new one — Redis Cloud cannot retrieve it. Leave the key's **CIDR allow list** at its default (all addresses): a key restricted to your office addresses rejects DSALTA's servers.
        </Info>
      </Step>

      <Step title="Connect Redis Cloud">
        Return to the connect panel you opened in step 1, paste the **Account key** and the **User key secret** into their fields, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key pair when you click **Connect**, by reading the account record (`/v1/`). On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Either key is wrong, the two keys come from different accounts, the REST API is not enabled for the account, or the user key was deleted.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check                                                                                                                      | Severity | What it verifies                                                                       |
    | -------------------------------------------------------------------------------------------------------------------------- | -------- | -------------------------------------------------------------------------------------- |
    | [User access to Critical System should be valid](/integrations/redis-cloud/user-access-to-critical-system-should-be-valid) | Info     | Checks that everyone with Redis Cloud access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/redis-cloud/offboarded-users-should-not-have-active-access) | High     | Checks that offboarded employees no longer have active Redis Cloud access.             |
    | [MFA should be enabled for all users](/integrations/redis-cloud/mfa-enabled-for-all-users)                                 | High     | Checks that every Redis Cloud account user has multi-factor authentication enabled.    |
  </Tab>

  <Tab title="Useful links">
    | Topic       | Link                                                                                                                        |
    | ----------- | --------------------------------------------------------------------------------------------------------------------------- |
    | Setup       | [Enable the Redis Cloud API](https://redis.io/docs/latest/operate/rc/api/get-started/enable-the-api/)                       |
    | Setup       | [Manage API keys](https://redis.io/docs/latest/operate/rc/api/get-started/manage-api-keys/)                                 |
    | Setup       | [Team management roles](https://redis.io/docs/latest/operate/rc/security/access-control/access-management/)                 |
    | Remediation | [Multi-factor authentication](https://redis.io/docs/latest/operate/rc/security/access-control/multi-factor-authentication/) |
    | General     | [Redis Cloud console](https://cloud.redis.io)                                                                               |
    | DSALTA      | [Connection error messages](/troubleshooting/connection-error-messages)                                                     |
  </Tab>
</Tabs>
