Sign in to Clusters with Your ClusterNest Account

Members of your organization can sign in to its OpenSearch and Prometheus clusters with their ClusterNest account. There is no identity provider to set up and no password to hand out: who can get in follows who is in the organization. A new cluster has the ClusterNest sign-in turned on.

• OpenSearch: OpenSearch Dashboards shows Login with ClusterNest next to the built-in internal user.
• Prometheus: opening the cluster’s address in a browser, such as https://metrics-123-cm.c9t.io, shows a login page, then the query UI. For scripts, get a token. Clients that run unattended keep using the static credentials or a JWT source.

What each member can do

A member’s organization role decides their access on every cluster:

Organization role	Access
Owner, Admin, Write	Full access. On OpenSearch this is the all_access role, on Prometheus the same as the admin credential.
Read	Read-only. On OpenSearch this is the readall role, on Prometheus the same as the readonly credential.
Billing	None.

Invite people and change their roles on the Organization page of the Console. The default role for an invited member is Read.

When someone is removed from the organization, or their role changes, their access on the clusters follows within about 15 minutes. OpenSearch Dashboards also asks everyone to sign in again after an hour.

Turn it on or off

The ClusterNest sign-in is an entry of type builtin in the cluster’s auth_sources. A cluster can have one.

Console

1. Open the cluster form: Launch Cluster for a new cluster, or Edit on an existing one.
2. Under Authentication, click Enable login with ClusterNest to turn it on, or remove its card to turn it off.
3. Save the cluster.

Terraform

resource "clusternest_prometheus" "metrics" {
  name            = "metrics"
  tier            = "standard"
  organization_id = 123

  auth_sources = [
    {
      name = "organization"
      type = "builtin"
    },
  ]
}

A cluster created without auth_sources gets the ClusterNest sign-in, and one that already exists keeps the sources it has when the attribute is left out. Set auth_sources = [] to remove every source, the ClusterNest sign-in included. The OpenSearch resource takes the same entry. See the resource references for Prometheus and OpenSearch.

Raw API

PUT replaces the whole cluster, so GET it, merge your change into the response and send that back, as in the JWT federation guide. Add the entry to turn the sign-in on (a cluster that already has it rejects a second one), and drop it from the list to turn it off:

curl "https://api.clusternest.com/cluster/prometheus/$CLUSTER_ID" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  | jq '.auth_sources += [{"type": "builtin", "name": "organization"}]' > cluster.json

curl -X PUT "https://api.clusternest.com/cluster/prometheus/$CLUSTER_ID" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  --data-binary @cluster.json

For OpenSearch, use /cluster/opensearch/$CLUSTER_ID.

Use it from a script

Scripts, CI jobs and AI agents can’t open a login page. Ask the API for a token for the cluster instead. First get an access token for your account: generate an app password from the MFA settings page of your account (your regular password does not work), then exchange it. Then trade that token for one the cluster accepts:

OpenSearch

export ACCESS_TOKEN=$(curl -sS -X POST https://api.clusternest.com/auth/token \
  -H "Content-Type: application/json" \
  -d '{"email": "[email protected]", "app_password": "<app password>"}' \
  | jq -r .access_token)

export CLUSTER_TOKEN=$(curl -sS -X POST \
  "https://api.clusternest.com/cluster/opensearch/$CLUSTER_ID/builtin-token" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  | jq -r .access_token)

curl -sS -H "Authorization: Bearer $CLUSTER_TOKEN" \
  https://logs-123-os.c9t.io/_cluster/health

Prometheus

export ACCESS_TOKEN=$(curl -sS -X POST https://api.clusternest.com/auth/token \
  -H "Content-Type: application/json" \
  -d '{"email": "[email protected]", "app_password": "<app password>"}' \
  | jq -r .access_token)

export CLUSTER_TOKEN=$(curl -sS -X POST \
  "https://api.clusternest.com/cluster/prometheus/$CLUSTER_ID/builtin-token" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  | jq -r .access_token)

curl -sS -H "Authorization: Bearer $CLUSTER_TOKEN" \
  "https://metrics-123-cm.c9t.io/prometheus/api/v1/query?query=up"

The response to the second request is the token and how long it lasts:

{
  "access_token": "<token>",
  "token_type": "Bearer",
  "expires_in": 900
}

The token works for 15 minutes, so ask again when requests start returning 401. It carries your role in the organization, so it gives a script the same access you have: full access for an Owner, Admin or Write member, read-only access for a Read member. It only works on the cluster it was requested for.

The request fails with 409 when the cluster has no ClusterNest sign-in, and with 403 when your role has no cluster access (Billing) or you are no longer a member. An AI agent connected through the MCP connector can call the get_opensearch_cluster_builtin_token and get_prometheus_cluster_builtin_token tools instead.

A shipper or remote write client that runs unattended should use the static credentials or a JWT source, which don’t expire every 15 minutes.

Alongside your own identity provider

The ClusterNest sign-in works next to the other sources a cluster accepts, and neither affects the other.

• Prometheus: any number of JWT sources can sit next to it. The login page offers the ClusterNest sign-in and, if you use it, the static credentials.
• OpenSearch: a cluster has one OpenID Connect login on its Dashboards page, and the ClusterNest sign-in uses it. It can’t be combined with an OIDC source that has dashboards_login turned on, but it can sit next to a SAML source and next to OIDC sources that only validate tokens. See the SSO overview.