webMethods API Gateway tutorial
Supported Versions: 10.7
Overview of the tutorial
This tutorial helps to understand how the InternalDataStore of APIGateway 10.7 can be secured using Search Guard or ReadonlyREST , the Elasticsearch plugins that offers encryption, authentication and authorization. In this context, these plugins helps to secure the InternalDataStore by exposing it over HTTPS protocol and enabling a basic authentication by configuring users and securing inter node communication in the clustered environment .
This tutorial covers the below steps in detail for each of the plugins Search Guard and ReadonlyREST .
- Installation and initialization of the plugin
- Protect InternalDataStore with SSL and Basic Authorization
- Changing Kibana configurations to securely connect to InternalDataStore
- Configuring API Gateway to securely connect to InternalDataStore
- Configuring the plugins with user generated certificates
Required knowledge
The reader has to have,
- a basic understanding of API Gateway and its communication with InternalDataStore for storing data
- a basic understanding of Kibana and its communication with InternalDataStore for rendering the dashboards in API Gateway
Why?
This document is intended for customers who want to protect their InternalDataStore , a wrapper over Elasticsearch, with Authentication and SSL using the external plugins that are compatible for the Elasticsearch version 7.7.1 on APIGateway version 10.7
Prerequisite steps
Complete the below prerequisites steps before get into the details of securing InternalDataStore of API Gateway using Search Guard or ReadonlyREST plugin.
- Install API Gateway advanced edition of version 10.7
Securing InternalDataStore Using ReadonlyREST
The below sections describe the details of securing InternalDataStore using ReadonlyREST plugin by installing the plugin and adding the necessary configurations in InternalDataStore, Kibana and API Gateway.
Step 1: Download of ReadonlyREST plugin compatible with Elasticsearch 7.7.1
This section explains how to download the ReadonlyREST plugin of the Elasticsearch 7.7.1 version used by the InternalDataStore.
You can download the ReadonlyREST plugin compatible for Elasticsearch 7.7.1 from https://readonlyrest.com/download
You will get an email notification after submitting the request (click GET IT NOW button) to the given email Id with a link to download the ReadonlyREST plugin. You can download it to the desired location in the file system.
Step 2: Installation and Initialization of ReadonlyREST plugin
This section explains how to install the ReadonlyREST plugin which is downloaded before.
- Stop the API Gateway server
- Open the command prompt to the location < SAG_Root>/InternalDataStore/bin
- Issue the command elasticsearch-plugin.bat install and give ‘y’ when the installation procedure prompts for additional required permissions it requires
and confirm the installation is completed with the message displayed as “Installed readonlyrest”
E.x :
- After successful installation, go to the location < SAG_Root>/InternalDataStore/config and create an empty file named readonlyrest.yml (in the same directory where elasticsearch.yml is found)
- Copy the folder sagconfig from <SAG_Root>/IntegrationServer/instances/<Instance_Name>/packages/WmAPIGateway/config/resources/elasticsearch/ to < SAG_Root>/InternalDataStore
- Now copy the sample keystore and trustore files (which will be used latter in below steps) node-0-keystore.jks and truststore.jks from < SAG_Root>/InternalDataStore/ sagconfig to < SAG_Root>/InternalDataStore/config
Step 3: Protect InternalDataStore with two-way SSL and Basic Authorization
Option 1 ) : Plain text credentials :
Open < SAG_Root>/InternalDataStore/config/ readonlyrest.yml and add below contents.
Note : Make sure the contents are indented properly as shown so that the YAML parser can parse them correctly.
readonlyrest:
access_control_rules:
- name: "Require HTTP Basic Auth"
type: allow
auth_key: Administrator:manage
ssl:
enable: true
keystore_file: "node-0-keystore.jks"
keystore_pass: a362fbcce236eb098973
key_pass: a362fbcce236eb098973
client_authentication: true
Details :
-
access control rule name “Require HTTP Basic Auth” indicates its Basic auth authentication.
-
auth_key has the credentials (username/password) in the plain text
-
ssl block is for SSL configuration.
- Property ’ client_authentication ’ denotes the 2 way SSL Authentication . By default, this is disabled.
- If you don’t want the server/InternalDataStore to validate client authentication, you can remove this property or set the value to false
Now open < SAG_Root>/InternalDataStore/config/elasticsearch.yml and add the below configuration statement and save the file.This will be used for HTTPS connection for InternalDataStore.
http.type: ssl_netty4
Default configurations of elasticsearch.yml will be as in the attached template file elasticsearch-configuration-tepmlate.conf
Note
The keystore file and its passwords keystore_pass & key_pass are shipped out of the product by default. This may not be safe for production environment. For production setup, you can generate your own certificates (keystore and trustore) and configure here.
Option 2) : Obfuscated or hashed credentials
- Exposing plain text credentials is very insecure for the application. Hence you should used obfuscated credentials.
- ReadonlyREST supports obfuscating the credentials by hashing the credentials using SHA256 algorithm.
- You can use the tool SHA-256 hash calculator | Xorbin to hash your credentials. The hashed credentials can be used in the configuration with the property auth_key_sha256
- In the above configuration, replace the auth_key configuration with auth_key_sha256 as below
readonlyrest:
access_control_rules:
- name: "Require HTTP Basic Auth"
type: allow
auth_key_sha256: 927d5619ff87227be6ca8a2cc9ee68c11dd7a08d64d1e20bdc8d86254850b418
ssl:
enable: true
keystore_file: "node-0-keystore.jks"
keystore_pass: a362fbcce236eb098973
key_pass: a362fbcce236eb098973
client_authentication: true
- Save the configuration file readonlyrest.yml.
Note : Ignore the below step if it was already done through option 1) explained above
- Now open < SAG_Root>/InternalDataStore/config/elasticsearch.yml and add the below configuration statement and save the file. This will be used for HTTPS connection for InternalDataStore.
http.type:ssl_netty4
Step 4: Secure the inter-node communication
If you have clustered the InternalDataStore instances, then the communication between them can be secured in this step as explained below.
- Open the file < SAG_Root>/InternalDataStore/config/ readonlyrest.yml and add the lines to the last
ssl_internode:
keystore_file: "node-0-keystore.jks"
keystore_pass: a362fbcce236eb098973
key_pass: a362fbcce236eb098973
- So the consolidated content of readonlyrest.yml will be as below
readonlyrest:
access_control_rules:
- name: "Require HTTP Basic Auth"
type: allow
auth_key_sha256: 927d5619ff87227be6ca8a2cc9ee68c11dd7a08d64d1e20bdc8d86254850b418
ssl:
enable: true
keystore_file: "node-0-keystore.jks"
keystore_pass: a362fbcce236eb098973
key_pass: a362fbcce236eb098973
ssl_internode:
keystore_file: "node-0-keystore.jks"
keystore_pass: a362fbcce236eb098973
key_pass: a362fbcce236eb098973
client_authentication: true
-
Add the below configuration to the file < SAG_Root>/InternalDataStore/config/elasticsearch.yml and save the file.
transport.type:ror_ssl_internode -
Start the InternalDataStore node and verify it is protected by accessing the node in HTTPS URL
https://<host>:9240with the given username/password.Confirmation for the installation/availability of ReadonlyREST plugin in InternernalDataStore startup console
Confirmation message for ReadonlyREST plugin has been loaded/started successfully
Accessing the InternalDataStore with its HTTPS URL
Step 5: Changing Kibana configurations to connect to InternalDataStore
Now we need to modify the Kibana server configurations to connect to the InternalDataStore securely over HTTPS port using basic authentication details.
- Open the file <SAG_Root>\profiles\IS_default\apigateway\dashboard\config\kibana.yml
- Remove the comments and update the following properties given below
- elasticsearch.username: Administrator
- elasticsearch.password: manage
- elasticsearch.ssl.verificationMode: certificate
- elasticsearch.ssl.certificateAuthorities:
- elasticsearch.hosts: https://:9240
- After changing these configurations open uiconfiguration.properties file at <SAG_Root>\profiles\IS_default\apigateway\config and set apigw.kibana.autostart to false
Sample configuration of kibana.yml is as below
server.port: 9405
server.host: "0.0.0.0"
server.basePath: "/apigatewayui/dashboardproxy"
elasticsearch.hosts: "https://localhost:9240"
elasticsearch.username: "Administrator"
elasticsearch.password: "manage"
elasticsearch.ssl.verificationMode: certificate
elasticsearch.ssl.certificateAuthorities: C:/SoftwareAG/InternalDataStore/sagconfig/root-ca.pem
pid.file: kibana.pid
console.enabled: false
Step 6: Changing API Gateway configurations to connect to InternalDataStore
Finally change the API Gateway configurations to connect to InternalDataDataStore securely. Follow the below steps.
- Go to <SAG_Root>/IntegrationServer/instances/default/packages/WmAPIGateway/config/resources/elasticsearch and open config.properties file. Uncomment the following properties and provide the values for them as below
- pg.gateway.elasticsearch.http.username=Administrator
- pg.gateway.elasticsearch.http.password=manage
- pg.gateway.elasticsearch.https.truststore.filepath=C:/SoftwareAG/InternalDataStore/sagconfig/truststore.jks
- pg.gateway.elasticsearch.https.truststore.password=2c0820e69e7dd5356576
- pg.gateway.elasticsearch.https.enabled=true
- After making all the configurations, start the InternalDataStore manually
- When InternalDataStore is up and running, start the Kibana server manually (To start kibana server manually run kibana.bat file at <SAG_HOME>/profiles\IS_default\apigateway\dashboard\bin )
- Now start the API Gateway and you would be able to login and create APIs. Analytics page should be accessible without any challenge window for user credentials
Step 7: Configuring ReadonlyREST with user generated certificates (optional)
Here we can see an example with a self-signed certificate which can be generated using Java Keytool.
Shut down API Gateway, InternalDataStore and Kibana.
-
Generate keystore.jks :
command to generate keystore using Keytool
keytool -genkey -alias <alias name> -keyalg RSA -keystore <File path>\keystore.jks -storetype JKSExample :
Replace this keystore.jks file with < SAG_Root>/InternalDataStore/config/keystore.jks file and update the properties keystore_pass and key_pass in < SAG_Root>/InternalDataStore/config/readonlyrest.yml
-
Export certificate from the keystore :
Command to export the certificate from the keystore
keytool -export -alias <alias name> -keystore <keystore file path> -rfc -file <filename>.certExample :
Update this certificate name in kibana configuration property elasticsearch.ssl.certificateAuthorities in <SAG_Root>\profiles\IS_default\apigateway\dashboard\config\kibana.yml
Example :
elasticsearch.ssl.certificateAuthorities: C:/work/APIGateway/test.cert
-
Generate trustore from the certificate :
Command to generate trustore file
keytool -import -alias <alias name> -file <Certificate file> -storetype JKS -keystore <File location and file name for trustore>.jksExample :
After successful creation of the the trustore file, update its details in API Gateway configuration file config.properties from <SAG_Root>/IntegrationServer/instances/default/packages/WmAPIGateway/config/resources/elasticsearch
with the properties pg.gateway.elasticsearch.https.truststore.filepath and pg.gateway.elasticsearch.https.truststore.password
Example :
pg.gateway.elasticsearch.https.truststore.filepath=C:/work/APIGateway/trustore.jks pg.gateway.elasticsearch.https.truststore.password=<your trustore password>After making all the configurations, start the InternalDataStore manually
When InternalDataStore is up and running, start the Kibana server manually (To start kibana server manually run kibana.bat file at <SAG_HOME>/profiles\IS_default\apigateway\dashboard\bin )
Now start the API Gateway and you would be able to login and create APIs. Analytics page should be accessible without any challenge window for user credentials
Securing InternalDataStore Using Search Guard
Step 1: Download of Search Guard plugin compatible with Elasticsearch 7.7.1
This section explains how to download the Search Guard plugin of the Elasticsearch 7.7.1 version used by the InternalDataStore.
You can download the Search Guard plugin version 42.1.0 compatible for Elasticsearch 7.7.1 from https://maven.search-guard.com/search-guard-suite-release/com/floragunn/search-guard-suite-plugin/7.7.1-42.1.0/search-guard-suite-plugin-7.7.1-42.1.0.zip and store it in your file system
You can also refer the compatible version of Search Guard for different Elasticsearch versions here : Latest Releases | Security for Elasticsearch | Search Guard
Step 2: Installation and Initialization of Search Guard plugin
This section explains how to install the Search Guard plugin which is downloaded before.
-
Stop the API Gateway server
-
Open the command prompt to the location < SAG_Root>/InternalDataStore/bin
-
Issue the command elasticsearch-plugin.bat install and give ‘y’ when the installation procedure prompts for additional required permissions it requires
and confirm the installation is completed with the message displayed as “Installed search-guard-7”Example :
-
After successful installation, copy the folder sagconfig from <SAG_Root>/IntegrationServer/instances/<Instance_Name>/packages/WmAPIGateway/config/resources/elasticsearch/ to < SAG_Root>/InternalDataStore
-
Now copy the sample keystore and trustore files (which will be used latter in below steps) node-0-keystore.jks and truststore.jks from < SAG_Root>/InternalDataStore/ sagconfig to < SAG_Root>/InternalDataStore/config
-
Open <SAG_Root>/InternalDataStore/config/elasticsearch.yml file. Remove all the properties that start with " searchguard " if such present and add the Search Guard properties as given below and save the file.
Search Guard properties :
searchguard.ssl.transport.keystore_type: JKS searchguard.ssl.transport.keystore_filepath: node-0-keystore.jks searchguard.ssl.transport.keystore_alias: cn=node-0 searchguard.ssl.transport.keystore_password: a362fbcce236eb098973 searchguard.ssl.transport.truststore_type: "JKS" searchguard.ssl.transport.truststore_filepath: truststore.jks searchguard.ssl.transport.truststore_alias: root-ca-chain searchguard.ssl.transport.truststore_password: 2c0820e69e7dd5356576 searchguard.ssl.transport.enforce_hostname_verification: false searchguard.ssl.transport.resolve_hostname: false searchguard.ssl.transport.enable_openssl_if_available: true searchguard.ssl.http.enabled: true searchguard.ssl.http.keystore_type: JKS searchguard.ssl.http.keystore_filepath: node-0-keystore.jks searchguard.ssl.http.keystore_alias: cn=node-0 searchguard.ssl.http.keystore_password: a362fbcce236eb098973 searchguard.ssl.http.truststore_type: JKS searchguard.ssl.http.truststore_filepath: truststore.jks searchguard.ssl.http.truststore_alias: root-ca-chain searchguard.ssl.http.truststore_password: 2c0820e69e7dd5356576 searchguard.ssl.http.clientauth_mode: OPTIONAL searchguard.enable_snapshot_restore_privilege: true searchguard.check_snapshot_restore_write_privileges: true searchguard.restapi.roles_enabled: ["SGS_ALL_ACCESS"] searchguard.authcz.admin_dn: - "CN=sgadmin"Details about the above search guard properties is given below
Item Desc Possible Values Default TRANSPORT ( 2-Way authentication is enabled by default) searchguard.ssl.transport.keystore_type Type of keystore JKS, PKCS12 JKS searchguard.ssl.transport.keystore_filepath Location of the keystore searchguard.ssl.transport.keystore_alias Keystore entry name if there are more than one entries. searchguard.ssl.transport.keystore_password Password to access keystore. searchguard.ssl.transport.truststore_type Type of truststore JKS, PKCS12 JKS searchguard.ssl.transport.truststore_filepath Location of the truststore searchguard.ssl.transport.truststore_alias Truststore entry name if there are more than one entries. searchguard.ssl.transport.truststore_password Password to access truststore. searchguard.ssl.transport.enforce_hostname_verification If true, the hostname mentioned in certificate will be validated. We set this to false as ours is general purpose self signed certs. true / false true searchguard.ssl.transport.resolve_hostname Applicable only if above property is true. If true, the hostname will be resolved against the DNS server. We set this to false as ours is general purpose self signed certs. true / false true searchguard.ssl.transport.enable_openssl_if_available Use if OpenSSL is available instead of JDK SSL. true / false true HTTP searchguard.ssl.http.enabled To enable the SSL for REST interface ( HTTP). We set this to true. true / false false searchguard.ssl.http.keystore_type Type of keystore JKS, PKCS12 JKS searchguard.ssl.http.keystore_filepath Location of the keystore searchguard.ssl.http.keystore_alias Keystore entry name if there are more than one entries. searchguard.ssl.http.keystore_password Password to access keystore. searchguard.ssl.http.truststore_type Type of truststore JKS, PKCS12 JKS searchguard.ssl.http.truststore_filepath Location of the truststore searchguard.ssl.http.truststore_alias Truststore entry name if there are more than one entries searchguard.ssl.http.truststore_password Password to access truststore. searchguard.ssl.http.clientauth_mode Option to enable 2-way authentication. REQUIRE : Client will be challenged for client certificate. OPTIONAL : Will be used if client certificate is available NONE : Ignore client certificate even if it’s available. REQUIRE, OPTIONAL, NONE OPTIONAL Search Guard Admin searchguard.authcz.admin_dn Search Guard maintains all the data in a index called “searchguard”. This is accessible to only users ( client cert which will be passed in sdadmin command) configured here. Misc searchguard.cert.oid All certificates used by the nodes on transport level need to have the oid field set to a specific value.This oid value is checked by Search Guard to identify if an incoming request comes from a trusted node in the cluster or not. In the former case, all actions are allowed, in the latter case, privilege checks apply. Plus, the oid is also checked whenever a node wants to join the cluster. ‘1.2.3.4.5.5’ searchguard.config_index_name Index where all the security configuration is stored. It’s not confgurable for now but in the future searchguard searchguard.enable_snapshot_restore_privilege searchguard.check_snapshot_restore_write_privileges To perform snapshot and restore operations, a user needs to have special privileges assigned. These two lines enable these privileges searchguard.restapi.roles_enabled Tells Search Guard which Search Guard roles can access the REST Management API to perform changes to the configuration Default configurations of elasticsearch.yml will be as in the attached template file elasticsearch-configuration-tepmlate.yml
-
Now shutdown and restart the InternalDataStore.
-
Go to the location <SAG_Root>/InternalDataStore/plugins/search-guard-7/tools and execute the below command
For Windows :
sgadmin.bat -cd …....\sagconfig\ -ks …....\sagconfig\sgadmin-keystore.jks -kspass 49fc2492ebbcfa7cfc5e -ts …....\sagconfig\truststore.jks -tspass 2c0820e69e7dd5356576 -nhnv -p 9340 -cn SAG_EventDataStoreFor Linux :
sgadmin.sh -cd …/…/…/sagconfig -ks …/…/…/sagconfig/sgadmin-keystore.jks -kspass 49fc2492ebbcfa7cfc5e -ts …/…/…/sagconfig/truststore.jks -tspass 2c0820e69e7dd5356576 -nhnv -p 9340 -cn SAG_EventDataStoreThis will initialize the InternalDataStore.
Example :
Note :
The Password -kspass 49fc2492ebbcfa7cfc5e and –tspass 2c0820e69e7dd5356576 are default passwords for keystore and truststore and the default certificates are not safe for production.
Step 3: Protect InternalDataStore with Basic Authorization
In this section let us see how an user can be provisioned in the Search Guard plugin to provide a http basic authentication.
-
Adding User name :
Go to <SAG_Root> \InternalDataStore\sagconfig and open sg_roles_mapping.yml file. Add the username (e.g. testuser) in the users list as given in the below image.
-
Adding password
The password of the user can be hashed using the tool <SAG_Root> \InternalDataStore\plugins\search-guard-7\tools\hash.bat and then add this hashed password in the file <SAG_Root> \InternalDataStore\sagconfig\ sg_internal_users.ymlExample : Hash the password
Example : Use the password in the file <SAG_Root> \InternalDataStore\sagconfig\ sg_internal_users.yml
-
After completing the configurations, initialize the Search Guard plugin again by executing the sgadmin.bat command as we did before. Restart the InternalDataStore and verify it is protected by accessing the node in HTTPS URL https://:9240 with the given username/password.
Step 4: Changing Kibana configurations to connect to InternalDataStore
Now we need to modify the Kibana server configurations to connect to the InternalDataStore securely over HTTPS port using basic authentication details.
- Open the file <SAG_Root>\profiles\IS_default\apigateway\dashboard\config\kibana.yml
- Remove the comments and update the following properties given below
- elasticsearch.username: Administrator
- elasticsearch.password: manage
- elasticsearch.ssl.verificationMode: certificate
- elasticsearch.ssl.certificateAuthorities:
- elasticsearch.hosts: https://:9240
- After changing these configurations open uiconfiguration.properties file at <SAG_Root>\profiles\IS_default\apigateway\config and set apigw.kibana.autostart to false
Sample configuration of kibana.yml is as below
server.port: 9405 server.host: "0.0.0.0" server.basePath: "/apigatewayui/dashboardproxy" elasticsearch.hosts: "https://localhost:9240" elasticsearch.username: "Administrator" elasticsearch.password: "manage" elasticsearch.ssl.verificationMode: certificate elasticsearch.ssl.certificateAuthorities: C:/SoftwareAG/InternalDataStore/sagconfig/root-ca.pem pid.file: kibana.pid console.enabled: false
Step 5: Changing API Gateway configurations to connect to InternalDataStore
Finally change the API Gateway configurations to connect to InternalDataDataStore securely. Follow the below steps.
- Go to <SAG_Root>/IntegrationServer/instances/default/packages/WmAPIGateway/config/resources/elasticsearch and open config.properties file. Uncomment the following properties and provide the values for them as below
- pg.gateway.elasticsearch.http.username=Administrator
- pg.gateway.elasticsearch.http.password=manage
- pg.gateway.elasticsearch.https.truststore.filepath=C:/SoftwareAG/InternalDataStore/sagconfig/truststore.jks
- pg.gateway.elasticsearch.https.truststore.password=2c0820e69e7dd5356576
- pg.gateway.elasticsearch.https.enabled=true
- After making all the configurations, start the InternalDataStore manually
- When InternalDataStore is up and running, start the Kibana server manually (To start kibana server manually run kibana.bat file at <SAG_HOME>/profiles\IS_default\apigateway\dashboard\bin )
- Now start the API Gateway and you would be able to login and create APIs. Analytics page should be accessible without any challenge window for user credentials
Step 6: Configuring Search Guard with user generated certificates (optional)
The API Provider can generate his own certificates to be used with Search Guard instead of the default certificates that are shipped with API Gateway. To achieve this, Search Guard provides an offline TLS tool, using which all the required certificates can be generated for running Search Guard in a production environment. Follow the below steps to generate certificates using Search Guard offline TLS tool.
Download the tool zip file from https://maven.search-guard.com/search-guard-tlstool/1.8/search-guard-tlstool-1.8.zip (the same can be found in the attachments and unzip it to a directory. Create a yaml file at \config . On executing the TLS tool command, it will read the node and certificate configuration settings from this yaml file and outputs the generated files in a configured directory. The sample file is given below. Please find the attachments for the sample file, Certificates.yml
After configuring the yaml file run the below command to generate the required certificates.
/tools/sgtlstool.bat -c …/config/Demo.yml -ca -crt
The generated certificates can be outputted at /tools/out
For further details on this refer the link provided in the References. It is mandatory to copy the certificates listed below from /tools/out to <SAG_Root>/InternalDataStore/config folder.
- Dinesh-node-1.key
- Dinesh-node-1.pem
- Dinesh-node-1_http.pem
- Dinesh-node-1_http.key
- Dinesh-client.pem
- Dinesh-client.key
- root-ca.pem
- root-ca.key
Now configure the generated certificates in the InternalDataStore elasticsearch.yml file.
After completing all the above steps start the InternalDataStore manually. After InternalDataStore is up, since the Search Guard is not initialized with the latest certificates, a log message would be shown saying that the Search Guard is not initialized. The following section provide the steps to initialize the Search Guard with the generated certificates.
-
Open command prompt and change directory to \InternalDataStore \plugins\search-guard-7\tools
-
Execute the command *sgadmin.sh -cd …....* sagconfig –nhnv –icl –cacert …....\config\root-ca.pem -cert …....\config\Dinesh-client.pem -key …....\config\Dinesh-client.key -keypass -p 9340 . A log “Done with success” will show up.
-
Now shutdown and restart the InternalDataStore. The InternalDataStore will now use the generated certificates for SSL communication.
Additional Steps while using user generated certificates
using the key tool, import the generated pem certificate “root-ca.pem” into truststore.
First, let us create an empty truststore and then import pem certificate into it.
Generate empty truststore :
keytool -genkey -keyalg RSA -alias endeca -keystore truststore.jks
keytool -delete -alias endeca -keystore truststore.jkscommand for importing pem file into truststore :
keytool -import -v -trustcacerts -alias endeca-ca -file root-ca.pem -keystore truststore.jks
After which, use the generated truststore in step 5 for the property
pg.gateway.elasticsearch.https.truststore.filepath
Troubleshooting : Search Guard Plugin
| # | Problem | Solution |
|---|---|---|
| 1 | Search Guard may not be initialized. Initialize Search Guard Using sgadmin tool. | Make sure that Search Guard is initialized properly using the steps given above |
| 2 | Error in ElasticSearch: Speaks http plaintext instead of SSL, will close the channel | It means Kibana or API Gateway is still communicating with InternalDataStore in HTTP. Configure the https protocol and certificates in kibana.yml of Kibana server and config.properties in API Gateway |
| 3 | Error while running sgtlstool.bat or enable_ssl.bat The system cannot find the path specified. | It means the JAVA_HOME was not set. configuring JAVA_HOME will resolve the issue. |
| 4 | Search Guard License Type: TRIAL, valid Your Search Guard license expires in 17 days. | Add the below line in elasticsearch.yml and restart elastic search searchguard.enterprise_modules_enabled: false |
References
ReaoonlyREST :
- Refer https://readonlyrest.com/ to know about ReadonlyREST
- Refer https://github.com/beshu-tech/readonlyrest-docs/blob/master/elasticsearch.md to know more about securing Elasticsearch with ReadonlyREST
- Refer https://forum.readonlyrest.com/ - the forum for ReadonlyREST.
Search Guard :
- Refer Installation | Security for Elasticsearch | Search Guard for Search Guard installation documentation
- Refer Search Guard Documentation 404 | Security for Elasticsearch | Search Guard detailed understanding of Search Guard offline TLS tool
- Refer Latest Releases | Security for Elasticsearch | Search Guard for Search Guard and Elasticsearch support matrix
Downloadable artifacts
- Certificates.yml file for Search Guard certificates configuration
- search-guard-tlstool-1.8.zip, Search Guard offline TLS tool
elasticsearch-configuration-tepmlate.conf (337 Bytes)
Certificates.yml (3.5 KB)
search-guard-tlstool-1.8.zip (11.6 MB)