Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

JIRA : SQOOP-1834 and its sub ticketsSQOOP-2048 and its sub tickets

Problem

 

Sqoop 2 needs a pluggable role based access controller (RBAC), which is responsible for the authorization to Sqoop 2 resources, such as server, connector, link, job, submission etc.

Basic Idea

 

  • The access controller is pluggable

...

Resource, actions and rules

Server has three children: Connector, Link, Job.

  • It is a hierarchy mode. If a user has the privilege of {server, all}, then he/she has all privileges of {connector, all}, {link, all} and {job, all}.
  • If a user has the privilege of {job, all}, then he/she has both privileges of {job, read} and {job, write}.
  • If a user want to create a link, then he/she need to have the privilege of {server, create}
ResourceGlobal Namespace
Server
  • All
  • Read
  • Write
Connector
  • All
  • Read
Link
  • All
  • Read
  • Write
Job
  • All
  • Read
  • Write
ResourceGlobal NamespaceInstance
Connector
  • View
  • Use
  • View
  • Use
Link
  • Create
  • View
  • Update
  • Delete
  • Use
  • Enable
  • Disable
  • View
  • Update
  • Delete
  • Use
  • Enable
  • Disable
Job
  • Create
  • View
  • Update
  • Delete
  • Use
  • Enable
  • Disable
  • View
  • Update
  • Delete
  • Use
  • Enable
  • Disable
Submission
  • View
  • Create (Start job)
  • Update (Stop)
  • Delete
  • View
  • Update (Stop)
  • Delete
ActionPrivilege needed
show connector
  • connector viewread
show link
  • link viewread
create link
  • link server create (global)
  • connector useread
update link
  • link updatewrite
  • connector useread
delete link
  • link deletewrite
enable link
  • link enablewrite
disable link
  • link disablewrite
show job
  • job viewread
create job job create (global)
  • both links useread
update job
  • job updatewrite
  • both links useread
delete job
  • job deletewrite
enable job
  • job enablewrite
disable job
  • job disable
show submission
  • submission view
create submission (start job)
  • submission create (global)
  • job use
update submission (stop job)
  • submission update
  • write
start job
  • job write
stop job
  • job write
show submission
  • job read
delete submission
  • submission delete

 

Authorization framework

 

...

Code Block
#org.apache.sqoop.authorization.handler=org.apache.sqoop.security.DefaultAuthorizationHandler
#org.apache.sqoop.authorization.controller=org.apache.sqoop.security.DefaultAccessController
#org.apache.sqoop.authorization.validator=org.apache.sqoop.security.DefaultAuthorizationValidator

Image RemovedImage Added

  • Three Four metadata classes.
    • Role
    • principal
      • This class defines user or group.
      • Type: user, group, role.
      • principal could be granted a role. i.e. if we want to grant a admin role to user hadoop, then grantRole (principal (name=hadoop, type=user), role (name=admin)).
    • Resource
      • This class defines four resources in Sqoop 2.
      • Type: server, connector, link, job, submission.
    • Privilege
      • Action: createall, view, update, delete, use, enable, disableread, write.
      • with_grant_option: boolean, defines whether the role could grant this privilege to other role.

...

Code Block
Override
public void createLinkPrivilige() throws SqoopAccessControlException {
    List<Privilege> privileges;
    privileges.add(new Privilege(new Resource("Link", "1"), "Create", null));
    privileges.add(new Privilege(new Resource("Connector", "1"), "UseRead", null));
    AuthorizationManager.getAuthenticationHandler.checkPrivileges(privileges);
}

...

  • The grant/revoke privilege should be run in command line in Sqoop client
  • The commands are showed below

Create/Drop Role
Code Block
showCREATE role
showROLE role -role_name admin
show

DROP ROLE role -principal_name sqoop -principal_type user
show role -privilege_name my_privilege
add role –role_name admin
update role -old_role_name admin -new_role_name developer
remove role -role_name admin
 
show principal
show principal -principal_name sqoop
show principal -principal_type user
show principal -principal_name sqoop -principal_type user
show principal -role_name admin
add principal –principal_name sqoop -principal_type user
update principal -old_principal_name sqoop -old_principal_type user -new_principal_name hadoop -new_principal_type group
remove principal -principal_name sqoop
remove principal -principal_type user
remove principal -principal_name sqoop -principal_type user


grant role –role_name admin -principal_name sqoop -principal_type user
revoke role –role_name admin -principal_name sqoop -principal_type user
 
show resource
show resource -resource_type link
show resource -resource_name 1 -resource_type link
add resource -resource_name 1 -resource_type link -action create -with_grant_option true
update resource -old_resource_name 1 -old_resource_type link -new_resource_name 2 -new_resource_type link
remove resource -resource_type link
remove resource -resource_name 1 -resource_type link
 
show privilege
show privilege -privilege_name my_privilege
show privilege -resource_name 1 -resource_type link
show privilege -role_name admin
add privilege -resource_name 1 -resource_type link
update privilege -old_resource_name 1 -old_resource_type link -old_action create -old_with_grant_option true -new_resource_name 1 -new_resource_type link -new_action create -new_with_grant_option true
remove privilege -privilege_name my_privilege
remove privilege -resource_name 1 -resource_type link
remove privilege -resource_name 1 -resource_type link -action create -with_grant_option true
 
grant privilege –role_name admin -privilege_name my_privilege
revoke privilege –role_name admin -privilege_name my_privilege
 
SHOW ROLE

Grant/Revoke Roles

Code Block
GRANT ROLE role_name [, role_name] ... TO principal_specification [, principal_specification] ...

REVOKE ROLE role_name [, role_name] ... FROM principal_specification [, principal_specification] ...
principal_specification:
    USER user_name | GROUP group_name | ROLE role_name

