[jira] [Comment Edited] (KAFKA-2629) Enable getting SSL password from an executable rather than passing plaintext password
[ https://issues.apache.org/jira/browse/KAFKA-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413820#comment-15413820 ] Bharat Viswanadham edited comment on KAFKA-2629 at 8/9/16 4:51 PM: --- [~singhashish] What is the final approach for this solution? was (Author: bharatviswa): [~singhashish] What is the final approach for this solution? Will also be using hadoop credential provider to address this problem? > Enable getting SSL password from an executable rather than passing plaintext > password > - > > Key: KAFKA-2629 > URL: https://issues.apache.org/jira/browse/KAFKA-2629 > Project: Kafka > Issue Type: Improvement > Components: security >Affects Versions: 0.9.0.0 >Reporter: Ashish K Singh >Assignee: Ashish K Singh > > Currently there are a couple of options to pass SSL passwords to Kafka, i.e., > via properties file or via command line argument. Both of these are not > recommended security practices. > * A password on a command line is a no-no: it's trivial to see that password > just by using the 'ps' utility. > * Putting a password into a file, and then passing the location to that file, > is the next best option. The access to the file will be governed by unix > access permissions which we all know and love. The downside is that the > password is still just sitting there in a file, and those who have access can > still see it trivially. > * The most general, secure solution is to provide a layer of abstraction: > provide functionality to get the password from "somewhere else". The most > flexible and generic way to do this is to simply call an executable which > returns the desired password. > ** The executable is again protected with normal file system privileges > ** The simplest form, a script that looks like "echo 'my-password'", devolves > back to putting the password in a file > ** A more interesting implementation could open up a local encrypted password > store and extract the password from it > ** A maximally secure implementation could contact an external secret manager > with centralized control and audit functionality. > ** In short: getting the password as the output of a script/executable is > maximally generic and enables both simple and complex use cases. > This JIRA intend to add a config param to enable passing an executable to > Kafka for SSL passwords. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (KAFKA-2629) Enable getting SSL password from an executable rather than passing plaintext password
[ https://issues.apache.org/jira/browse/KAFKA-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951306#comment-14951306 ] Haohui Mai edited comment on KAFKA-2629 at 10/9/15 10:40 PM: - While flexibility is generally a good thing, in my opinion the security consequences in real-world of this approach needs to be carefully evaluated. My question is that why this approach provides more security? Why trusting the operating system kernel is insufficient in this case? Why bringing in yet another another application to the trusted computing base? How does it widen the attack surfaces? What are the kinds of attacks that this approach prevents, but putting permissions on top of the file fails to do so? bq. Hadoop implemented something called the CredentialProvider specifically for the purpose of encrypting passwords. See https://issues.apache.org/jira/browse/HADOOP-10607. This functionality is now supported by other projects, including Hive, HBase, etc. I believe the Hadoop jira is irrelevant. This is specifically tailored to hook with services like Apache Ranger and Apache Sentry -- all of which for user authentication / authorization. bq. If you google, you will find many well known products use similar approaches. Even if someone is not, they should as per the PCI DSS v3 standard. Can you list what you specifically referring to? bq. 8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components. Please correct me if I'm wrong, it looks to me that you misread the standard? The statement you specifically refers to user authentication services. The password in SSL keystore serves as a master keyphrase to protect the private key stored in the keystore. bq. Sure, one can access the executable with proper permissions, but will not be able to access the env variables that the process, starting Kafka server, used to get the password. I'd like to point out that the other side of the argument is that the system needs to trust the your customized application to be secure. Unfortunately building a secure application is often tricky[1,2,3,4]. Programs like gpg have mechanisms to defend against these attacks. If you really want a workflow like that it is possible to use gpg to extract the passphase from a centralized keystore, putting it into a temporary file with proper permissions and start the Kafka server. Indeed there are some tricky issues to handle in order to secure the temporary file, but in practice it is much easier for security reviews and give much better security guarantees. Does it solve your use cases? In short, encryption is a way to achieve security but by no means that it is equivalent to security. The trusts and security consequences have to be carefully evaluated. References: 1. Moxie Marlinspike, https://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-SLIDES.pdf 2. Xiang Cai et al. Exploiting Unix File-System Races via Algorithmic Complexity Attacks, In IEEE S, 2009. 3. J. Alex Halderman et al. Lest We Remember: Cold Boot Attacks on Encryption Keys. In USENIX Security, 2008. 4. Ian Goldberg and David Wagner, Randomness and the Netscape Browser. January 1996 Dr. Dobb's Journal was (Author: wheat9): While flexibility is generally a good thing, in my opinion the security consequences in real-world of this approach needs to be carefully evaluated. My question is that why this approach provides more security? Why trusting the operating system kernel is insufficient in this case? Why bringing in yet another another application to the trusted computing base? How does it widen the attack surfaces? What are the kinds of attacks that this approach prevents, but putting permissions on top of the file fails to do so? bq. Hadoop implemented something called the CredentialProvider specifically for the purpose of encrypting passwords. See https://issues.apache.org/jira/browse/HADOOP-10607. This functionality is now supported by other projects, including Hive, HBase, etc. I believe the Hadoop jira is irrelevant. This is specifically tailored to support the transparent encryption at rest project. It provides a pluggable way to hook with services like active directory, Apache Ranger and Apache Sentry. bq. If you google, you will find many well known products use similar approaches. Even if someone is not, they should as per the PCI DSS v3 standard. Can you list what you specifically referring to? bq. 8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components. Please correct me if I'm wrong, it looks to me that you misread the standard? The statement you specifically refers to user authentication services. The
[jira] [Comment Edited] (KAFKA-2629) Enable getting SSL password from an executable rather than passing plaintext password
[ https://issues.apache.org/jira/browse/KAFKA-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950932#comment-14950932 ] Sriharsha Chintalapani edited comment on KAFKA-2629 at 10/9/15 6:30 PM: [~singhashish] The distribution of ssl.properties along with a plaintext password is been a common way of doing things. In Hadoop they do this as well. Not just for ssl in case of kerberos you depend on file system permissions for keytabs to keep it secure. I don't see ssl properties file any different than keystore file permissions. Honestly, I never seen any system doing this so far for SSL. Why do you think filesystem permission not suffice and do you have any example anyone else doing this. In your proposal you are saying an executable is also protected by same file system permissions than how it is providing any additional security ?. was (Author: sriharsha): [~singhashish] The distribution of ssl.properties along with a plaintext password is been a common way of doing things. In Hadoop they do this as well. Not just for ssl in case of kerberos you depend on file system permissions for keytabs to keep it secure. I don't see ssl properties file any different than keystore file permissions. Honestly, I never seen any system doing this so far for SSL. Why do you think filesystem permission not suffice and do you have any example anyone else doing this. > Enable getting SSL password from an executable rather than passing plaintext > password > - > > Key: KAFKA-2629 > URL: https://issues.apache.org/jira/browse/KAFKA-2629 > Project: Kafka > Issue Type: Improvement > Components: security >Affects Versions: 0.9.0.0 >Reporter: Ashish K Singh >Assignee: Ashish K Singh > > Currently there are a couple of options to pass SSL passwords to Kafka, i.e., > via properties file or via command line argument. Both of these are not > recommended security practices. > * A password on a command line is a no-no: it's trivial to see that password > just by using the 'ps' utility. > * Putting a password into a file, and then passing the location to that file, > is the next best option. The access to the file will be governed by unix > access permissions which we all know and love. The downside is that the > password is still just sitting there in a file, and those who have access can > still see it trivially. > * The most general, secure solution is to provide a layer of abstraction: > provide functionality to get the password from "somewhere else". The most > flexible and generic way to do this is to simply call an executable which > returns the desired password. > ** The executable is again protected with normal file system privileges > ** The simplest form, a script that looks like "echo 'my-password'", devolves > back to putting the password in a file > ** A more interesting implementation could open up a local encrypted password > store and extract the password from it > ** A maximally secure implementation could contact an external secret manager > with centralized control and audit functionality. > ** In short: getting the password as the output of a script/executable is > maximally generic and enables both simple and complex use cases. > This JIRA intend to add a config param to enable passing an executable to > Kafka for SSL passwords. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
