[Bug report] Service admins cannot bootstrap RBAC system with no users

[bharos]

Version

main branch

Describe what's wrong

Service admins configured via gravitino.authorization.serviceAdmins cannot bootstrap the RBAC system in a fresh Gravitino installation. While they can create metalakes, they are blocked from creating users, roles, and granting permissions, rendering fresh installations with authorization enabled completely unusable.

I'm not sure if there's a way to add user ?

Error message and/or stacktrace

Error says user, ie. service admin is not authorized to do operations like add_user etc..

How to reproduce

Configure a fresh Gravitino instance with authorization enabled:

gravitino.authorization.enable=true
gravitino.authorization.serviceAdmins=admin

Start with empty database (no metalakes, no users, no roles)
As service admin "admin", attempt to:

# Step 1: Create metalake -  WORKS
POST /api/metalakes {"name": "production"}

# Step 2: Create user - FAILS
POST /api/metalakes/production/users {"name": "alice"}
# Error: "Not authorized - need METALAKE::OWNER || METALAKE::MANAGE_USERS"

# Step 3: Create role -  FAILS  
POST /api/metalakes/production/roles {"name": "admin_role", ...}
# Error: "Not authorized - need METALAKE::OWNER || METALAKE::CREATE_ROLE"

# Step 4: Grant role -  FAILS
PUT /api/metalakes/production/permissions/users/alice/grant
# Error: "Not authorized - need METALAKE::OWNER || METALAKE::MANAGE_GRANTS"

How can we proceed from initial state to add users etc.. to the system?

Additional context

No response

[bharos]

Actually, I realize the problem.
I think this is not a bug (well not entirely). I faced the issue because I created metalake using one service admin principal, and then changed the service admin to a different one (but then they can't do any operations).

But still that can be a bit concerning. What is a solution in that case in general

[roryqi]

Metalake owner can delete the metalake. We don't wanna to give permission to service admin to drop metalake. Service admin shouldn't have any permission after changing the owner of the metalake.

[bharos]

What was the ideology behind making the service admin only have the ability to create metalakes?
I am trying to understand why service admin was not created like admin in Hive (https://hive.apache.org/docs/latest/language/sql-standard-based-hive-authorization/) where they have pretty much all permissions?

Actually, will service admins technically have all permissions, if they create all the metalakes? Because they will be metalake owners for all the metalakes, right ? But I think here the difference is that they need to maintain that ownership and should not transfer it to another user

[roryqi]

What was the ideology behind making the service admin only have the ability to create metalakes? I am trying to understand why service admin was not created like admin in Hive (https://hive.apache.org/docs/latest/language/sql-standard-based-hive-authorization/) where they have pretty much all permissions?

Actually, will service admins technically have all permissions, if they create all the metalakes? Because they will be metalake owners for all the metalakes, right ? But I think here the difference is that they need to maintain that ownership and should not transfer it to another user

For design principals, We want to avoid using super user in our authorization system. We only build our authorization system based on owner and role. If we use Gravitno to build a Saas product. The service admin will be the Saas product provider, maybe Datastrato. The metalake owner will be the company platform team. If service admin can many things, it will burden the company user worry about security.