[
https://issues.apache.org/jira/browse/KAFKA-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14953542#comment-14953542
]
Mike Yoder commented on KAFKA-2629:
-----------------------------------
Hi - I work with [~singhashish] so I thought I'd jump in here.
{quote}
While flexibility is generally a good thing, in my opinion the security
consequences in real-world of this approach needs to be carefully evaluated.
{quote}
Appreciate the feedback. You're right, security is hard.
{quote}
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?
{quote}
All reasonable questions. First, let's step back and realize that this is only
an _interface_ to getting a password, not the implementation behind said
interface. Many of your questions really deserve to be asked of the
implementations.
That being said, running an executable is a little different than ordinary file
access. However I don't believe that it adds risk to the overall security of
the application.
Yes, the specification of the executable to run is in a config file - but if an
attacker controls the config file itself, we have far bigger problems than them
being able to run some program. Likewise, if an attacker can control the
executable that's being run, then bad things can happen - but that's bad
because the implementation has somehow been screwed up, or because the attacker
has control of things that defeat other security measures as well.
I think that the benefit of this approach is that it _enables_ things that
aren't possible with a password simply sitting in a config file. Primarily it
enables a use case where a centralized password store is contacted, and a
password dispensed. The benefit with this is that the password store can audit
usage, rotate passwords, and provide centralized management.
{quote}
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.
{quote}
I disagree. The implementation of the CredentialProvider is hooked into all the
"sensitive" parameters of Hadoop. It's not just for the authentication of
users.
One example is here:
https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/ssl/FileBasedKeyStoresFactory.java#L155
This is for core hadoop ssl's keystore password. The getPassword() call goes to
the CredentialProvider interface for passwords.
The CredentialProvider is an interface; the implementation can do pretty much
anything it wants, including something like what is described in this jira. The
popular implementation gets a password from a jceks file.
An alternative implementation of this jira would be to build something like the
CredentialProvider for Kafka. That's a bigger project... but accomplishes
similar goals.
{quote}
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.
{quote}
That's an interesting distinction that I have not seen others make. I admit
that differentiating between passwords used for human authentication and
passwords used to encrypt things in a keystore is not one that occurred to me.
In a way, you're right, they are somewhat different use cases, and I could be
accused of misreading the standard.
HOWEVER, I know many organizations who interpreted the standard like I did: a
password is a password, and shall not be suffered to exist in plain text on a
disk. There are corporations out there with quite rigid blanket policies
regarding this. Auditors, in particular, do not have a sense of humor at all
about such things. So many others could be accused of misreading the standard,
too.
{quote}
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.
{quote}
Yes.
{quote}
Unfortunately building a secure application is often tricky \[1,2,3,4\].
{quote}
No argument here. Remember, though, this is an _interface_ to such a thing, not
the thing itself. You will not catch me claiming that implementations of this
will be able to defeat a cold boot attack, or anything a sophisticated attacker
will throw at it.
{quote}
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?
{quote}
I would view that as certainly one viable implementation, yes. But I think it
lacks the auditing and centralized management that others may want. The point
of making an interface here instead of settling on one implementation is to
enable different use cases. Tying it specifically to gpg would be problematic
for some use cases.
Hopefully I've addressed some of your concerns. You're right that security is
difficult. However having a generic interface around the acquisition of
passwords does not harm or help security per se; only the implementations can
do that.
> 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)
