Accessing the KHIKA Gui
Contents
Login
In this section we assume that you have access to KHIKA SaaS on AWS or your KHIKA Virtual Appliance (VM) is ready on your premise. If not, please enroll yourself on KHIKA as SaaS or go through the section about KHIKA on-premise. The section below is relevant for KHIKA as SaaS or KHIKA on-premise, with minor variations. We have tried to be explicit to mention SaaS or on-premise whenever there is a subtle difference in the behavior. The section below assumes that you have access to KHIKA GUI to login as admin of the specific customer.
Lets get started with KHIKA GUI !
You can login into the GUI using Google Chrome Browser for further configuration of KHIKA. Please Note: KHIKA does not support any browser apart from Google Chrome.
If you have implemented KHIKA on premise, the URL is in the format : "https://IP_address_of_KHIKA_App_Server"
If you are accessing KHIKA SaaS on AWS, the URL is : https://ap-south-1.khikasiem.com
Note that the certificate for the web server is self-signed and hence the browse will warn you at this. You may ignore this warning and proceed.
Click Advanced to proceed to get below message
Following landing page for user login appears.
If you wish to install your own certificate, please perform below steps
- Login to the appliance using ‘khika’ user using your favourite ssh client
- cd /opt/KHIKA/kibana/config
- Open kibana.yml in ‘vi’ editor
- Locate section ‘server.ssl.enabled’. It looks like below
The default self-signed certificates are installed in following directory: /opt/KHIKA/3rdpartyUnix/Apache24/conf/
Note that KHIKA supports PEM-Format SSL certificates. Please refer to the documentation of your certificate vendor to convert your certificates into the PEM format, if they are in any other format.
- After you have the .crt (i.e. the certificate) and the .key (i.e. private key) files, copy them in /opt/KHIKA/3rdpartyUnix/Apache24/conf/ directory.
- Change the filenames (and directory paths if you have copied the certificate and key anywhere else) if required in kibana.yml file
- Make sure that the ‘server.ssl.certificate’ stanza points to the full path of the certificate and ‘server.ssl.key’ stanza points to the full path of the private keys.
- After editing and saving kibana.yml, come to the command prompt. Enter cd /opt/KHIKA and fire command “./khika_appserver.sh stop”
- Wait for some time (2 to 3 minutes)
- Fire command ‘./khika_appserver.sh start’ from /opt/KHIKA directory
- Connect using the fresh session of the browser
- Login using default credentials (i.e. username = admin, password = admin).
See video for logging into KHIKA as SaaS
See video for logging into KHIKA as on-premise
Change the password
After logging in for the first time (default user=admin and password=admin), it is recommended to change the password. Steps are mentioned below :
Select “Configure” screen from the left pane
Click on “Users” tab
Click on “Change Password” button
Type the desired password in “New Password” and “Confirm Password” fields. Click on “Change password”
Creating a User Group
You must be an “admin” user and a user in “admin group” for managing Users and User Groups. A User Group is like a team, in which you can add/remove team members (Users) and assign roles to them. One single User Group is mapped to a Workspace. We can decide which users are a part of this group, and hence can get access to the data in this Workspace. User groups are primarily created to restrict access to Workspaces, and thus data in them. Following are the steps to create a new User Group :
In the “Configure” screen, click on “User Groups” tab.
Click on “Create Group” button
Type say, “network_team” for Group Name field and click on “Add”
We have now successfully created a User Group. This can be mapped to a workspace. However, while creating a User Group itself, we can add Users to it as well.
Creating Users, Creating User group, Creating Workspace and Mapping Workspace to User Group are dependent on each other.
Creating a Workspace
Workspace is a logical grouping of data sources clubbed together. Workspace consists of :
- Data Aggregator – the collector component from where the data is to be pulled.
- Adapters - data collection programs (or scripts) run by the Data Aggregator that convert the raw data to indexed normalised format.
A single Data Aggregator may have multiple Adapters under it. Only a user with “Admin” role can create a new Workspace. You may want to create multiple workspaces for separating data of multiple devices. When different user groups are assigned to each Workspace, each team has access to and can monitor its own separate devices and data. For example, if you have Linux and Windows servers you can make a separate workspace for Linux team and add Linux devices in it and a separate one for Windows workspace and add windows devices in it. Further if there are multiple locations like say Pune and Jamshedpur, you can create separate workspaces for Linux Pune and Linux Jamshedpur teams. Please Note : Multiple workspaces of a single location share one aggregator of that location. For creating a workspace, follow the steps as mentioned below :
In the “Configure” screen, select “Workspace” tab
Click on “Add Workspace” button
Enter name of the Workspace as “Firewall” in the Workspace Name field. This should be an alpha-numeric string without white spaces.
Enter Data Retention (time-to-live) period in days as 30 or 60 days (depending on how long you want to retain the data).
Note on Data Retention in KHIKA: - KHIKA stores data on the local disk. The amount of data that KHIKA can store is only limited by the amount of disk you have. Data can be categorized into two types:
- Raw/Log Data (raw messages converted into key-value pairs)
- Report Data (i.e. the summarized data derived from the raw logs)
Select the User Group in which you want to add the Workspace from the Group drop-down list.
Click on the “Node” Tab. Select “localhost” as the node here and click on “Add”.
Data size field – you can keep it as default value for now.
Creating a new User
Only users with “Admin” role can create new users. Steps are mentioned below : Go to “Users” tab on the “Configure” screen.
Click on “New User”
The following dialog box is displayed.
Following table lists the various fields in the New User dialog box. Enter information in the dialog box accordingly.
| Fields | Description |
|---|---|
| User Name | Name assigned to the user. It should be at least eight characters long. |
| First Name | First name associated with the User. |
| Last Name | Last name associated with the User. |
| Email ID associated with the User. | |
| Password | Password unique to the user |
| Re-enter Password | Re-enter to confirm above password |
Click on “Add” button in the bottom
- Assign appropriate role – “Admin” or “Staff” to the new user. Admin users can further create new users, create new alert rules etc. Staff users have read-only access to the system, that serves the purpose of monitoring without any modifications to the configuration.
- Go to “Users” tab on the “Configure” screen.
Click on “Set Role” button of the user for whom you want to assign the role. (In our case it is “user1”)
Select Admin/Staff option from the “Select Role” dropdown.
Click on “Save”
User is created successfully and the list of users can be seen in this tab, for any user management.
Add the new user to the User group. Click on “User Groups” tab
Select the group to which you want to add user in the group dropdown. (In our case it is “network_team”)
Click on “Add User” button.
Select the user you wish to add to user group in “Select Users” dropdown. In our case it is “business_user”
Click on “Add” button.
Our new user “business_user” is now added to the group “network_team”.
Access Control in KHIKA
Let us try to understand a bit more about users, user groups and access control. A ‘KHIKA’ user can have access to one or more workspaces. Before creating workspaces, it is important to think which users will have access to which workspaces. Perform following steps to provide controlled access to individual users in ‘KHIKA’
- Design your workspaces with a clear view and understanding of the data
- You must know who is going to need access to the data and the level of access required
- As a thumb rule, you must create a separate workspace for the data that needs restricted access. (Example:- If you don’t want your Server team to have access to your Firewall data, create a separate workspace for your Firewall data)
- Create different “User Groups”, one per “Workspace”
- While creating the Workspace, carefully assign it to an appropriate “User Group”
- Create Users and assign them to one or more “user Group/s” depending on the access requirements.
Refer the next section for integrating your logs data into KHIKA
