May 23, 2019 at 13:49Elastic frees up problematic security features previously released in open source
The other day, a blog entry appeared on the Elastic blog that reports that the main security functions of Elasticsearch, which were released into the open source space more than a year ago, are now free for users.
The official blog post contains the “right” words that open source should be free and that the project owners build their business on other additional features that they offer for enterprise solutions. Now the following security functions are included in the base builds of versions 6.8.0 and 7.1.0, previously available only with a gold subscription:
However, transferring security functions to the free section is not a broad gesture, but an attempt to create a distance between a commercial product and its main sores.
And he has them, and serious ones.
The “Elastic Leaked” query returns 13.3 million results for Google. Impressive, isn't it? After the security functions of the project were displayed in open source, which once seemed like a good idea, Elastic began to have serious problems with data leaks. In fact, the basic version turned into a sieve, since no one really supported these same security functions.
One of the most high-profile data leaks from an elastic server was the case of the loss of 57 million data from US citizens, as reported in the pressin December 2018 (later it turned out that 82 million records had actually leaked). Then, in December 2018, due to Elastic security problems in Brazil, 32 million people were stolen. In March 2019, a total of 250,000 confidential documents, including legal ones, leaked from another elastic server. And this is only the first search page for the query we mention.
In fact, hacks continue to this day and began shortly after the security functions were removed from the "contentment" by the developers themselves and transferred to open source code.
The reader may notice: “So what? Well, they have security problems, and who does not have them? ”
And now attention.
The question is, until Monday, Elastic, with a clear conscience, was taking money from customers for a sieve called security functions, which it had withdrawn to open source in February 2018, that is, about 15 months ago. Having not incurred any significant expenses to support these functions, the company regularly took money for them from gold and premium subscribers from the client enterprise segment.
At some point, security problems became so toxic for the company, and customer complaints became so threatening that greed receded into the background. However, instead of resuming development and “patching” holes in their own project, due to which millions of documents and personal data of ordinary people went into the public domain, Elastic threw security functions into the free version of elasticsearch. And it presents it as a great blessing and contribution to the cause of open source.
In the light of such “effective” decisions, the second part of the blog post looks very strange, because of which we, in fact, drew attention to this story. We are talking about the release of the alpha version of Elastic Cloud on Kubernetes (ECK) - the official Kubernetes operator for Elasticsearch and Kibana.
Developers with quite a serious facial expression say that, they say, due to the removal of security functions in the basic free bundle of elasticsearch security functions, the load on the user administrators of these solutions will be reduced. Anyway, everything is fine.
“We can guarantee that all clusters launched and managed by ECK will be protected by default from the moment they are launched, without additional burden on administrators,” the official blog says.
As a solution thrown and plainly unsupported by the original developers, which over the past year has turned into a universal whipping boy, will provide users with safety, the developers are silent.
The official blog post contains the “right” words that open source should be free and that the project owners build their business on other additional features that they offer for enterprise solutions. Now the following security functions are included in the base builds of versions 6.8.0 and 7.1.0, previously available only with a gold subscription:
- TLS for encrypted communications.
- File and native realm for creating and managing user records.
- Management of user access to the API and the cluster based on roles; multi-user access to Kibana using Kibana Spaces is allowed.
However, transferring security functions to the free section is not a broad gesture, but an attempt to create a distance between a commercial product and its main sores.
And he has them, and serious ones.
The “Elastic Leaked” query returns 13.3 million results for Google. Impressive, isn't it? After the security functions of the project were displayed in open source, which once seemed like a good idea, Elastic began to have serious problems with data leaks. In fact, the basic version turned into a sieve, since no one really supported these same security functions.
One of the most high-profile data leaks from an elastic server was the case of the loss of 57 million data from US citizens, as reported in the pressin December 2018 (later it turned out that 82 million records had actually leaked). Then, in December 2018, due to Elastic security problems in Brazil, 32 million people were stolen. In March 2019, a total of 250,000 confidential documents, including legal ones, leaked from another elastic server. And this is only the first search page for the query we mention.
In fact, hacks continue to this day and began shortly after the security functions were removed from the "contentment" by the developers themselves and transferred to open source code.
The reader may notice: “So what? Well, they have security problems, and who does not have them? ”
And now attention.
The question is, until Monday, Elastic, with a clear conscience, was taking money from customers for a sieve called security functions, which it had withdrawn to open source in February 2018, that is, about 15 months ago. Having not incurred any significant expenses to support these functions, the company regularly took money for them from gold and premium subscribers from the client enterprise segment.
At some point, security problems became so toxic for the company, and customer complaints became so threatening that greed receded into the background. However, instead of resuming development and “patching” holes in their own project, due to which millions of documents and personal data of ordinary people went into the public domain, Elastic threw security functions into the free version of elasticsearch. And it presents it as a great blessing and contribution to the cause of open source.
In the light of such “effective” decisions, the second part of the blog post looks very strange, because of which we, in fact, drew attention to this story. We are talking about the release of the alpha version of Elastic Cloud on Kubernetes (ECK) - the official Kubernetes operator for Elasticsearch and Kibana.
Developers with quite a serious facial expression say that, they say, due to the removal of security functions in the basic free bundle of elasticsearch security functions, the load on the user administrators of these solutions will be reduced. Anyway, everything is fine.
“We can guarantee that all clusters launched and managed by ECK will be protected by default from the moment they are launched, without additional burden on administrators,” the official blog says.
As a solution thrown and plainly unsupported by the original developers, which over the past year has turned into a universal whipping boy, will provide users with safety, the developers are silent.