[FEATURE] Support login from a proxy user

[gabry-lab]

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

Search before asking

• [X] I have searched in the issues and found no similar issues.

Describe the feature

As of now, kyuubi get subject like this.

  private Subject createSubject() {
    if (isKeytabAuthMode()) {
      String principal = sessConfMap.get(AUTH_KYUUBI_CLIENT_PRINCIPAL);
      String keytab = sessConfMap.get(AUTH_KYUUBI_CLIENT_KEYTAB);
      return KerberosAuthenticationManager.getKeytabAuthentication(principal, keytab).getSubject();
    } else if (isFromSubjectAuthMode()) {
      AccessControlContext context = AccessController.getContext();
      return Subject.getSubject(context);
    } else if (isTgtCacheAuthMode()) {
      return KerberosAuthenticationManager.getTgtCacheAuthentication().getSubject();
    } else {
      // This should never happen
      throw new IllegalArgumentException("Unsupported auth mode");
    }
  }

However when isFromSubjectAuthMode is true, it doesn't check if current subject has any credentials. We'd better double-check that if possible.

If current subject doesn't have any credentials, we'd better use left auth mode to get subject, such as TgtCacheAuthMode

Motivation

No response

Describe the solution

No response

Additional context

Background: Our flink cluster create a login user using ticket cache, and create another proxy user based on that to run all user code. So, in SubjectAuthMode, current user (actually a proxy user) doesn't have any credentials.

Here is how hadoop ipc.Client to handle sasl error,

Are you willing to submit PR?

• [ ] Yes. I would be willing to submit a PR with guidance from the Kyuubi community to improve.
• [X] No. I cannot submit a PR at this time.

[pan3793]

cc kerberos experts @zhouyifan279 @cxzl25 @turboFei, also cc @link3280 as Flink is mentioned

[gabry-lab]

@pan3793 it's not related to kerberos, I think we should not only infer auth mode from session configs,but also we'd better use the specific auth mode from JdbcConnectionParams.AUTH_TYPE directly.

[pan3793]

@gabrywu it's not very clear to me what's your expectations, I would say the original behavior from the Hive JDBC driver is not ideal, I have tried my best to make the behavior compatible with the Hive JDBC driver to reduce the migration efforts from Hive JDBC driver users.

it's not related to kerberos ... we'd better use the specific auth mode from JdbcConnectionParams.AUTH_TYPE directly.

I see your point, strictly speaking, it's related to the Hadoop security mechanism and client auth mechanism chosen behavior, I'm not an expert in this area, would be better if you could leave specific examples on your proposal, also, please make sure the proposed behavior compatible with Hive JDBC driver.

[gabry-lab]

@pan3793 no matter what's the auth mechanism is, we'd better use the specific auth mode provided by client explicitly. If users don't provide auth mode, we can infer it from session configs.

[zhouyifan279]

From what I understood, we are discussing 2 problems:

1. Can not authenticate with Kyuubi Server using proxy user and subject auth mode
2. Make auth mode configs more user friendly

For Problem 1, we can use proxy user to authenticate using following code:

val remoteUser: UserGroupInformation = ...
val isProxyUser = remoteUser.getAuthenticationMethod() == UserGroupInformation.AuthenticationMethod.PROXY
val realUser = if (isProxyUser) {
  remoteUser.getRealUser()
} else {
  remoteUser
}

val connection = realUser.doAs(new PrivilegedExceptionAction[Connection]() {
    override def run(): Connection = {
          val url = if (isProxyUser) {
             "jdbc:hive2://....;hive.server2.proxy.user=" + remoteUser.getShortUserName()
          } else {
             "jdbc:hive2://....;"
          }
          DriverManager.getConnection(url)
    }
})

As Kyuubi Hive Jdbc tries to not include hadoop dependencies, I suggest not put the above code into Kyuubi.

For Problem 2, I agree that the authentication configs inherited from Hive is hard to understand. I vote +1 for the refactoring as long as it keeps to support current configs.

[pan3793]

@zhouyifan279 I missed this thread, to be clear, the Kyuubi JDBC driver is intended to not couple with Hadoop classes, but we can do that via reflection when Hadoop classes are available under classpath

As Kyuubi Hive Jdbc tries to not include hadoop dependencies, I suggest not put the above code into Kyuubi.