30 October 2015 Engineering

Tear away your ACLs: Upgrade Your Found Cluster To Shield

By Michael Basnight

UPDATE: This article refers to our hosted Elasticsearch offering by an older name, Found. Please note that Found is now known as Elastic Cloud.

One of the benefits of being a customer of Found, our official hosted Elasticsearch service, is that you get to use Elastic’s enterprise plugins, including Shield. Found uses Shield on every cluster to ensure that your data is secure. It also has user authentication, so you can set up users and roles, and with Shield 2.0 (available in Elasticsearch 2.0 on Found), you can even limit the fields and documents that users can access! As our awesome Elastic engineers come out with features, Found customers benefit from them! #winning.

A brief history of Found ACL

Before Found implemented Shield, we had our own way of doing Access Control Lists (ACL). Some of our long time customers very likely implemented those ACLs in production. The legacy ACLs, while they worked very well, they had their downsides. It was a piece of infrastructure Found had to implement and maintain. It was also easy to make mistakes because of the syntax of the ACL. 

upgrade-found-acl-kittens.jpg

As you can imagine, we jumped at the chance to make our infrastructure less complicated by migrating all our clusters to use Shield. Now we have a world class solution providing ACL and node-to-node security for every cluster on Found! Now doesn’t that just give you warm fuzzies?

Why do you care?

And its not just about the fact that we have the best security solution powering our clusters. You also get more security features with Shield. More than all other hosted Elasticsearch offerings. Shield 2.0 introduces things like impersonation and document and field level security. And of course if you are still on 1.7.x, you can use index and alias level security.

Transition path for ACL

Lastly, there is still a possibility that your cluster is still running legacy ACLs. Fear not, Shield is still running in the background, keeping node-to-node communication secure, so nothing can connect to your cluster and get your data. If you have yet to convert, below are some examples for migrating your ACLs without issues!

If you are running the legacy ACL without changes, you have two userssearchonly and readwrite. Shield uses the concept of roles, and you have three optionsadminreadwrite and readonly. You really have two transition paths here. You can map your legacy readwrite user to admin, which has access to everything, or you can map it to readwrite. The difference is that the readwrite user has monitor access and admin has all access, explained here.

Below is an example of a Shield config in Found, mapping readwrite to admin.

# This is the users file in the Shield editor in Found
readwrite: READWRITE_PASSWORD
searchonly: SEARCHONLY_PASSWORD
    
# This is the 'users per role' file in the Shield editor in Found
admin: readwrite
readonly: searchonly
    

So as you can see, we have provided the same user/pass from before, and mapped them to their Shield roles. Remember, this is extensible.

Below is an example of a Shield config in Found, without replacing the admin user.

# This is the users file in the Shield editor in Found
admin: NEW_ADMIN_PASSWORD
readwrite: READWRITE_PASSWORD
searchonly: SEARCHONLY_PASSWORD
    
# This is the 'users per role' file in the Shield editor in Found
admin: admin
# You can optionally add readwrite to the admin user if you like
# admin: admin, readwrite
readwrite: readwrite
readonly: searchonly
    

Remember, the ACL support can be modified on Found without any service interruption, and no changes to your client side passwords. Just a few clicks in the UI, and you can be running Shield ACL! For more information, there is documentation here and here. Happy Shielding!