Title: High Level Design of Role Based Access Controller in SQOOP 2

JIRA : SQOOP-1834 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 connector, link, job, submission etc.

Basic Idea

• The access controller is pluggable

• Set controller class in sqoop.properties

org.apache.sqoop.accessController.class=org.apache.sqoop.accessController.DefaultSqoopAuthorizerImpl

• The default implement in Sqoop 2 could be a FAKE controller (always return true)

• The access controller class could be implemented by other controller framework, such as Sentry
• Connector

Resource and actions

Authorization framework

• Config in sqoop.properties

#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 Added

• Five classes will be added into Sqoop-core as org.apache.sqoop.security package.
  • AuthorizationManager
    • Similar with other Sqoop Manager, ie. ConnectorManager, RepositoryManager, etc., the AuthorizationManager handles two singleton instances, AuthorizationManager and AuthorizationHandler.
    • The initialize function is run when starting the Sqoop server
    • The initialize function will initial AuthorizationHandler, according to the handler name (DefaultAuthorizationhandler or SentryAuthorizationHandler) from configuration file (sqoop.properties).
  • AuthorizationHandlerFactory
    • It is a factory design mode.
    • It is to use ClassUtils.loadClass to refact the real AuthorizationHandler in getAuthorizationHandler function.
  • AuthorizationHandler
    • It is an abstract class.
    • There is a default implementation (DefaultAuthorizationHandler) in Sqoop-security component.
    • It handles two singleton instances, AccessController and AuthorizationValidator.
    • All function will be delegated to these two instances to handle. AccessController to handle grantRole, revokeRole, grantPrivilege and revokePrivilege. AuthorizationValidator to handle checkPrivilege.
  • AccessController
    • It is an abstract class.
    • There is a default implementation (DefaultAccessController) in Sqoop-security component.
    • This class is responsible to manage roles, privileges.
  • AuthorzationValidator
    • It is an abstract class.
    • There is a default implementation (DefaultAuthorizationValidator) in Sqoop-security component.
    • This class is responsible to check privileges.
• Three classes will be added into Sqoop-security as org.apache.sqoop.security package.
  • DefaultAuthorizationHandler
    • This class extends abstract AuthorizationHandler.
    • It handles two singleton instances, DefaultAccessController and DefaultAuthorizationValidator.
  • DefaultAccessController
    • This class extends abstract AccessController.
  • Default AuthorzationValidator
    • This class extends abstract AuthorizationValidator.
    • As default/simple implementation, it always returns true and will not check the privilege actually.

Image Added

1. All functions in JdbcRepository, which manipulate resources, ie. create link, will be added privilege validation check.

  /**   * {@inheritDoc}   */  @Override  public void createLink(final MLink link) {    AuthorizationManager.getAuthorizationHanlder().checkPrivilige();    doWithConnection(new DoWithConnection() {      @Override      public Object doIt(Connection conn) {        if(link.hasPersistenceId()) {          throw new SqoopException(RepositoryError.JDBCREPO_0015);        }         handler.createLink(link, conn);        return null;      }    });  }

1. Privilege check will be passed to real AccessController from AuthorizationHandler.

     @Override     public void checkPrivileges() throws SqoopAccessControlException {         authValidator.checkPrivileges();     }

  Command line tool

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

show rolegrant role –name useradd role –id 1 –name userremove role –id 1show role_user_groupgrant role_user_group –role_id 1 –user_name sqoopgrant role_user_group –role_id 1 –group_name sqooprevoke role_user_group –role_id 1 –user_name sqooprevoke role_user_group –role_id 1 –group_name sqoopshow privilegegrant privilege –resource_type link –resource_id 1 –role_id 1 –action_type readrevoke privilege –resource_type link –resource_id 1 –role_id 1 –action_type read

• Restful call API is handled by org.apache.sqoop.handler.AuthorizationRequestHandler.java in sqoop-server
  • GET /v1/role/{rid}
    • Return details about one particular role with id:rid
    • Return all of them if rid equals to "all"
  • POST /v1/role
    • Create new role without id:rid
    • Update existing role with id:rid
    • POST data of JsonObject MRole
  • DELETE /v1/role/{rid}
  • GET /v1/role_user_group/{rugid}
    • Return details about one particular role_user_group with id:rugid
    • Return all of them if rugid equals to "all"
  • POST /v1/role_user_group
    • Create new role without id:rugid
    • Update existing role_user_group with id:rid
    • POST data of JsonObject MRoleUserGroup
  • DELETE /v1/role_user_group/{rugid}
  • GET /v1/privilege/{pid}
    • Return details about one particular privilege with id:pid
    • Return all of them if pid equals to "all"
  • POST /v1/privilege
    • Create new role without id:pid
    • Update existing privilege with id:pid
    • POST data of JsonObject MRoleUserGroup
  • DELETE /v1/privilege/{pid}

Sentry implementation

Image Added

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

#org.apache.sqoop.authorization.handler=org.apache.sqoop.security.SentryAuthorizationHandler#org.apache.sqoop.authorization.controller=org.apache.sqoop.security.SentryAccessController#org.apache.sqoop.authorization.validator=org.apache.sqoop.security.SentryAuthorizationValidator

• Use Sentry to check access privilege
• Set access privilege using hue (optional)

Database design

Image Added

• 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.