Kibana UI displays generic error when API key expires or least‑privilege role blocks access

Short answer

Kibana cannot silently renew an expired API key because an API key is a terminal credential; it carries no refresh token and Kibana does not hold the owner's primary password needed to mint a new one. The generic banner appears because Kibana relays coarse 401 (Unauthorized) and 403 (Forbidden) responses from the Elasticsearch security realm. Although they look identical in the browser, they represent distinct failures: one of identity (expiry) and one of permission (privilege).

Confirmed vs. likely behavior

Confirmed: Elasticsearch returns HTTP 401 for expired or invalidated API keys and HTTP 403 for valid credentials that lack a required privilege. Kibana surfaces both as generic banners, but the Kibana server log records the underlying security_exception and the real status code.

Likely: If a previously working dashboard suddenly fails, the API key has probably expired or been invalidated. If the error appears from the first login for a new user, a missing role privilege is the more consistent explanation.

What silent renewal would require

To renew an expired key without user interaction, Kibana would need a mechanism beyond the key itself:

• A refresh-style flow: an OAuth2-like pattern where a longer-lived refresh credential can request a new short-lived access token. Static API keys do not support this.
• Stored primary credentials: keeping the creating user's password server-side to generate replacement keys, which is a serious security regression and not recommended.

Note that API keys only expire if created with an explicit expiration. Keys created without one persist until manually invalidated or until the owning user's credentials change.

Surfacing privilege details in the UI

The message is generic partly to avoid leaking information (revealing which indices or features exist) to unauthorized users. To give actionable feedback, the UI would need to:

1. Intercept the 403 response for the requested feature or index pattern.
2. Call the Elasticsearch _has_privileges API for the current user and resource.
3. Map the missing privilege (for example, a Kibana feature privilege or index read access) to a human-readable message.

Does OIDC or SAML change this?

With OIDC or SAML, token renewal shifts to the Identity Provider. When the IdP session expires, Kibana typically redirects to the IdP login page instead of showing a generic API error, so the 401 path improves. However, authorization (403) decisions still come from Elasticsearch role mappings, so the generic access-denied behavior for missing privileges persists regardless of the SSO provider.

Verification

Reproduce the error, then check the Kibana server log for the Elasticsearch response status (401 vs 403). You can also query Elasticsearch directly:

# Confirm whether the key is still valid and when it expires
GET /_security/api_key

# Check whether the user has the required privileges
GET /_security/user/_has_privileges
{
  "index": [{ "names": ["your-index-*"], "privileges": ["read"] }],
  "application": [{
    "application": "kibana-.kibana",
    "privileges": ["feature_discover.read"],
    "resources": ["*"]
  }]
}

After fixing the key or role, reload Kibana in an incognito window so a cached session does not mask the result. Exact UI wording and status codes vary by Elastic Stack version, so trust the logs over the browser banner.