ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

AIOps - How to create jarvis apis and elasticsearch endpoints that are disabled by default?

book

Article ID: 226870

calendar_today

Updated On:

Products

DX Operational Intelligence DX Application Performance Management CA App Experience Analytics

Issue/Introduction

Starting from DX Platform 21.x Jarvis API and elastic search routes/ingress are disabled by default due to security purpose

Below is the process to recreate the endpoints.

 

Cause

Jarvis APIs: 

- Please note that the APIs endpoints exposed from saas have always been the nginx endpoints and direct jarvis APIs was never exposed in saas. However in on-prem builds we had both the direct jarvis API routes and also the nginx endpoints causing security concerns and configuration issues and so the direct APIs route is removed going forward. 

- Although we have removed the direct jarvis APIs route/ingress by default the required subset of the Jarvis APIs (Ingestion & Health) are already exposed through nginx and so the nginx route/ingress can be used instead of the direct Jarvis route, for example, http://doi-nginx.<endpoint>/health:

Elastic APIs:
- This is removed primarily due to security concerns as exposing ES exposes almost all our data without any authentication and also leaves the cluster vulnerable (e.g it's very easy for someone to delete all data by giving a simple delete query)
- The ES Health/stats APIs can be all invoked from within the cluster using curl/command line. 
- The queries involving actual data can also be done from command line/curl within the cluster but it will be hard to interpret the results and so the below OI query endpoints can be used to securely query alarms/events/logs etc. 
- Also although we are not creating the ES route by default it is fairly trivial for someone to go to openshift/k8s console and create a temporary route for troubleshooting. However it's very important for security reasons not to keep these routes enabled forever due to the reasons mentioned above. But it might be OK for customers to create a route at the start of a troubleshooting session and delete it after the session is over. 
 
 
 

Environment

DX Platform 21.3.x and higher

Resolution

1) Open the appropriate configuration yml file:

If you are using secured routes (tlsEnabled), then follow below steps :

a) For Jarvis APIs : (example apis.10.109.32.88.nip.io)

oc/kubectl apply -f <INSTALL_DIR>/files/meta/plain/nextgen/dx-base/install/jarvis-apis-ingress.secure.yml


b) For ElasticSearch: (example es.10.109.32.88.nip.io)

Depending on cluster size (small / medium)

oc/kubectl apply -f <INSTALL_DIR>/files/meta/plain/nextgen/dx-base/install/jarvis-elasticsearch-ingress.secure.small.yml

oc/kubectl apply -f <INSTALL_DIR>/files/meta/plain/nextgen/dx-base/install/jarvis-elasticsearch-ingress.secure.medium.yml

 

If using in-secured routes (tlsDisabled), then follow below steps:

a) For Jarvis APIs:

oc / kubectl apply -f <INSTALL_DIR>/files/meta/plain/nextgen/dx-base/install/jarvis-apis-ingress.insecure.yml


b) For ElasticSearch:

Depending on cluster size (small / medium)

oc/kubectl apply -f <INSTALL_DIR>/files/meta/plain/nextgen/dx-base/install/jarvis-elasticsearch-ingress.insecure.small.yml

oc/kubectl apply -f <INSTALL_DIR>/files/meta/plain/nextgen/dx-base/install/jarvis-elasticsearch-ingress.insecure.medium.yml

2) Replace the below values in the yml files:

{{namespace}}
{{routerip}}

Examples:

Replace {{namespace}} with dxi

Replace {{routerip}} with es.10.109.32.88.nip.io

Additional Information

https://knowledge.broadcom.com/external/article/190815/dx-aiops-troubleshooting-common-issues.html

Attachments