Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

Possibility to use Principals across clusters

avatar
Expert Contributor

Hi community,

a security related question: I got two clusters in my environment. Both are kerberized and connected to the same Active directory as KDC.

Let's look at technical users now: For the hive-user for instance I created a keytab both on the first and second cluster:

hive/somehostinclusterA@REALM.COM

hive/somehostinclusterB@REALM.COM

Now imagine that the first cluster (A) is run by development with moderate rules, while cluster B is run in production with strict rules.

When somebody now steals a keytab from cluster A, there is a security threat: Not only can he access cluster A, but he can also access cluster B (=production), which is bad.

Why? Because the auth_to_local rules just convert both hive/somehostinclusterA@REALM.COM and hive/somehostinclusterB@REALM.COM to hive, who is Superuser for the Hive Service in both clusters.

Is this a known security problem and are there guidelines on how to fix it. I thought about making complex auth_to_local rules, but this seems to be unoperatable.

1 ACCEPTED SOLUTION

avatar
Contributor
hide-solution

This problem has been solved!

Want to get a detailed solution you have to login/registered on the community

Register/Login
9 REPLIES 9

avatar
@Roland Simonis

I believe that you are confusing authentication with authorization. Kerberos is only an authentication mechanism. It tells who the user is... not what the user can do. In some cases, the lack of who helps with authorization since there is no user to authorize. This is what you are trying to do by not translating certain principal names to local user names.

In the scenario you pose, there is a security issue; but, I am not sure that I would blame Kerberos or Ambari's configuration of the Kerberos infrastructure on it. I believe that by installing an authorization service, like Ranger, you should be able protect against unauthorized access to Hive and other services and thus rule out any cross-cluster access issues.

If you are looking to proceed with limiting access based on auth-to-local rules, be sure to see Auth-to-local Rules Syntax for information on the syntax of the rules.

avatar

So after a conversation with @lmccay, it appears that my assumption/statement about Ranger is incorrect and therefore a compromised service principal compromises all (relevant) services on all clusters that use the same Kerberos realm. But once again, Kerberos is not an authorization mechanism... it is merely an authentication mechanism.

I think the only real solution here is to isolate clusters using different Kerberos realms. This can be done by using a local KDC and realm for the cluster-specific principals and creating a one-way trust with an Active Directory (or centralized KDC) for the user accounts. This has a few benefits over the centralized-only solution, including cluster isolation as well as network traffic isolation and distribution of load on the KDC.

avatar
Expert Contributor

@Robert Levas

Thanks for your comment.

For any other users than technical users, I agree with you. Authorization is my friend to keep away users from the wrong cluster.

In this particular case, however, I am really "blaming" authentication. My problem is, that the technical users of two cluster have the same name and can therefore not be distinguished from another by an authorization engine, such as Ranger.

Example: The hive-Principal in cluster B SHOULD have access to all tables (as he is the superuser) but the hive-Principal from cluster B SHOULD NOT. Kerberos authentication, however, does not distinguish between the users, as they both have the same name.

avatar
Expert Contributor

@Roland Simonis - I believe that @Robert Levas is generally correct but you are talking about a keytab being compromised. In that case, I believe it is generally gameover. Keytab management is extremely important. They should only be readable by root and not even backed up. If you want to protect clusters from keytabs that are compromised from other clusters then they should be for different realms - IMO.

avatar
Expert Contributor

Thank you @Robert Levas and @lmccay for your insights. It appears, protecting the keytabs really is one of the most important Hadoop security tasks.

As seperating REALMs is not realizable in my case, I will stick with keeping keytabs secure and maybe tuning auth-to-local-rules.

Also thanks to @spotluri for summing it up.

avatar
Contributor
hide-solution

This problem has been solved!

Want to get a detailed solution you have to login/registered on the community

Register/Login

avatar
Expert Contributor

Just to sum it up: I have now chosen to place some regex in the auth-to-local rules to match exactly those hosts, which are used in a certain cluster.

While this adds operations overhead, it will make the cluster more secure.

The guys of Cloudera have a good summary about that in their documentation: https://www.cloudera.com/documentation/enterprise/5-9-x/topics/sg_auth_to_local_isolate.html

avatar
Contributor

Just had a new idea, that probably can solve the problem

We can have different account names such as hive-clusterA/hostname@realm.com

hive-clusterB/hostname@realm.com

And then have an auth_to_local rule in clusterA which converts hive-clusterA to hive and vice versa in clusterB.

Very similar to how "dn", "nn","nm" principals get resolved.

Cheers

avatar
Expert Contributor

Hi @spotluri

This is also a great idea, if splitting REALMs is not feasible.