Elastic

F Elastic Cloud Enterprise (ECE orchestrator API)

Automation reaches the self-managed ECE orchestrator API with a static API key (or a username and password traded for a JWT); keys default to a three-month expiry but can be set to never, can be rotated by API, but cannot be scoped below their owner, show no last-used time, and no workload federation exists. Platform snapshot repositories want a pasted S3 access key, GCS service-account JSON key, or Azure SAS token.

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

Inbound F

How a workload running anywhere authenticates to this product.

Static ECE API key sent in the Authorization header (created in the Cloud UI or via the API, default three-month expiry); the alternative is a native/LDAP/AD username and password exchanged at /users/auth/_login for a JWT bearer token. No OIDC or JWT federation for workloads.

elastic.co checked 2026-10-14
“The Elastic Cloud Enterprise RESTful APIs support both key-based and token-based authentication. Key-based is generally the preferred method.”
elastic.co checked 2026-10-14
“For token-based API authentication, you can use the same username and password that you use to log into the Cloud UI.”
elastic.co checked 2026-10-14
“"securityDefinitions":{"apiKey":{"type":"apiKey","name":"Authorization","in":"header"},"basicAuth":{"type":"basic"}}”
elastic.co checked 2026-10-14
“The second method uses the `user` and `pass` values to obtain a valid JWT token, that token is then used as the Authentication Bearer header for every API call.”
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`.”

The only security schemes in the ECE OpenAPI spec are an API key header and HTTP basic; the /users/auth/_login JWT is minted from a username and password, so it is a static secret by another name, not federation (ecctl refreshes it every minute but still holds the password). SAML, LDAP and Active Directory provider profiles exist but are for humans signing into the Cloud UI. ecctl (--api-key or --user/--pass) and the `ec` Terraform provider (apikey, or username/password for ECE only) inherit the same static options. API keys cannot be created for the built-in admin and readonly users, so automation needs a named native/LDAP/AD user. Host enrollment: adding allocator/proxy/coordinator hosts uses roles tokens, either ephemeral (auto-revoked after one hour) or persistent ("Available ... indefinitely. Can be revoked at any time."), per https://www.elastic.co/docs/deploy-manage/deploy/cloud-enterprise/generate-roles-tokens. Applies to self-managed ECE only; ECE itself requires an Elastic license (Enterprise-level features), but API keys are not an extra-cost add-on, so no tier gate is recorded.

Outbound F

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

Platform-level snapshot repositories (the automatic found-snapshots backups) are configured with a pasted static credential: S3 access key and secret key, a GCS service-account JSON key with storage.admin, an Azure storage SAS token, or MinIO access/secret keys.

elastic.co checked 2026-10-14
“In Elastic Cloud Enterprise (ECE), snapshot repositories are managed at the platform level and can be assigned to individual deployments. When a repository is assigned to a deployment, a snapshot is taken every 30 minutes by default.”
elastic.co checked 2026-10-14
“All repository options must be specified, as there are no default values.”
elastic.co checked 2026-10-14
“The secret key to use for authentication.”
elastic.co checked 2026-10-14
“The service account should be granted the role of storage.admin so that Elasticsearch clusters can read, write, and list the bucket objects.”
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
“"sas_token": "AZURE SAS_TOKEN",”
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.”

ECE is self-managed, so these credentials live in the customer's own ECE installation (and deployment keystores), not with Elastic; this is still the product reaching into customer cloud storage with a long-lived secret the customer hands it. Repositories checked: S3 (access key + secret key fields on the platform form), GCS (service-account JSON key in the gcs.client.*.credentials_file secure setting, storage.admin role), Azure (SAS token in the repository JSON), MinIO (access/secret keys). The deployment-level S3 guide (shared by ECH and ECE) gives a bucket-scoped IAM-user policy, and SAS tokens are inherently scoped, but the GCS guide asks for storage.admin and none of the ECE repository pages explain rotation, so the bar for D is not met. Plain self-managed Elasticsearch can pick up EC2 instance-role or EKS web-identity credentials when no keys are set; the ECE pages do not document that path for ECE-orchestrated containers, so it was not credited. No other outbound connectors into customer clouds or SaaS were found for the orchestrator; allocator/runner hosts are infrastructure the customer installs ECE on, enrolled with roles tokens (see inbound notes).

Hygiene for any static credential the product still issues

✗ Expiry enforceable	Fails: the Cloud UI defaults to a three-month expiry and responses carry an X-Elastic-Api-Key-Expiration header, but any user can choose Never, no platform policy to cap lifetime is documented, and the API's `expiration` field is optional. A changeable UI default is not an enforced expiry (same call as cloudflare-api, doppler-secrets and elasticsearch). elastic.co checked 2026-10-14 “By default, the API key will expire three months after its creation date, but you can set the 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 /users/auth/keys creates a key; DELETE /users/auth/keys/{api_key_id}, DELETE /users/{user_id}/auth/keys/{api_key_id} and bulk DELETE /users/auth/keys/_all revoke them. ecctl wraps these as `ecctl auth key create\|delete\|list\|show`. elastic.co checked 2026-10-14 “"summary":"Create API key","description":"Creates a new API key.","operationId":"create-api-key"” elastic.co checked 2026-10-14 “Creates a new API key for the current authenticated user.”
✓ Scoped keys	Marginal pass. The key itself cannot be scoped (per-key role_assignments are explicitly unavailable in self-hosted ECE), but a purpose-built native user can be created for automation and given one of the pre-built roles (Platform admin, Platform viewer, Deployment manager, Deployment viewer), and its keys carry only that role. That matches the rubric's "purpose-built machine principal" allowance; roles are coarse (no custom roles, no per-deployment scoping). A reader who treats native users as human accounts would fail this check; inbound is F either way since expiry also fails. elastic.co checked 2026-10-14 “The API key has the same permissions as the API key owner.” elastic.co checked 2026-10-14 “The optional roles for the API key. Takes the role of the creator if not specified. Currently unavailable in self-hosted ECE.” elastic.co checked 2026-10-14 “In addition to the system admin and readonly users, you can create additional users and assign pre-built roles to control access to platform operations, deployment assets, or API calls.”
✗ Last-used visible	ApiKeyResponse exposes id, user_id, organization_id, description, key, creation_date, expiration_date and role_assignments; no last-used field. The docs mention only creation and expiry, not usage. elastic.co checked 2026-10-14 “The response model for an API key.” elastic.co checked 2026-10-14 “When you use an API key to authenticate, the API response header X-Elastic-Api-Key-Expiration indicates the key’s expiration date.”
✗ Leak revocation	GitHub lists only "Elastic Cloud API Key" and "Elastic Stack API Key", both as non-partner (user alert / push protection) patterns, so Elastic is not notified for automatic revocation. Neither pattern is described as covering self-managed ECE API keys, and an ECE installation is not reachable by a vendor revocation service in any case. docs.github.com checked 2026-10-14 “Elastic Cloud API Key”

Notes

Scope: the ECE orchestrator's own REST API (platform and deployment lifecycle), self-managed only. Elastic Cloud Hosted and Serverless use the Elastic Cloud API, graded separately as elastic-cloud-api (its keys support role assignments, which ECE's do not). Data-plane access to ECE-orchestrated deployments uses Elasticsearch API keys and realms (elasticsearch card); Kibana and Fleet ride on those (kibana, elastic-agent-fleet cards). Not graded separately: Elastic Cloud on Kubernetes (ECK) is a Kubernetes operator with no orchestrator API of its own, so access is governed by Kubernetes RBAC on its custom resources ("Built on the Kubernetes Operator pattern, Elastic Cloud on Kubernetes (ECK) extends the basic Kubernetes orchestration capabilities", https://www.elastic.co/docs/deploy-manage/deploy/cloud-on-k8s); Logstash is a client of Elasticsearch that authenticates with user/password, cloud_auth or an Elasticsearch API key ("Authentication to a secure Elasticsearch cluster is possible using one of the user/password, cloud_auth or api_key options", https://www.elastic.co/docs/reference/logstash/plugins/plugins-outputs-elasticsearch), so it is covered by the elasticsearch card. Grade moves to C or better only if ECE accepts federated workload tokens or another non-static bootstrap.

Badge

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