You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "bharath v (JIRA)" <ji...@apache.org> on 2019/08/07 17:25:00 UTC
[jira] [Created] (IMPALA-8844) Decouple kinit renewal thread from
Keberos configuration.
bharath v created IMPALA-8844:
---------------------------------
Summary: Decouple kinit renewal thread from Keberos configuration.
Key: IMPALA-8844
URL: https://issues.apache.org/jira/browse/IMPALA-8844
Project: IMPALA
Issue Type: Improvement
Components: Backend
Affects Versions: Impala 3.2.0
Reporter: bharath v
Currently, Impala starts a kinit renewal thread only when kerberos is enabled,
{noformat}
Status SecureAuthProvider::Start() {
// True for kerberos internal use
if (needs_kinit_) {
DCHECK(is_internal_);
DCHECK(!principal_.empty());
// IMPALA-8154: Disable any Kerberos auth_to_local mappings.
FLAGS_use_system_auth_to_local = false;
// Starts a thread that periodically does a 'kinit'. The thread lives as long as the
// process does.
KUDU_RETURN_IF_ERROR(kudu::security::InitKerberosForServer(principal_, keytab_file_,
FLAGS_krb5_ccname, false), "Could not init kerberos"); <==== starts the thread
LOG(INFO) << "Kerberos ticket granted to " << principal_;
}
{noformat}
There can be cases where Impala's internal connections are *not* kerberized but communication with external components like HMS/Ranger/Atlas could be kerberized. In such setups, Impala process doesn't have a tgt initialized resulting in failing connections to these components.
We could start with decoupling the kinit thread from the kerberos configuration and have it run in cases where any communication is kerberized (use a flag?).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org