Platinum Licensed cluster using CCS against a Basic Licensed cluster

Elastic Stack Elasticsearch
1

Not sure if this idea is going to be offensive or not, but hear me out.

We have a pretty standard log searching setup internally, spread across 40 nodes. It's kind of a pet project for some of our analysts. This setup is using a Basic license, with local accounts.

Recently one of our auditors took offense to the fact the local auth system has no built-in password policies. I know there is a 6 char minimum but he wanted more :stuck_out_tongue:

Unfortunately there is no way I can business-justify a commercial license for this setup. It's just too much $$$ and the use case isn't one I can sell internally.

I've been trying to figure out if there was a good, inexpensive way to just tick this one checkbox. I looked at ReadOnlyREST and SearchGuard, but don't really like them.

I then came up with this idea: What if I built a 1-node Elastic cluster, licensed it with Gold or Platinum licensing (giving it the ability to tie into Active Directory, which would check my auditor's checkbox), point Kibana to that cluster, and configure Cross Cluster search into the Basic licensed Cluster?

Off the top of my head I can't see any reason this wouldn't work technically. Obv to address the auditor's headspace I'd have to do some firewalling to make sure users couldn't hit the basic cluster directly anymore, but that's not hard.

Question: Does anyone see any reason a commercial cluster wouldn't work doing CCS to a Basic cluster?

2

As far as I know all connected clusters need to have the same license.

3

You'll need to read the licence agreement carefully to find out for sure, but like Christian I also expect a mixed-licence setup isn't ok.

Two simpler options spring to mind:

  1. You can have a password policy that isn't enforced by the system, simply by writing it down. You presumably already have a policy that says various other things that can't be enforced by the system (e.g. people can't share their account details with each other) so just add some guidance on password quality to that. Boom, you now have a password policy.

  2. You could upgrade your auditor :wink:

4

Password policy enforcement would be a useful feature to have though... :slight_smile:

1 Like
5

:+1: PRs are welcome :grin:

Password strength guidelines are IMO a fairly small fraction of a much larger security policy framework, most of which can't be enforced by the system, so it's pretty inconsistent to worry too much about this one thing.

It's a different story for public-facing systems where a written policy is practically useless, but this is an internal system with only internal users.

1 Like
6

Hah, thanks guys. I won't argue against the points (because I agree) but def won't pass internally. Upgrading our auditor would be.....ideal :smiley:

Obv I'm not dealing with a technical problem, but a human one. I'll go read the license agreement just to say I did but you're probably right, that someone at Elastic would have thought of this.

8

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.