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

# Snowflake accounts

> Add and connect to Snowflake accounts.

Snowflake accounts let you manage access to a Snowflake database. Users connect through Web Access or the CLI, and every statement they run is recorded in the [session](/docs/documentation/platform/pam/sessions/overview).

Every statement runs from the [gateway](/docs/documentation/platform/gateways/overview) in your own network, and the credential never reaches the client. Make sure the gateway can reach your Snowflake account, including over AWS PrivateLink if that's how you expose it.

## Prerequisites

* A Snowflake user for Infisical to connect as.
* A warehouse the user's role can use.
* A [gateway](/docs/documentation/platform/gateways/overview) on version 0.43.133 or later that can reach your Snowflake account. Earlier gateways don't support Snowflake and refuse the session. Snowflake returns large results from cloud object storage rather than from the account host, so a gateway behind an egress allowlist needs that storage reachable too.
* A key pair or a programmatic access token for that user. Snowflake blocks single-factor password sign-in for human users, so password authentication only works for a service user whose account policy still permits it.

## Creating an account

<Steps>
  <Step title="Start adding an account">
    Go to **Privileged Access Management → Accounts** and select **Add Account**.
  </Step>

  <Step title="Select a folder and template">
    Choose which [folder](/docs/documentation/platform/pam/folders/overview) to add the account to, then select a Snowflake [template](/docs/documentation/platform/pam/templates/overview).
  </Step>

  <Step title="Enter connection details">
    | Field                  | Description                                                                                                           |
    | ---------------------- | --------------------------------------------------------------------------------------------------------------------- |
    | **Name**               | A descriptive name (e.g., `analytics-prod`)                                                                           |
    | **Account Identifier** | The account identifier from your Snowflake URL, without the `snowflakecomputing.com` suffix (e.g., `myorg-myaccount`) |
    | **Default Warehouse**  | The warehouse a session runs its queries on. Leave blank to use the user's own default                                |
    | **Database**           | The database sessions open. Web Access lists the schemas and tables inside it                                         |
    | **Default Schema**     | The schema a session starts in. A session can switch to another schema the role can reach. Optional                   |
    | **Default Role**       | The role a session starts with. A session can switch to another role the user holds                                   |
  </Step>

  <Step title="Enter credentials">
    | Field                         | Description                                                   |
    | ----------------------------- | ------------------------------------------------------------- |
    | **Auth Method**               | Key Pair, Programmatic Access Token, or Password              |
    | **Username**                  | The Snowflake login name                                      |
    | **Private Key**               | PKCS#8 private key, for key pair authentication               |
    | **Private Key Passphrase**    | Passphrase for an encrypted private key. Optional             |
    | **Programmatic Access Token** | The token value, for programmatic access token authentication |
    | **Password**                  | The user's password, for password authentication              |
  </Step>

  <Step title="Save">
    Select **Create**. Infisical signs in to Snowflake and runs one statement to confirm the credential and the warehouse work before saving the account.
  </Step>
</Steps>

## Key pair authentication

Generate a key pair, then assign the public key to the Snowflake user:

```bash theme={"dark"}
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out infisical_key.p8 -nocrypt
openssl rsa -in infisical_key.p8 -pubout -out infisical_key.pub
```

```sql theme={"dark"}
ALTER USER pam_service SET RSA_PUBLIC_KEY = '<contents of infisical_key.pub, without the header and footer lines>';
```

Paste the contents of `infisical_key.p8` into **Private Key**, then delete your local copy. Snowflake keeps two key slots per user, `RSA_PUBLIC_KEY` and `RSA_PUBLIC_KEY_2`, so you can add a new key before removing the old one.

To rotate the key pair on a schedule instead of by hand, use a [Snowflake user key pair rotation](/docs/documentation/platform/secret-rotation/snowflake-user-key-pair).

## Programmatic access token authentication

Snowflake only issues a token to a user who is subject to a network policy, and only when the token is restricted to a role:

