How to configure Redash Zscaler for secure, repeatable access

Picture this: your team needs quick access to Redash dashboards, but corporate security insists everyone must go through Zscaler first. The result is often broken embeds, timed-out sessions, and engineers mumbling about “just exporting CSVs instead.” It doesn’t have to be that way. A proper Redash Zscaler setup keeps the data safe and your analytics running fast.

Redash is beloved for its simplicity. It connects to sources like PostgreSQL, BigQuery, or Snowflake, turning raw queries into living charts and alerts. Zscaler sits on the security side, acting as a cloud proxy that inspects traffic, enforces policy, and secures outbound access without traditional VPNs. When these two meet cleanly, you get red-hot visibility wrapped in enterprise-grade control.

The key is identity. Configure Zscaler to use your SSO provider—Okta, Azure AD, or another SAML/OIDC service—so that Redash inherits role-based access. Zscaler performs inline inspection and tunnel control, then forwards sessions only after it verifies user context. Redash can trust the identity claim and skip its own friction-heavy VPN whitelist. This all happens before a single dashboard is queried, making access both faster and safer.

In practice, the workflow looks like this:

1. A developer hits the Redash URL.
2. Zscaler intercepts and checks credentials with the identity provider.
3. Session metadata (IP, group, device posture) is folded into the request.
4. Redash reads those claims to enforce its own team or query-level permissions.

If Redash times out behind Zscaler, first check SSL inspection rules. Redash needs its database drivers untouched, so add exceptions where inspection breaks TLS negotiation. For RBAC mapping, ensure groups align between your identity provider and Redash’s users table. Rotate tokens regularly; both Zscaler’s trusted root and Redash’s API keys can linger longer than you expect.

Benefits of a well-tuned Redash Zscaler setup:

• Consistent identity enforcement without network gymnastics
• Fewer “just give me temporary SQL access” tickets
• Protected dashboards with auditable, identity-aware traffic logs
• Faster onboarding with one SSO instead of multiple credentials
• Clean separation between data analysis and network security layers

For developers, this means higher velocity. Less context switching, fewer browser certificate pop-ups, no waiting for IT to open ephemeral ports. Redash stays reachable and compliant at the same time.

Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically. Instead of manual PRs to update access, policies sync from your identity graph and flow to the endpoints in real time.

How do you connect Redash and Zscaler cleanly?
Use identity-first routing. Start with Zscaler’s app connector tied to your IdP, enable SAML integration in Redash, and test access through a controlled group. The traffic should stay encrypted while user context flows end to end.

AI-based copilots now dip into dashboards for context. That makes Redash’s authentication surface even more important. Access through Zscaler ensures only verified prompts can fetch data, which keeps fine-tuned models from leaking results across tenants.

Good configuration makes data storytelling secure and fast. Redash surfaces insight, Zscaler guards the door, and your team just gets on with the work.

See an Environment Agnostic Identity-Aware Proxy in action with hoop.dev. Deploy it, connect your identity provider, and watch it protect your endpoints everywhere—live in minutes.