We configured our Hadoop clutser with Kerberos and everything started fine .We are trying to generate ticket for our hdfs principal using
kinit hdfs#HADOOP.COM
it is asking for password that we never configured although we are able to login using keytab file using
kinit hdfs#HADOOP.COM -t <keytab file location>
but now we wan the ticket that was generated using the keytab file to expire
I am very new in using Kerberos ,any pointers in right direction will be of a great help.
To list the kerberos ticket details, execute the below command in terminal
klist
Make sure JAVA_HOME is set in bashrc file
Not sure what you really mean by "now we wan the ticket that was generated using the keytab file to expire".
AFAIK you cannot force expiration of a ticket, but...
you can delete it completely with kdestroy
you can re-create it (delete + create) with kinit, either in
interactive mode (prompts for password then encrypts it to be shipped
to KDC) or background mode (uses provided keytab, which contains a
pre-encrypted password)
you can renew it (shift the expiration date, as far as you don't
bump into the max renewal lifetime)
So my best bet is that you just need to run kdestroy.
Related
Is it possible to set the default.password dynamically e.g. from a file? We have connected Presto to Zeppelin with a JDBC connector successfully, however we are using a different authentication method that requires us to renew the password every day. I have checked the current gitHub repository and found out that there is an interpreter.json that takes in default.password from the interpreter settings on Zeppelin. If I change the default.password to an environment variable, will it affect other JDBC interpreters. Is there a workaround?
Links to the repository:
https://github.com/apache/zeppelin/blob/e63ba8e897a522c6cad099286110c2eaa1496912/jdbc/src/main/resources/interpreter-setting.json
https://github.com/apache/zeppelin/blob/8f45fefb1c45ab163bedb94e3d9a9ef8a35afd91/jdbc/src/main/java/org/apache/zeppelin/jdbc/JDBCInterpreter.java
I figured out the problem. The interpreter.json in the config file stores all the information of each JDBC connection. So, by updating the password with jq command and restarting Zeppelin every day, this will update the password dynamically.
I was looking for answer to above question on different web sites but in the every case there was how to generate keytab file. I need keytab to get hbase connection which contains kerberos authentication.
In order to generate a keytab on Windows, you need to be running some version of Kerberos which talks back to a Directory server. On Windows, by far the most prevalent example of this is Active Directory, which has Kerberos support built-in. You'll need to create the keytab on a Windows server joined to the Active Directory domain, using the ktpass command to actually create the keytab.
Keytab generation syntax example:
ktpass -out centos1-dev-local.keytab -mapUser krbCentos#DEV.LOCAL +rndPass -mapOp set +DumpSalt -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -princ HTTP/centos1.dev.local#DEV.LOCAL
The above command example successfully creats a keytab for use in an AD domain named DEV.LOCAL. Note: notice the use of the randomize password syntax (+rndPass). In my opinion, there is no need to specify a password in the keytab creation command syntax. Instead, it's better to allow the password to be randomized - that provides much better security since it prevents anyone from being able to manually logon as the AD account surreptitiously and bypass the keytab.
For additional reference, I highly suggest you read my article on Kerberos keytab creation on the Windows platform on Microsoft Technet which greatly expands on what I said here: Kerberos Keytabs – Explained. I frequently go back and edit it based on questions I see here in this forum.
I have deployed Kerberos in hadoop cluster. According to the theory, the KDC will verify you are the one as you clared, according to the private key.
However, using that system confused me. For example, if you need access to the HDFS, what you need to do is just to input "kinit hdfs#MY.REALM" and the password from a client. Then you will get ticket and manipulate the HDFS as the superuser "hdfs".
Does this the real process of kerberos? If the user are only verified by password, why don't we directly build a list inside the server and require the user to input its username/password? Where is the private key mentioned in the theory? Can anyone explain this to me please?
I have an oozie workflow which executes a spark job, which needs usernames and passwords to connect to various servers. Right now I pass it in the workflow.xml as arguments:
username
password
It's (of course) a bad way to do this as it makes the password visible. What is the standard way to obfuscate the password in such a case?
Thanks!
Sqoop is an interesting case, as you can see in its documentation:
at first there was just the --password command-line option, followed by the password in plain text (yuck!)
then the --password-file was introduced, followed by a file that contains the password; it's a clear improvement because(a) when running on an Edge Node, the password itself is not visible to anyone running a ps command(b) when running in Oozie, you can just upload the file once in HDFS, then tell Oozie to download it to the CWD of the YARN container running your job, with a <file> option, and the password itself is not visible to anyone who inspects the job definition ---- but don't you forget to restrict access to the damn file, both on Edge Node and on HDFS, otherwise the password could still be compromised ----
finally, an optional Credential Store was introduced in Hadoop, and Sqoop supports that natively (although you now have the issue of protecting the password you use to connect to the Credential Store...)
Similarly, for Spark (and also for any custom Java / Scala / Python app) I strongly suggest that you store all sensitive information in a "properties" file, restrict access to that file, then pass it as a command-line argument to your program.
It will also make your life easier if you have distinct Dev / Test / Prod environments -- the Oozie script and "properties" filename will be exactly the same, but the actual props will be environment-specific.
Every time i try to use the Hadoop Resource Manager web interface (http://resource-manger.host:8088/cluster/) i show up logged in as dr.who.
My question, how can I login as another user? In this case i want to login as myself and have a higher lever of privileges than dr.who.
The user infomation is got from HttpServletRequest#getRemoteUser().
1. If you deployed an insecure cluster, the simplest way to pass the username to server is by url parameter. For example, http://localhost:8088/cluster?user.name=babu
2. If you deployed a secure cluster, you probably use Kerberos authentication. You can use kinit to get a kerberos tgt, then configure the browser to negotiate. (network.negotiate-auth.trusted-uris for firefox, and --auth-server-whitelist for chromium. I'm sure there's lots of answers about this)
For more information, you can check hadoop official documentation.(https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/HttpAuthentication.html)
You should set the access control list by changing the default configuration of:
yarn.resourcemanager.zk-acl
from
world:anyone:rwcda
to something else,which is Cluster-specific
The ACLs the ResourceManager uses for the znode structure to store the internal state.