ReadonlyREST plugins officially support installation on Elasticsearch and Kibana working in Kubernetes cluster and managed by the ECK operator.
You can choose one of the following installation methods:
Installation methods
Using our Docker images from Docker Hub
The easiest and fastest method to start with a ROR-powered ELK stack on ECK is to use our official images. We will show you how to do it in the following sections:
Elasticsearch node with ReadonlyREST plugin
If we want to add the ReadonlyREST plugin to the simple Elasticsearch cluster specification from ECK Quickstart we should do it as below:
apiVersion:elasticsearch.k8s.elastic.co/v1kind:Elasticsearchmetadata:name:quickstartspec:version:8.14.3# check https://hub.docker.com/r/beshultd/elasticsearch-readonlyrestimage:beshultd/elasticsearch-readonlyrest:8.14.3-ror-latestnodeSets: - name:defaultcount:1config:node.store.allow_mmap:falsepodTemplate:spec:containers: - name:elasticsearch# we have to run our image as root (id: 0) - after the required patching step Elasticsearch will be run using "elasticsearch" user (id: 1000)securityContext:runAsNonRoot:falserunAsUser:0runAsGroup:0env:# we have to explicitly agree to patch the ES binaries (the patching step will be done only once) - name:I_UNDERSTAND_IMPLICATION_OF_ES_PATCHINGvalue:"yes"# these two passwords are used by "elastic-internal" and "elastic-internal-probe" users - these users are used by ECK - name:INTERNAL_USR_PASSvalueFrom:secretKeyRef:name:quickstart-es-internal-userskey:elastic-internal - name:INTERNAL_PROBE_PASSvalueFrom:secretKeyRef:name:quickstart-es-internal-userskey:elastic-internal-probe# Kibana service account to handle internal Kibana requests - name:KIBANA_SERVICE_ACCOUNT_TOKENvalueFrom:secretKeyRef:name:quickstart-kibana-userkey:token# the initial readonlyrest.yml file loaded by ROR plugin during ES startupvolumeMounts: - name:config-rormountPath:/usr/share/elasticsearch/config/readonlyrest.ymlsubPath:readonlyrest.ymlvolumes: - name:config-rorconfigMap:name:config-readonlyrest.yml
ReadonlyREST initial settings
The initial settings can be defined as ConfigMap like this:
Notice that if you use ROR Enterprise, you can take advantage of the Cluster-wide Settings functionality and reload configuration on all your nodes without restarting K8s' PODs.
Kibana node with ReadonlyREST plugin
If we want to add the ReadonlyREST plugin to the simple Kibana instance specification from ECK Quickstart we should do it as follows:
apiVersion:kibana.k8s.elastic.co/v1kind:Kibanametadata:name:quickstartspec:version:8.14.3# check https://hub.docker.com/r/beshultd/kibana-readonlyrestimage:beshultd/kibana-readonlyrest:8.14.3-ror-latestcount:1elasticsearchRef:name:quickstartconfig:# define ROR Kibana settings # readonlyrest_kbn.store_sessions_in_index: true # we have to set it to true when we define more than one nodereadonlyrest_kbn.cookiePass:"12345678901234567890123456789012345678901234567890"podTemplate:spec:# we have to run our image as root (id: 0) - after the required patching step Kibana will be run using "kibana" user (id: 1000)securityContext:runAsNonRoot:falserunAsUser:0runAsGroup:0containers: - name:kibanaenv:# we have to explicitly agree to patch the KBN binaries (the patching step will be done only once) - name:I_UNDERSTAND_AND_ACCEPT_KBN_PATCHINGvalue:"yes"# we have to provide a ROR license if we want to use ROR Pro or Enterprise (if the license is not provided, then ROR Free is used) - name:ROR_ACTIVATION_KEYvalue:"<YOUR_ACTIVATION_KEY/>"
And these are all differences we need to make to run ECK Quickstart with ReadonlyREST instead of X-Pack security.
Using Docker images built by you and stored in your registry
As you probably noticed, our docker images have to be run with root privileges. It's due to legal reasons and you, as a user, have to confirm that you agree to do the patching steps. If running a pod with root privileges is something you cannot accept, you can create your own image with the patching step done at the image creation level (not at runtime as our image does) and save it your your own registry.
Expand to see details
Elasticsearch with ROR custom image
The minimal Elasticsearch with ROR image definition looks like this:
# 'Dockerfile' file content
ARG ES_VERSION
FROM docker.elastic.co/elasticsearch/elasticsearch:${ES_VERSION}
ARG ES_VERSION
ARG ROR_VERSION
USER elasticsearch
RUN /usr/share/elasticsearch/bin/elasticsearch-plugin install --batch "https://api.beshu.tech/download/es?esVersion=$ES_VERSION&pluginVersion=$ROR_VERSION&email=[YOUR-EMAIL-ADDRESS]"
USER root
RUN /usr/share/elasticsearch/jdk/bin/java -jar /usr/share/elasticsearch/plugins/readonlyrest/ror-tools.jar patch
USER 1000:0
And place the elasticsearch-with-ror image in your registry.
Elasticsearch node with ReadonlyREST plugin
If we want to add the ReadonlyREST plugin to the simple Elasticsearch cluster specification from ECK Quickstart we should do it as below:
apiVersion:elasticsearch.k8s.elastic.co/v1kind:Elasticsearchmetadata:name:quickstartspec:version:8.14.3# this is the image from your registryimage:elasticsearch-with-rornodeSets: - name:defaultcount:1config:node.store.allow_mmap:falsepodTemplate:spec:containers: - name:elasticsearchenv:# these two passwords are used by "elastic-internal" and "elastic-internal-probe" users - these users are used by ECK - name:INTERNAL_USR_PASSvalueFrom:secretKeyRef:name:quickstart-es-internal-userskey:elastic-internal - name:INTERNAL_PROBE_PASSvalueFrom:secretKeyRef:name:quickstart-es-internal-userskey:elastic-internal-probe# Kibana service account to handle internal Kibana requests - name:KIBANA_SERVICE_ACCOUNT_TOKENvalueFrom:secretKeyRef:name:quickstart-kibana-userkey:token# the initial readonlyrest.yml file loaded by ROR plugin during ES startupvolumeMounts: - name:config-rormountPath:/usr/share/elasticsearch/config/readonlyrest.ymlsubPath:readonlyrest.ymlvolumes: - name:config-rorconfigMap:name:config-readonlyrest.yml
And place the kibana-with-ror image in your registry.
Kibana node with ReadonlyREST plugin
If we want to add the ReadonlyREST plugin to the simple Kibana instance specification from ECK Quickstart we should do it as follows:
apiVersion:kibana.k8s.elastic.co/v1kind:Kibanametadata:name:quickstartspec:version:8.14.3# this is the image from your registryimage:kibana-with-rorcount:1elasticsearchRef:name:quickstartconfig:# define ROR Kibana settings # readonlyrest_kbn.store_sessions_in_index: true # we have to set it to true when we define more than one nodereadonlyrest_kbn.cookiePass:"12345678901234567890123456789012345678901234567890"podTemplate:spec:containers: - name:kibanaenv:# we have to provide a ROR license if we want to use ROR Pro or Enterprise (if the license is not provided, then ROR Free is used) - name:ROR_ACTIVATION_KEYvalue:"<YOUR_ACTIVATION_KEY/>"
And these are all differences we need to make to run ECK Quickstart with ReadonlyREST instead of X-Pack security.
Using an Init Container
This is not a recommended method.
It's possible to install ROR using an Init Container. Unfortunately, this method is not as easy to use in the case of ROR. This is due to the required ReadonlyREST patching step (for both plugins), which allows ROR to work with Elasticsearch/Kibana. During this step, the ROR patcher tool modifies some of the Elasticsearch and Kibana binaries. Different versions of Elasticsearch/Kibana require different binaries to be modified. In order to do this in a Kubernetes-based environment, we need to mount appropriate locations from the Elasticsearch/Kibana POD to the init container that will install ROR. The volumes should have write permissions because of the changes made by the ROR patcher. You can still use this method, but as you can see it's not that easy.
Expand to see details
If you are still interested in this one, please take a look at the examples in our repository: