apache/hadoop · error · IllegalArgumentException

'%s' not found

Error message

'%s' not found

What it means

KeyAuthorizationKeyProvider.verifyKeyVersionBelongsToKey (line 255) runs during EEK decryption: it looks up the encryption key version name (e.g. mykey@0) in the backing KeyProvider via getKeyVersion. If the provider returns null — no such version exists in the keystore — it throws IllegalArgumentException "'<versionName>' not found" (HTTP 400 to REST clients). This is a data/URL integrity check on the EDEK's version reference, not an authorization failure.

Source

Thrown at hadoop-common-project/hadoop-kms/src/main/java/org/apache/hadoop/crypto/key/kms/server/KeyAuthorizationKeyProvider.java:255

  @Override
  public EncryptedKeyVersion generateEncryptedKey(String encryptionKeyName)
      throws IOException, GeneralSecurityException {
    readLock.lock();
    try {
      doAccessCheck(encryptionKeyName, KeyOpType.GENERATE_EEK);
      return provider.generateEncryptedKey(encryptionKeyName);
    } finally {
      readLock.unlock();
    }
  }

  private void verifyKeyVersionBelongsToKey(EncryptedKeyVersion ekv)
      throws IOException {
    String kn = ekv.getEncryptionKeyName();
    String kvn = ekv.getEncryptionKeyVersionName();
    KeyVersion kv = provider.getKeyVersion(kvn);
    if (kv == null) {
      throw new IllegalArgumentException(String.format(
          "'%s' not found", kvn));
    }
    if (!kv.getName().equals(kn)) {
      throw new IllegalArgumentException(String.format(
          "KeyVersion '%s' does not belong to the key '%s'", kvn, kn));
    }
  }

  @Override
  public KeyVersion decryptEncryptedKey(EncryptedKeyVersion encryptedKeyVersion)
          throws IOException, GeneralSecurityException {
    readLock.lock();
    try {
      verifyKeyVersionBelongsToKey(encryptedKeyVersion);
      doAccessCheck(
          encryptedKeyVersion.getEncryptionKeyName(), KeyOpType.DECRYPT_EEK);
      return provider.decryptEncryptedKey(encryptedKeyVersion);
    } finally {

View on GitHub (pinned to 2add963021)

Solutions

  1. Verify the version exists: GET /v1/key/{name}/_metadata lists material versions for the key; fix the versionName in the decrypt call
  2. If EDEKs are stale because the keystore was recreated, re-encrypt the data with fresh EEKs (generate again and rewrite)
  3. Make sure each environment (dev/prod) uses its own keystore and clients never send EDEKs across environments

Example fix

# before
POST /v1/keyversion/mykey@9/_eek?eek_op=decrypt
# after (version that exists per key metadata)
POST /v1/keyversion/mykey@0/_eek?eek_op=decrypt
Defensive patterns

Strategy: validation

Validate before calling

// Before decrypt, confirm the version exists on this provider
KeyVersion kv = provider.getKeyVersion(ekv.getEncryptionKeyVersionName());
if (kv == null) throw new IllegalStateException("stale EDEK: version no longer in keystore, re-encrypt data");

Try / catch

try { provider.decryptEncryptedKey(ekv); } catch (IllegalArgumentException e) { if (e.getMessage().endsWith("not found")) { /* stale/foreign version: re-encrypt path */ } else throw e; }

Prevention

When it happens

Trigger: POST /v1/keyversion/{versionName}/_eek?eek_op=decrypt where versionName does not exist in the backing keystore: typo'd or truncated version name in the URL, or EEK material produced against a different keystore (e.g. keystore restored from backup, key deleted and recreated, or a dev/test KMS mixup).

Common situations: Clients replaying old EDEKs after the key store was wiped/re-created; copy-pasting between environments; version-name formatting mistakes (mykey@0 vs mykey@1); the underlying keystore file replaced underneath the KMS.

Related errors


AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/7360a585a3268008. Report an issue: GitHub.