Introducing ClusterNest sign-in for your clusters

Your ClusterNest account now signs you in to your OpenSearch and Prometheus clusters. There is no identity provider to set up and no password to hand out, and access follows who is in your organization.

It is on for every new cluster, and you can turn it on for the ones you already run. And because the sign-in works for agents too, an AI agent can create an OpenSearch cluster and search it in the same conversation, from your laptop or from the Claude app on your phone.

For the teams without an identity provider

Single sign-in to a cluster has meant bringing your own identity provider. That is the right answer for a company that already runs one, and we do not charge extra for it: OIDC and SAML are included on every tier, for every provider you add, instead of sitting behind an enterprise plan as they do at many vendors. Setting one up is a lot for a team that does not run one, or that just wants the logging cluster open to the people already in its ClusterNest organization.

So the choice used to be an identity provider built for the occasion, or a password handed around. Now a new engineer accepts the invitation, signs in to ClusterNest, and opens the cluster. On OpenSearch Dashboards there is a Login with ClusterNest button, and on Prometheus the cluster’s address opens a login page. One click and they are in. Nobody had to create or hand over a credential.

Access that follows your organization

Who can get in is who is in the organization, and their role there decides what they can do.

• Owners, admins and writers get full access to every cluster.
• Readers get read-only access, and the cluster enforces it. A reader can search and query, and every write is refused.
• Billing members get no access to the data on the clusters.

Invite someone and they have access. Change their role and the clusters follow. Remove them and they can no longer sign in, with no list of cluster users to remember to edit. Your security team gets offboarding that does not depend on anyone remembering the search cluster, and finance gets a role that handles the bill without touching the data.

One connector, from cluster to answer

Add the MCP connector to your AI assistant once. That is the only integration.

From there an agent can create an OpenSearch cluster, turn on the cluster’s own MCP server, and search what is in it. There is no second server to add, and no credential to create, paste into the agent’s settings or rotate.

The ClusterNest sign-in is what makes this work. The agent acts as you: every request it sends to the cluster carries a short-lived sign-in token with your role, so an agent working for a reader can search but not change anything, and one working for a billing member gets nothing.

And because it all runs through the connector, it works wherever your assistant does. That includes the phone in your pocket.

An alert fires while you are away from your desk. You open the Claude app and ask what started failing on checkout in the last hour. The agent searches the logs and answers. No laptop, no VPN, no Dashboards login.

That opens the cluster to more people and more jobs:

• Teams whose identity provider agents can’t use. A team with no identity provider, or one its agents can’t log in through, still gets an agent that can search its logs.
• People outside engineering. Support and product members invited as readers ask in plain language and get answers from the same data.
• Contractors. Invite them as readers and they query through their own assistant, with no password to hand over. Remove them and they can no longer sign in.
• A cluster for one question. Ask for a cluster, load an export into it, ask for the top error patterns, then have the agent delete it.
• A memory for your assistant. Runbooks and postmortems for a team, or documents, receipts and notes for one person. Whatever you index, your assistant can look up from any device.

A cluster’s IP allowlist applies to all of it. A hosted assistant connects from its provider’s addresses, and the guide shows where to find them.

Agents that run commands, such as Claude Code, can also ask ClusterNest for a token and query a Prometheus cluster with PromQL directly. Scripts and CI jobs use the same call over the API. The requests and responses are in the guide.

The other half: workloads that never hold a password

People are one half of the story. The other half is the software that talks to your clusters all day, and that is where a shared password does the most damage: copied to every node, shared across clusters, rotated never.

You can already close that too, with identities your platform issues:

• Log shippers on Kubernetes sign in to OpenSearch with their own pod’s short-lived token. Nothing is copied into a Secret and nothing needs rotating. We wrote up how it works, with the measurements.
• Remote-write agents and pipelines send metrics to Prometheus with a token from your identity provider or your Kubernetes cluster, through JWT federation. The cluster checks the token against the issuer’s published keys.

Next to your own identity provider

None of this replaces what you have. Your own identity providers keep working next to the ClusterNest sign-in. OpenSearch accepts OIDC and SAML providers. Prometheus accepts JWT issuers for your workloads, any of which can also sign your people in to the cluster’s query UI over OpenID Connect, and one SAML provider that does the same. A Prometheus cluster can hold several sources at once. The SSO overview shows how the pieces fit.

Passwordless, end to end

Put the pieces together. People sign in to ClusterNest with a passkey, Google or GitHub, and that opens the clusters. Workloads present a token their platform already issues. Agents and scripts ask for a short-lived token. Nobody has to know a cluster password for any of it.

Every cluster keeps its static credentials as a fallback for the day an identity system is down, and rotating them is now one button in the cluster’s Authentication card.

Try it today

New clusters already have it. For an existing cluster, open it in the console, choose Edit, and click Enable login with ClusterNest under Authentication. Terraform and the API take a builtin entry in auth_sources, and the guide has all three.

Questions, or a setup you are not sure fits? Write to [email protected].