HDDS-14207. Inconsistent Ozone admin check

[Gargi-jais11]

What changes were proposed in this pull request?

Ozone administrators have super privileges in Ozone system. Some actions are only allowed by Ozone administrators.
While currently the ozone administrator check is not consistent. Some codes, check permission is enabled first, then check if user has the admin privilege. For example, OMFinalizeUpgradeRequest#validateAndUpdateCache

if (ozoneManager.getAclsEnabled()) {
        UserGroupInformation ugi = createUGIForApi();
        if (!ozoneManager.isAdmin(ugi)) {
          throw new OMException("Access denied for user " + ugi + ". "
              + "Superuser privilege is required to finalize upgrade.",
              OMException.ResultCodes.ACCESS_DENIED);
        }
      }

Some codes, check if user has the admin privilege directly, for example, OzoneManager#triggerSnapshotDefrag

    final UserGroupInformation ugi = getRemoteUser();
    // Check Ozone admin privilege
    if (!isAdmin(ugi)) {
      throw new OMException("Only Ozone admins are allowed to trigger "
          + "snapshot defragmentation manually", PERMISSION_DENIED);
    }

Proposed Fix:
ACLs are a subset of authorization, so we should not change ozone.acl.enabled to cover more than that instead for a single flag for authorization, added a new ozone.authorization.enabled property to cover both ACL and admin check.

• Added ozone.authorization.enabled new config with default value: true
• New Flow for Admin operations and Object operations is:

Admin Operations (non-objects):
  SCM decommission, OM upgrade, Recon endpoints, etc.
  ↓
  Check: ozone.security.enabled && ozone.authorization.enabled
  ↓
  Does NOT depend on ozone.acl.enabled 

Object Operations (volumes/buckets/keys):
  Create bucket, read key, delete volume, etc.
  ↓
  Check: ozone.security.enabled && ozone.authorization.enabled && ozone.acl.enabled
  ↓
  Depends on ALL three properties

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-14207

How was this patch tested?

Updated the existing testcases to work according to the admin and object permissions enabled basis.
Tested Manually in docker cluster in unsecure and secure environment for all commands, pasting result of some of them:

1. Unsecure Cluster:

• ozone.security.enabled=false, ozone.authorization.enabled=true and ozone.acl.enabled=false.

// Admin Operation: No permission denied for any nonadmin user as well
bash-5.1$ ozone admin scm transfer -n d7702a02-98bf-427e-8bf1-5dcd45ea3306
Transfer leadership successfully to d7702a02-98bf-427e-8bf1-5dcd45ea3306.               ✅

=============================================================================

// Object Operation: No permission denied for any nonadmin user as well
bash-5.1$ ozone sh volume create /volume2
bash-5.1$ ozone sh volume create /volume2/bucket.                              ✅

2. Secure Cluster :

• ozone.security.enabled=true, ozone.authorization.enabled=true and ozone.acl.enabled=false.

// Admin Operation: Permission denied for any nonadmin user
// om as user access granted
bash-5.1$ kinit -kt /etc/security/keytabs/om.keytab om/om@EXAMPLE.COM
bash-5.1$ ozone admin om transfer -r
Transfer leadership successfully to random node.        ✅

// testuser2 as user: Permission denied                        
bash-5.1$ kinit -kt /etc/security/keytabs/testuser2.keytab testuser2/om@EXAMPLE.COM
bash-5.1$ ozone admin scm transfer -r                           ❌
Access denied for user testuser2/om@EXAMPLE.COM. SCM superuser privilege is required.

=============================================================================

// Object Operation: No permission denied for any nonadmin user  as acl enabled is false 
bash-5.1$ kinit -kt /etc/security/keytabs/om.keytab om/om@EXAMPLE.COM
bash-5.1$ ozone sh volume create /volume2
bash-5.1$ ozone sh volume create /volume2/bucket.         ✅----------> om as user allowed operation 

bash-5.1$ kinit -kt /etc/security/keytabs/testuser2.keytab testuser2/om@EXAMPLE.COM
bash-5.1$ ozone sh volume create /vol2
bash-5.1$ ozone sh bucket create /vol1/buck2.         ✅-----------> testuser2(non-admin) allowed to create as acl is disabled

• ozone.security.enabled=true, ozone.authorization.enabled=true and ozone.acl.enabled=true

// Admin Operation: Permission denied for any nonadmin user
// om as user access granted
bash-5.1$ kinit -kt /etc/security/keytabs/om.keytab om/om@EXAMPLE.COM
bash-5.1$ ozone admin om transfer -r
Transfer leadership successfully to random node.                         ✅

// testuser2 as user: Permission denied
bash-5.1$ kinit -kt /etc/security/keytabs/testuser2.keytab testuser2/om@EXAMPLE.COM
bash-5.1$ ozone admin scm transfer -r                                                    ❌
Access denied for user testuser2/om@EXAMPLE.COM. SCM superuser privilege is required.

=============================================================================

// Object Operation: Permission denied for any nonadmin user  as acl is enabled 
bash-5.1$ kinit -kt /etc/security/keytabs/om.keytab om/om@EXAMPLE.COM
bash-5.1$ ozone sh volume create /volume2
bash-5.1$ ozone sh volume create /volume2/bucket.        ✅

bash-5.1$ kinit -kt /etc/security/keytabs/testuser2.keytab testuser2/om@EXAMPLE.COM
bash-5.1$ ozone sh bucket create /volume2/bucket2                          ❌
PERMISSION_DENIED User testuser2 doesn't have READ permission to access volume Volume:volume2       
bash-5.1$ ozone sh volume create /volume3                                         ❌
PERMISSION_DENIED User testuser2 doesn't have CREATE permission to access volume Volume:volume3    

[Gargi-jais11]

@adoroszlai and @ChenSammi Please review the patch.

[adoroszlai]

Thanks @Gargi-jais11 for the patch.

[adoroszlai]

Thanks @Gargi-jais11 for updating the patch.

[adoroszlai]

Please also check test failure in TestSecureOzoneRpcClient.

[Gargi-jais11]

Thanks @adoroszlai for pointing out, I am still working on the fix. Will mark the PR as ready for review once I fix those failures.

[adoroszlai]

Thanks @Gargi-jais11 for updating the patch, LGTM.

[ChenSammi]

We don't need to check isAdminAuthorizationEnabled() again here, as it's checked in the caller ozoneManager.getAclsEnabled().

The rest looks good to me.