I guess this should be KIP-77 ? KIP-76 is "Improve Kafka Streams Join Semantics"
See http://search-hadoop.com/m/uyzND19SmQJ1yfCQ42/v=plain -Matthias On 08/25/2016 10:13 PM, Ashish Singh wrote: > Hey Gwen, > > You’re right that if someone can alter the executable then they can do > things in the context of the thing running the script, like kafka. But if > you were kafka admin user (or root), you could also do lots of things to > lots of other different files owned by the user, so it’s not really that > much different than the current state of things. > > You’re right to wonder about the real security gains here. In some sense, > they aren’t many, because if you know where to look and what to do, you can > coax the password out of that executable. What this approach really does is > make it *nontrivial* for an attacker to get the password. And people tend > to flip out when they see passwords sitting in the clear on a disk, because > we’ve all been rightly trained that cleartext passwords are bad. > > This approach when combined with some strong security practices, like the > ones mentioned below makes the system reasonably secure. This approach is > probably the simplest way for folks to strengthen their Kafka security. > There are other more complicated ways, like Hadoop’s credential store, > which depends on external systems. If the community feels that this does > not help, we can definitely move towards more complicated mechanisms. > However, this has sufficed for our needs so far and others have expressed > their satisfaction on the JIRA. > > - Executable decrypts a file that stores encrypted passwords. > - The secret to decrypt that file is passed in via environment, which is > generally a bit harder to find than files on disk. > - The perms also protect the executable. > - The file sits on an ephemeral disk that’s mounted to memory, so > stealing a physical disk won’t result in getting even the encrypted > password. > > On Thu, Aug 25, 2016 at 9:07 AM, Gwen Shapira <g...@confluent.io> wrote: > > Hi Ashish, >> >> I appreciate the need to integrate our authentication with other >> systems that store passwords. >> I am not sure that doing so by running a binary is the best solution. >> >> First, it does not add security: As you said, a file is just "sitting >> there" the same way an executable is just "sitting there" - we still >> rely on file system privileges for security. >> Second, the idea that Kafka will run arbitrary filesystem executables >> is pretty terrifying. Reading a string from a file is harmless, but an >> incorrectly privileged executable can be replaced with "rm -rf /" or >> anything really. Kafka sometimes runs from privileged account, so this >> is a serious risk. >> >> I looked at the Hadoop credential store you helpfully linked to in the >> KIP, and it seems like the Hadoop proposal includes a well thought out >> API to integrate with external systems. Since we took this approach in >> the past, I'm wondering why not follow the same and use an API to >> integrate with credential stores rather than arbitrary executables. >> >> Gwen >> >> On Wed, Aug 24, 2016 at 12:03 PM, Ashish Singh <asi...@cloudera.com> >> wrote: >>> Hey Guys, >>> >>> I’ve just posted KIP-76: Enable getting password from executable rather >>> than passing as plaintext in config files >>> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-76+En >> able+getting+password+from+executable+rather+than+passing+ >> as+plaintext+in+config+files> >>> . >>> >>> The proposal is to enable getting passwords from executable. This is an >> ask >>> from very security conscious users. >>> >>> Full details are here: >>> >>> KIP: >>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-76+Ena >> ble+getting+password+from+executable+rather+than+passing+as+ >> plaintext+in+config+files >>> JIRA: https://issues.apache.org/jira/browse/KAFKA-2629 >>> POC: https://github.com/apache/kafka/pull/1770 >>> >>> Thanks >>> >>> -- >>> >>> Regards, >>> Ashish >> >> >> >> -- >> Gwen Shapira >> Product Manager | Confluent >> 650.450.2760 | @gwenshap >> Follow us: Twitter | blog >> > >
signature.asc
Description: OpenPGP digital signature
