apache/hadoop · error · AuthorizationException

User [%s] is not authorized to perform [%s] on key with ACL

Error message

User [%s] is not authorized to perform [%s] on key with ACL name [%s]!!

What it means

KeyAuthorizationKeyProvider.checkAccess (line 148) guards every key operation (READ, GENERATE_EEK, DECRYPT_EEK, ROLLOVER, DECRYPT, ENCRYPT, ...). Access requires an existing key ACL entry key.acl.<aclname>.<OP> (or key.acl.<aclname>.ALL) in kms-acls.xml that contains the caller. Otherwise it throws AuthorizationException 'User [<u>] is not authorized to perform [<op>] on key with ACL name [<acl>]!!' -> HTTP 403.

Source

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

      success = acls.isACLPresent(aclName, KeyOpType.MANAGEMENT) &&
          (acls.hasAccessToKey(aclName, ugi, KeyOpType.MANAGEMENT)
          || acls.hasAccessToKey(aclName, ugi, KeyOpType.ALL));
    }
    if (!success)
      throw new AuthorizationException(String.format("User [%s] is not"
          + " authorized to create key !!", ugi.getShortUserName()));
  }

  private void checkAccess(String aclName, UserGroupInformation ugi,
      KeyOpType opType) throws AuthorizationException {
    Preconditions.checkNotNull(aclName, "Key ACL name cannot be null");
    Preconditions.checkNotNull(ugi, "UserGroupInformation cannot be null");
    if (acls.isACLPresent(aclName, opType) &&
        (acls.hasAccessToKey(aclName, ugi, opType)
            || acls.hasAccessToKey(aclName, ugi, KeyOpType.ALL))) {
      return;
    } else {
      throw new AuthorizationException(String.format("User [%s] is not"
          + " authorized to perform [%s] on key with ACL name [%s]!!",
          ugi.getShortUserName(), opType, aclName));
    }
  }

  @Override
  public KeyVersion createKey(String name, Options options)
      throws NoSuchAlgorithmException, IOException {
    writeLock.lock();
    try {
      authorizeCreateKey(name, options, getUser());
      return provider.createKey(name, options);
    } finally {
      writeLock.unlock();
    }
  }

  @Override

View on GitHub (pinned to 2add963021)

Solutions

Add the missing per-op entry key.acl.<aclname>.<OP> (e.g. key.acl.mykey.DECRYPT_EEK) with the user/group, or grant key.acl.<aclname>.ALL
Match the ACL name exactly: it is the key's key.acl.name attribute, which can differ from the key name
Wait for kms-acls.xml hot reload (or restart KMS) and retry; verify with the KMS audit log which op was denied

Example fix

<!-- kms-acls.xml -->
<property>
  <name>key.acl.mykey.DECRYPT_EEK</name>
  <value>hdfs,hive</value>
</property>

Defensive patterns

Strategy: try-catch

Try / catch

try { kpExt.generateEncryptedKey(name); } catch (AuthorizationException e) { /* 403: add user to key.acl.<name>.GENERATE_EEK (or .ALL) */ log.warn("key ACL denied", e); }

Prevention

Grant per-op key ACLs for every operation each service account performs (GENERATE_EEK, DECRYPT_EEK, ROLLOVER, ...)
Review key ACL coverage when onboarding new HDFS encryption zones
Treat READ as insufficient for EEK flows by design

When it happens

Trigger: Operations like rolloverKey, generateEncryptedKey, decryptEncryptedKey, getKeyVersion on a key whose ACL name has no entry for that specific op type — e.g. a user allowed GENERATE_EEK but issuing DECRYPT_EEK, or decrypting EEKs of a key with only key.acl.<name>.READ defined.

Common situations: Zone/crypto service accounts missing DECRYPT_EEK on an encryption-zone key; after key ACL refactors an op-specific entry was dropped; clients assuming READ covers EEK operations (it does not: EEK ops need GENERATE_EEK/DECRYPT_EEK entries).

Related errors

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