Viewing Granted Roles

Code Block
SHOW ROLE GRANT principal_specification

SHOW PRINCIPAL ON ROLE role_name
 
principal_specification:
    USER user_name | GROUP group_name | ROLE role_name

Grant/Revoke Privileges

Code Block
GRANT privilege_action_type [, privilege_action_type] ... ON resource [, resource] ... TO principal_specification [, principal_specification] ... [WITH GRANT OPTION]

REVOKE [GRANT OPTION FOR] privilege_action_type [, privilege_action_type] ... ON resource [, resource] ... FROM principal_specification [, principal_specification] ...

REVOKE ALL PRIVILEGES FROM principal_specification [, principal_specification] ...

privilege_action_type:
    ALL | CREATE | READ | WRITE
 
resource:
    SERVER server_name | CONNECTOR connector_name | LINK link_name | JOB job_name
 
principal_specification:
    USER user_name | GROUP group_name | ROLE role_name

Viewing Granted Privileges

Code Block
SHOW GRANT principal_specification [ON resource]
 
principal_specification:
    USER user_name | GROUP group_name | ROLE role_name
 
resource:
    SERVER server_name | CONNECTOR connector_name | LINK link_name | JOB job_name

 

  • Restful call API is handled by org.apache.sqoop.handler.AuthorizationRequestHandlerAuthorizationEngine.java in sqoop-server
    • GET POST /authorization/v1roles/create
      • Create new role
      /
      • with {
      rid
      • name}
    • GET DELETE /v1authorization/role/principal/type/{typerole-name}

    • GET /nameauthorization/{name}
      • Return details about one particular role with id:rid
      • Return all roles the particular principal has with principal (type, name)
      • Return all of them if rid equals to "all"
    • PUT /v1/role
      • Create new role without id:rid
      • Update existing role with id:rid
      • PUT data of JsonObject role (name)
    • DELETE /v1/role/{rid}
    • GET /v1/principal/{pid}
    • GET /v1/principal/role/{rid}
      • Return details about one particular principal with id:pid
      • Return all principals the particular role has with role (rid)
      • Return all of them if pid equals to "all"
    • roles
      • Show all roles
    • GET /authorization/principals?role_name={name}
      • Show all principals in role with {name}
    • GET /authorization/roles?principal_type={type}&principal_name={name}
      • Show all roles in principal with {name, type}
    • PUT /authorization/roles/grantPUT /v1/grant_role
      • Grant a role to a user/group/role
      • PUT data of JsonObject role(idname) list and and principal (name, type, name) list
    • PUT /authorization/v1roles/revoke_role
      • Revoke /Remove a existing role granta role to a user/group/role
      • PUT data of JsonObject role(idname) list and principal (name, type, name) list
      GET
    • PUT /v1authorization/resourceprivileges/{rid}
      • Return details about one particular role with id:rid
      • Return all of them if rid equals to "all"
    • PUT /v1/resource
      • Create new resource without id:rid
      • Update existing resource with id:rid
      • PUT data of JsonObject resource (type, name)
    • DELETE /v1/resource/{rid}
    • GET /v1/privilege/{pid}
      • Return details about one particular privilege with id:pid
      • Return all of them if pid equals to "all"
    • PUT /v1/privilege
      • Create new privilege without id:pid
      • Update existing role with id:pid
      • PUT data of JsonObject privilege(resource, action, with_grant_option)
    • DELETE /v1/privilege/{pid}
    • PUT /v1/grant_privilege
      • Grant a privilege to a role
      • PUT data of JsonObject role(id) list and privilege (resource, action, with_grant_option) list
    • grant
      • Grant a privilege to a principal
      • PUT data of JsonObject principal(name, type) and privilege (resource-name, resource-type, action, with-grant-option)
    • PUT /authorization/privileges/revoke
      • Revoke a privilege to a principal
      • PUT data of JsonObject principal(name, type) and privilege (resource-name, resource-type, action, with-grant-option)
      • If privilege is null, then revoke all privileges for principal(name, type)
    • GET /authorization/privileges?principal_type={type}&principal_name={name}&resource_type={type}&resource_name={name}
      • Show all privileges in principal with {name, type} and resource with {resource-name, resource-type}
      • If resource is null, then show all privileges in principal with {name, type}
      PUT /v1/revoke_privilege
      • Revoke/Remove a existing privilege grant
      • PUT data of JsonObject role(id) list and privilege (resource, action, with_grant_option) list

Sentry implementation

  • Sentry could be used as an alternative access controller
  • Config in sqoop.properties

...

  • Role table
    • Id
    • Name
    • Comment
      • Role name could be admin, developer, user, etc.
  • Role_User_Group table
    • Id
    • Role_id
    • User_name
    • Group_name
    • Comment
      • The information of user and group comes from Linux or LDAP etc.
      • Only one of user name and group name is set. If user name is set and leave group name empty, it means that this user has this rule. If group name is set and leave user name empty, it means that all users in this group has this rule.
      • One user/group could have one or multiple roles.
  • Privilege table
    • Id
    • Role_id
    • Resource_id
    • Resource_type
    • Action_type
    • Comment
      • Resource type could be the existing resource table, such as connector, link, job, submission, etc.
      • Resource type could be added in the future, say config etc.
      • If resource_id is 0, it means all resource of this type, ie. resource_id=0 and resource_type=link means all links.
      • Use resource id and resource type to identify the resource, ie. resource_id=1 and resource_type=link means the resource of “select * from link where id =1”.
      • Action type could be read, create, update, delete, use etc.
  • Accordingly, MRole, MRoleUserGroup and MPrivilege classes are added into package org.apache.sqoop.model.

...