Skip to content

Key-Encryption Key Provider Failed

URI: https://docs.ankatech.co/errors/kek-destruction-provider-failed
HTTP Status: 502 Bad Gateway

When you see this

A destruction of a tenant key-encryption key, or the cancel of one, reached the provider or HSM that holds the key, and the call failed.

  • On a destruction, the request itself never answers this error: it calls no provider. The provider or HSM is called by the destruction pass when the platform's waiting period ends. When it refuses that call and the key is known to be unchanged (the refusal came before anything that destroys a key was sent, or, after it was sent, as a non-retryable answer, a denied permission or an invalid request, on the first attempt), the key is RETIRED again with the refusal reason PROVIDER_REFUSED, a kek-destruction.execution-failed row with outcome FAILURE, stage PROVIDER and this problem type is filed in the audit trail, and the platform alert kek.destruction.failed is raised; it counts the refusal for 7 days, or until a new destruction of the key is requested. A new destruction is a new request, with a new waiting period. A call that was sent and got no usable answer is not a refusal: the provider may have acted, so the key stays PENDING_DESTRUCTION and executing, and a FAILURE row with stage PROVIDER_INDETERMINATE is filed. Once the call can no longer be running, a later pass reads the provider: a key destroyed is recorded destroyed, a scheduled destruction is recorded with its due date, and a key the provider still holds with nothing scheduled returns to held and due (stage EXECUTION_RECOVERED) and is executed again with a fresh recount.
  • On a cancel, the key stays PENDING_DESTRUCTION on the platform. The detail says which of two cases it is: the provider refused before changing anything (the key is unchanged), or it gave no usable answer, so whether it cancelled the destruction is not known.

A tenant key-encryption key is destroyed at its provider or HSM, never only in the platform's records. A destruction request moves a RETIRED key to PENDING_DESTRUCTION and calls no provider: the platform holds the destruction for the deployment's waiting period (30 days by default), and until it ends a cancel returns the key to RETIRED with no provider call. When the period ends the platform checks the key again and only then asks its provider or HSM to destroy it; the key becomes DESTROYED only once a read of the provider confirms it gone. Until then the destruction can be cancelled while the key object still exists, which returns the key to RETIRED.

Common Causes

  • The provider refused the call with an error other than a denied permission, or the call could not be prepared: the provider's client could not be built, or the HSM could not be read, or does not carry this environment's claim, before the destruction or the cancel was sent.
  • On a cancel, the HSM's token could not be read, or the provider failed after the cancel was sent, which may leave the key partly restored.
  • extensions.provider names the provider by its role: MANAGED_TIER_KEY_MANAGEMENT_SERVICE or HSM. The provider's own message, endpoint, account and key coordinates are never returned.

Response Example

{
  "type": "https://docs.ankatech.co/errors/kek-destruction-provider-failed",
  "title": "Key-Encryption Key Provider Failed",
  "status": 502,
  "detail": "The key-encryption key's provider (the managed tier's key management service) refused the call before changing anything; the key-encryption key is unchanged. Retry later.",
  "instance": "/api/v3/admin/platform/tenants/8f14e45f-ceea-467a-9575-0d5b2a1f3c11/key-custody/keks/3c1f7a9e-2b44-4e0d-8f6a-91d2c7b5e0aa/cancel-destruction",
  "timestamp": 1793696400,
  "extensions": {
    "provider": "MANAGED_TIER_KEY_MANAGEMENT_SERVICE",
    "requestId": "9c41e7a2-5b08-4d3f-a6e1-2f7c90b4d815"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

How to Resolve

  1. Read the key's lineage entry. After a destruction refused at its execution it is RETIRED; request the destruction again once the provider is available, which starts a new waiting period.
  2. After a cancel whose detail says the outcome is not known, read the lineage entry again before retrying: the key stays PENDING_DESTRUCTION until a cancel succeeds or the provider confirms it destroyed.
  3. If it persists, check the provider's availability and the managed tier's state.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.