Elastic

F Elastic Cloud control plane API (Hosted and Serverless)

The Elastic Cloud API, the ec Terraform provider and ecctl accept only a static organization API key; keys default to a three-month expiry and can be role-scoped, but "Never" is allowed and cannot be forbidden, and there is no last-used view or GitHub partner revocation. Into your cloud, BYOK key access is keyless on AWS, Azure and GCP, while custom snapshot repositories still want static cloud keys.

Docs: elastic.co · Checked 2026-10-14 · source YAML · dispute via PR

Inbound F

How a workload running anywhere authenticates to this product.

Static Elastic Cloud API key (Authorization: ApiKey) owned by the organization, with roles and an expiry set at creation; no OIDC, workload identity or token-exchange path exists for the control plane.

elastic.co checked 2026-10-14
“An Elastic Cloud API key belongs to the organization and is not tied to the user who created it. When a key is created, it is assigned specific roles that control its access to organizational resources.”
elastic.co checked 2026-10-14
“API keys are used to authenticate requests to the Elastic Cloud Serverless REST API.”
elastic.co checked 2026-10-14
“"securityDefinitions":{"apiKey":{"type":"apiKey","name":"Authorization","in":"header"}}”
raw.githubusercontent.com checked 2026-10-14
“Elasticsearch Service (ESS) only supports `apikey`. Elastic Cloud Enterprise (ECE) supports `apikey` or a combination of `username` and `password`.”
elastic.co checked 2026-10-14
“Elastic Cloud uses API keys to authenticate users against its API. Additionally, it supports the usage of JWT to validate authenticated clients. The preferred authentication method is API keys.”

Applies to Elastic Cloud Hosted and Serverless (both are managed through api.elastic-cloud.com with the same key). The Cloud API and Serverless API OpenAPI specs declare a single security scheme, the ApiKey header; nothing in the specs or docs offers OIDC, GitHub Actions, cloud workload identity or a token exchange for the control plane. ecctl's JWT path is a username/password login (ECE and ESS Private), not federation. Organization SAML SSO exists for humans only. Serverless keys can optionally carry Elasticsearch and Kibana API access for projects; Hosted deployment data-plane access uses Elasticsearch API keys (see `elasticsearch`, `kibana`). ECE's own API keys are graded on `elastic-cloud-enterprise`. No tier gate: API keys are available on every Elastic Cloud subscription.

Outbound Brequires Enterprise (customer-managed encryption keys)

How this product reaches into your cloud, repos, or other SaaS.