```sql theme={"dark"}
ALTER USER pam_service SET NETWORK_POLICY = <your network policy>;
ALTER USER pam_service ADD PROGRAMMATIC ACCESS TOKEN infisical
  ROLE_RESTRICTION = 'PAM_READER' DAYS_TO_EXPIRY = 90;
```

The token value is shown once. Paste it into **Programmatic Access Token**, and give the same role in **Role** so the session activates the one the token allows.

## Permissions

What a session can do comes from the role the account activates, so grant that role only what the people using the account need. At minimum it needs `USAGE` on the warehouse and the database, and `USAGE` on each schema whose tables should appear in Web Access:

```sql theme={"dark"}
GRANT USAGE ON WAREHOUSE analytics_wh TO ROLE pam_reader;
GRANT USAGE ON DATABASE analytics TO ROLE pam_reader;
GRANT USAGE ON SCHEMA analytics.public TO ROLE pam_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics.public TO ROLE pam_reader;
```

The account's **Role** sets what a session starts with, not a boundary it stays inside: a session can run `USE ROLE` to switch to any other role the credential holds. Grant the credential only the roles the people using the account should reach.

Command blocking matches the text of each statement, so a statement that builds SQL at runtime, such as `EXECUTE IMMEDIATE`, can run something a pattern would otherwise reject. Use Snowflake privileges for restrictions that have to hold.

## Connecting

<Tabs>
  <Tab title="Web Access">
    Web Access provides a browser-based interface with two tools:

    * **Data Explorer** — browse tables, view data, filter and sort, edit rows, export to CSV/JSON
    * **SQL Editor** — write and run SQL queries, use transactions

    To connect:

    1. Go to **Privileged Access Management → Accounts**
    2. Find the account and select the rocket icon (or select **Launch Session** from the menu)
    3. Select **Connect in Browser**
  </Tab>

  <Tab title="CLI">
    Requires Infisical CLI version 0.43.133 or later.

    The CLI starts a local proxy that snowsql, DBeaver, and the Snowflake drivers connect to. It speaks plain HTTP on `127.0.0.1`, so connect with `ssl=off` and no certificate to trust. The username and password are ignored, since the gateway authenticates for you.

    ```bash theme={"dark"}
    infisical pam access analytics/snowflake-prod
    ```

    The command prints the port and a ready-made connection string for each client.

    **Flags:**

    * `--port <port>` — use a specific local port (otherwise one is assigned automatically)
    * `--reason <reason>` — provide an access reason (if required by template)
  </Tab>
</Tabs>

Infisical caps results at 10,000 rows per statement so a large query can't exhaust the gateway's memory, and the Data Explorer shows the first 1,000 of those and tells you when there are more. Snowflake itself imposes no such limit; use the CLI with your own client to work with a full result set.

<Note>
  Snowflake doesn't enforce primary keys, but the Data Explorer still needs one declared on a table before it can edit that table's rows. A table without one is read-only in the grid, and editable from the SQL editor.
</Note>

## Recording

Every statement a session runs is recorded, along with the outcome of each one, and appears under **Session Logs** on the session. Web Access and the CLI both reach Snowflake through the gateway, so recording works the same for either. Recordings are encrypted with a per-session key and written to the storage backend the [template](/docs/documentation/platform/pam/templates/overview) selects, the same as any other account type.

The template's **Command Blocking** policy applies to Snowflake as well: a statement matching one of its patterns is rejected before it reaches Snowflake, and the rejection is recorded. **Session Log Masking** patterns are applied to the recording before it's written.

## Next steps

<CardGroup cols={2}>
  <Card title="Sessions" icon="display" href="/docs/documentation/platform/pam/sessions/overview">
    View and manage sessions.
  </Card>

  <Card title="Access requests" icon="user-check" href="/docs/documentation/platform/pam/access-requests/overview">
    Require approval before a session starts.
  </Card>
</CardGroup>