apache/hadoop · error · AuthorizationException

User:%s not allowed to do '%s' on '%s'

Error message

User:%s not allowed to do '%s' on '%s'

What it means

KMSACLs.assertAccess (single-ACL variant, KMS.java line 274 in KMSACLs.java) is invoked before every KMS operation. It checks the calling user against the KMS-level ACL types configured in kms-acls.xml (hadoop.kms.acl.<TYPE>, e.g. CREATE, GET, DELETE, ROLLOVER, SET_KEY_MATERIAL, GENERATE_EEK, DECRYPT_EEK, GET_KEYS, GET_CURRENT_KEY). If hasAccess fails it marks the unauthorized-calls meter, writes an audit 'unauthorized' record, and throws AuthorizationException, surfaced to REST clients as HTTP 403.

Source

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

        } else {
          LOG.debug("user is in {}" , blacklist.getAclString());
        }
      }
    }
    if (LOG.isDebugEnabled()) {
      LOG.debug("User: [{}], Type: {} Result: {}", ugi.getShortUserName(),
          type.toString(), access);
    }
    return access;
  }

  public void assertAccess(KMSACLs.Type aclType,
      UserGroupInformation ugi, KMSOp operation, String key)
      throws AccessControlException {
    if (!KMSWebApp.getACLs().hasAccess(aclType, ugi)) {
      KMSWebApp.getUnauthorizedCallsMeter().mark();
      KMSWebApp.getKMSAudit().unauthorized(ugi, operation, key);
      throw new AuthorizationException(String.format(
          (key != null) ? UNAUTHORIZED_MSG_WITH_KEY
                        : UNAUTHORIZED_MSG_WITHOUT_KEY,
          ugi.getShortUserName(), operation, key));
    }
  }

  public void assertAccess(EnumSet<Type> aclTypes,
      UserGroupInformation ugi, KMSOp operation, String key)
      throws AccessControlException {
    boolean accessAllowed = false;
    for (KMSACLs.Type type : aclTypes) {
      if (KMSWebApp.getACLs().hasAccess(type, ugi)){
        accessAllowed = true;
        break;
      }
    }

    if (!accessAllowed) {

View on GitHub (pinned to 2add963021)

Solutions

1. Add the short username (or a group/host range) to the relevant hadoop.kms.acl.<TYPE> entry in kms-audit... kms-acls.xml and let the ACL reload pick it up (or restart KMS)
2. Verify which user is actually being checked: the message shows ugi.getShortUserName(), which for proxy/doAs calls is the end user, not the proxy
3. Check the KMS audit log line written just before the exception to confirm the operation and key involved
4. Ensure the blacklist (hadoop.kms.blacklist.<TYPE>) is not overriding an allow entry for this user

Example fix

<!-- kms-acls.xml before -->
<property><name>hadoop.kms.acl.GET</name><value>hdfs</value></property>
<!-- after: allow the hive service user too -->
<property><name>hadoop.kms.acl.GET</name><value>hdfs,hive</value></property>

try { kms.createKey(name, options); } catch (AuthorizationException e) { // HTTP 403 // surface 'user not in hadoop.kms.acl.CREATE' to operators, do not retry }

When it happens

Trigger: Any KMS REST or KeyProvider call by a user who is not in the applicable hadoop.kms.acl.<TYPE> entry (and not matched by the default hadoop.kms.acl.ACL or the blacklist rules) — e.g. a GET /v1/key/name by a user missing the GET ACL, or key creation without the CREATE ACL. The key argument is non-null for key-scoped operations and null for others; the message formats user, KMSOp and key name.

Common situations: Fresh KMS install where kms-acls.xml still has restrictive defaults; adding a new service user (HDFS, Hive, HBase) but forgetting to add it to the ACLs; ACL hot-reload after someone tightened hadoop.kms.acl.GET; proxy-user scenarios where the doAs user is the one being checked.

Related errors

• User [%s] is not authorized to create key !!
• User [%s] is not authorized to perform [%s] on key with ACL
• Null protocol not authorized
• User {} is not authorized for protocol {}: {}
• Host {} is not authorized for protocol {}

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