Customer-managed encryption keys are keyless on all three clouds (AWS KMS key policy granting Elastic's AWS organization, Azure admin consent to Elastic's multi-tenant app, GCP IAM grant to Elastic's service accounts), but custom snapshot repositories on Hosted deployments want a static AWS access key, GCS service-account JSON key or Azure storage key in the keystore.

elastic.co checked 2026-10-14
“Encryption at rest using customer-managed keys is only available for the Enterprise subscription level.”
elastic.co checked 2026-10-14
“"aws:PrincipalOrgPaths": "o-ygducmlz12/r-e5t3/ou-e5t3-fzpdq76p/ou-e5t3-ysfcmd95/ou-e5t3-hwt05su3/*"”
elastic.co checked 2026-10-14
“Using the ID that you copied, create a new service principal for Elastic Cloud in your Azure tenant. The service principal grants Elastic Cloud access to interact with your RSA key.”
elastic.co checked 2026-10-14
“Elastic Cloud uses two service principals to encrypt and decrypt data using your key. You must grant these services access to your key before you create your deployment.”
elastic.co checked 2026-10-14
“Next, create an IAM user, copy the access key ID and secret, and configure the following user policy. This is important to make sure the access keys, which you will need to provide to your cluster, can only access the intended bucket.”
elastic.co checked 2026-10-14
“Save the service account key in JSON file format. You are going to use it later to configure your Elasticsearch deployment for snapshotting.”
elastic.co checked 2026-10-14
“Follow the Microsoft documentation to set up an Azure storage account with an access key, and then create a container .”
elastic.co checked 2026-10-14
“AWS PrivateLink connects your Virtual Private Cloud (VPC) to the AWS-hosted services that you use, treating them as if they were in your VPC.”

Checked: BYOK on AWS, Azure and GCP (Hosted only; keyless, no secret handed over); private connectivity (AWS PrivateLink, Azure Private Link, GCP Private Service Connect: endpoints the customer creates toward Elastic, no credential); AWS and GCP Marketplace subscriptions and Azure Native logs (Azure diagnostic settings push to Elastic). None of those ask for a customer secret. The AWS BYOK grant is a key-policy statement with Principal "*" constrained by aws:PrincipalOrgPaths to Elastic's AWS organization, not a role with external ID; still keyless. Static keys: custom snapshot repositories on Hosted (S3 access key ID/secret, GCS service-account JSON, Azure storage account key) entered in the deployment's Elasticsearch keystore through the Cloud console; the docs do give a bucket-scoped IAM policy. Those snapshot connections are made by Elasticsearch itself and are also relevant to the `elasticsearch` card. Without the Enterprise tier the only documented reach-in is the static-key snapshot path.

Hygiene for any static credential the product still issues

✗ Expiry enforceable	Fails: the console defaults to three months and Elastic emails before expiry, but "Never" is one click away, no organization policy to forbid it or cap the lifetime is documented, and the Create API key endpoint treats expiration as optional. A changeable UI default is not an enforced expiry (same call as cloudflare-api, doppler-secrets and elasticsearch). An org-level maximum-lifetime policy would flip this check and lift inbound to D. elastic.co checked 2026-10-14 “By default, API keys expire after three months. You can set the expiration to a different preset value or to a specific date, up to one year. If you need the key to work indefinitely, you can set its expiration to Never .” elastic.co checked 2026-10-14 “The optional expiration for the API key, provided as a duration (ex: '1d', '3h')”
✓ Rotation via API	POST, GET and DELETE on /api/v1/users/auth/keys create, list and revoke keys. elastic.co checked 2026-10-14 “You can create an API key using the Create API key API.” elastic.co checked 2026-10-14 “Delete or invalidate API keys.”
✓ Scoped keys	Keys belong to the organization rather than a user and take explicit roles scoped to specific deployments or projects. Caveat from the API spec: if role_assignments is omitted the key "Takes the role of the creator if not specified". elastic.co checked 2026-10-14 “You can grant a cloud API key the same types of roles that you assign to users : organization-level roles, cloud resource access roles, and connected cluster access roles.” elastic.co checked 2026-10-14 “Roles can be scoped to specific deployments or to all deployments.”
✗ Last-used visible	The ApiKeyResponse schema has id, user_id, organization_id, description, key, creation_date, expiration_date and role_assignments, with no last-used field, and the API keys docs page does not mention last use. elastic.co checked 2026-10-14 “The response model for an API key.”
✗ Leak revocation	GitHub detects Elastic Cloud API keys as a user alert with push protection, but the Partner column is ✗, so a leaked key is not reported to Elastic for automatic revocation. Same for the Elastic Stack API Key pattern. docs.github.com checked 2026-10-14 “\| Elastic \| Elastic Cloud API Key \| elastic_cloud_api_key \| ✗ \| ✓ \| ✓ \| ✗ \| ✗ \| ✗ \|”

Notes

One of five Elastic cards: `elastic-cloud-api` (this), `elasticsearch`, `kibana`, `elastic-agent-fleet`, `elastic-cloud-enterprise`. Hosted deployment data access, Kibana and Fleet authenticate with Elasticsearch API keys, graded separately. Grade moves to B or A only if the Cloud API accepts a federated token (GitHub Actions OIDC, cloud workload identity or a bring-your-own issuer). An org policy that forbids "Never" would lift inbound to D; a last-used timestamp and GitHub partner revocation would add further hygiene passes.

Badge

[![wif.tax grade](https://wif.tax/badge/elastic-cloud-api.svg)](https://wif.tax/p/elastic-cloud-api/)