On Wed, May 6, 2020 at 3:32 PM Eric Yang <eric...@gmail.com> wrote: > > Hi all, > > Kerberos was developed decade before web development becomes popular. > There are some Kerberos limitations which does not work well in Hadoop. A > few examples of corner cases:
Microsoft Active Directory, which is extensively used in many organizations, is based on Kerberos. > 1. Kerberos principal doesn't encode port number, it is difficult to know > if the principal is coming from an authorized daemon or a hacker container > trying to forge service principal. Clients use ephemeral ports. Not sure of what the relevancy of this statement. > 2. Hadoop Kerberos principals are used as high privileged principal, a form > of credential to impersonate end user. Principals are identities of the user. You can make identities fully qualified, to include issuing authority if you want to. This is not kerberos specific. Remember, Kerberos is an authentication mechanism, How those assertions are translated to authorization rules are application specific. Probably reconsider alternatives to auth_to_local rules. > 3. Delegation token may allow expired users to continue to run jobs long > after they are gone, without rechecking if end user credentials is still > valid. Delegation tokens are hadoop specific implementation, whose lifecycle is outside the scope of Kerberos. Hadoop (NN/RM) can periodically check respective IDP Policy and revoke tokens. Or have a central token management service, similar to KMS > 4. Passing different form of tokens does not work well with cloud provider > security mechanism. For example, passing AWS sts token for S3 bucket. > There is no renewal mechanism, nor good way to identify when the token > would expire. This is outside the scope of Kerberos. Assuming you are using YARN, making RM handle S3 temp credentials, similar to HDFS delegation tokens is something to consider. > There are companies that work on bridging security mechanism of different > types, but this is not primary goal for Hadoop. Hadoop can benefit from > modernized security using open standards like OpenID Connect, which > proposes to unify web applications using SSO. This ensure the client > credentials are transported in each stage of client servers interaction. > This may improve overall security, and provide more cloud native form > factor. I wonder if there is any interested in the community to enable > Hadoop OpenID Connect integration work? End to end identity assertion is where Kerberos in it self does not address. But any implementation should not pass "credentials'. Need a way to pass signed requests, that could be verified along the chain. > > regards, > Eric On Wed, May 6, 2020 at 3:32 PM Eric Yang <eric...@gmail.com> wrote: > > Hi all, > > Kerberos was developed decade before web development becomes popular. > There are some Kerberos limitations which does not work well in Hadoop. A > few examples of corner cases: > > 1. Kerberos principal doesn't encode port number, it is difficult to know > if the principal is coming from an authorized daemon or a hacker container > trying to forge service principal. > 2. Hadoop Kerberos principals are used as high privileged principal, a form > of credential to impersonate end user. > 3. Delegation token may allow expired users to continue to run jobs long > after they are gone, without rechecking if end user credentials is still > valid. > 4. Passing different form of tokens does not work well with cloud provider > security mechanism. For example, passing AWS sts token for S3 bucket. > There is no renewal mechanism, nor good way to identify when the token > would expire. > > There are companies that work on bridging security mechanism of different > types, but this is not primary goal for Hadoop. Hadoop can benefit from > modernized security using open standards like OpenID Connect, which > proposes to unify web applications using SSO. This ensure the client > credentials are transported in each stage of client servers interaction. > This may improve overall security, and provide more cloud native form > factor. I wonder if there is any interested in the community to enable > Hadoop OpenID Connect integration work? > > regards, > Eric --------------------------------------------------------------------- To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
