Enterprises and IT organizations would have implemented certain workflows and tools to support their operations & management of IT resources. When moving to the cloud, part of the resources from their data centers or on-premise workloads are migrated to the cloud. The processes and tools are still to be retained to ensure smoother functioning of their operations across On-Prem and Cloud infrastructure.
There are several tools extensively used by the IT organizations for various purposes. CoreStack has integrated with some of these tools to help IT teams govern their cloud resources effectively without having to modify their existing workflows and integrations.
Integrated Tools also provide the option to extend the native capabilities supported by Cloud Services as per their own Organization standards. CoreStack acts as a bridge to connect cloud platforms and integrated tools to the extent possible. In general, CoreStack treats everything as a service, be it a Cloud or a Tool. So, for tools integration, CoreStack needs access to the tool account to authenticate and manage it.
Tools can be authenticated in multiple ways such as
Need to register an integrated tool account with CoreStack using any of the authentication mechanisms supported by the tool. After registration, some tools require additional configurations to be enabled in the tools, most of which are automated while some are to be done manually because of certain limitations with the tools.
Unlike cloud accounts, integrated tools don't have the settings None, Express or Custom in CoreStack while registration. By default, all tools are to be configured with some settings though some of them can be recommended by CoreStack.
Some tools are configured at the CoreStack's account or tenant level so any actions that happen within the multiple cloud accounts are integrated with a common tool account. Some tools can be used for automation and governance while some are aimed at managing the IT workflows.
Given below are the list of tools currently supported by CoreStack. Details of how it works are explained further in the respective tools related documentation.
When integrated with CoreStack, policy violations identified in CoreStack can be created as incidents in the selected Jira Project. This is useful if you have Jira ServiceDesk as the Incident Management tool for your team and would prefer to use that as the centralized system to capture and resolve incidents.
Navigate to Settings > Integrated Tools
Look for JIRA ServiceDesk in the Left panel under the ITSM Category.
Click on “Add Account” option in the right side to go to JIRA on-boarding page.
The on-boarding process has 3 steps shown as 3 tabs in the page:
Please keep the following information ready:
c) Provide a meaningful label such as “CoreStack_App” and click on create
d) Your API Token will be created, and you will see token displayed. Click on the “Copy” button to copy the token to clipboard and keep it ready.
Once you have the above 3 values handy, you can start the on-boarding process.
The other fields required are similar to any cloud or tool account. They include
Account Name: Any friendly and meaningful name for the Jira account
Description: Optional description about the Jira account
Environment: Choose Dev / Test / Prod as applicable
Scope: Choose Tenant if all users in the CoreStack Tenant can access this account. Choose Private if you would like this account accessible only by you.
These settings are required to help CoreStack decide on the right information to use while creating the incident tickets.
This is the last step in the onboarding process. The list of Roles in CoreStack for this Tenant will be displayed. You need to select the Roles that can have access to this Integrated Jira account. However the level of access will depend on the role.
After selecting the roles, you can click on the “Finish” button to complete the process.
You can come back and view/edit the settings of the Jira account from the same page: Settings > Integrated Tools > Jira.
Click on the account to view the settings already provided. You will see the details of the account as shown below:
If you need to modify the settings, click on the 3 dots menu at right end to select “Edit” and modify any of the settings. The process is very similar to the onboarding steps explained above.
After the account is successfully onboarded into CoreStack, you also need to configure which alerts to send to Jira and the relevant settings. The instructions as provided below:
Select your Tenant on the Left panel and then look for “Activity Queue Settings” on the right panel. Expand this section and select the Jira account from the dropdown. There are multiple activities happening in CoreStack and the destination for each of the activity such as monitoring alerts, Template failures, Policy violations etc. can be different Tools onboarded to CoreStack.
Currently for Jira, only Policy violations are supported and hence we are mapping the newly onboarded Jira account for Policies as shown below:
Next, you need to select “Configuration Management” and then map tick the checkbox under “Policy” for ITSM Change Management. This completes the tenant level configuration required.
As mentioned above, you could have Policy Violations routed to Jira ServiceDesk as tickets.
You can simulate a condition to test this:
Example: Select “Policies” module from Left Navigation Menu and then search for the Policy “AWS Security Group Port Violation Policy”
This Policy is to check for port(s) such as SSH/RDP/DB opened to public (with CIDR block 0.0.0.0/0) in an AWS account. Port(s) can be specified when executing the policy.
You can run the policy on-demand to check for the selected account and region. Provide the input parameters requested and click on “Run” button at top right. Once the policy execution is initiated, you will be redirected to the Job History page where you can see the status of the job execution.
On the left side you have all the jobs recently executed. You can select the right policy to be checked. You can then view the Input parameters provided and the Execution Logs for the policy.
Navigate to the specific Jira Project that was provided during the Tenant level configuration. You must be able to view any tickets created for Policy violations. If required, you can search by the assignee / summary description provided.
For new policy violation, an incident will be created in JIRA under selected Service Desk project with the details as provided during Tenant level configuration. For the same violation, when there is an update, the same incident gets updated every time by adding a comment in that incident.
Note: There could be cases where the initial incident creation failed for some reason or the update has different input values – the second/later updates may be created as new incident.
CoreStack supports the following use cases for Zabbix when integrated.
Versions Supported: 4.0
Pre-Requisites before On-boarding:
Login to CoreStack portal > Settings > Integrated Tools > Zabbix > Add Account The onboarding has 3 steps involved – Authentication, Configuring Triggers & Actions, Authorisation
Provide Zabbix Username, Password and API auth URL
This page will have two sections
Zabbix Host Config
This configuration is used to select the metrics (Zabbix Items) that needs to be managed by CoreStack in order to get the utilization data. Select the Cloud, Cloud account, Host Group, Template and then items under the template to collect data.
Note: The configuration is specific to Host Group/Template. To select items for other host groups/template, repeat the above steps.
Zabbix Trigger Config
This configure is used to set metric alerts and remediation actions. For eg, If CPU utilization threshold reached 70%, restart VM.
Select the CoreStack roles to provide access to this Zabbix account and click finish.
The metric items selected under “Host config” can be viewed under
You can see the configured metric’s data
All the other configured metrics will be available below the graph, select the item to see the corresponding data. You can also select another item in “Compare with” to compare the graph.
Click view forecast to see the forecast data
Map Existing Host Names with Cloud Resource Names
CoreStack will automatically fetch the utilization data based on the condition that the “resource name” (from cloud provider) matches with the “host name” configured in Zabbix. If this doesn't match, CoreStack will not collect data.
If there are hosts configured in Zabbix, which have different names in the cloud, you can follow the below instructions to map them manually.
Go to Inventory ->Enable Services -> Monitoring
Unconfigured -> This will list down all resources that are not configured for utilization data Click edit icon on the left side of the corresponding resource and provide the host name configured in Zabbix. The provided name will be validated against the corresponding Zabbix account configured. If host is valid and available, CoreStack will start collecting utilization data.
Add New Hosts to Zabbix
CoreStack provides you out of the box (Marketplace) Templates to add a new hosts to Zabbix. There are templates for adding with/without agent.
Users can execute those templates against the Zabbix account onboarded with the required inputs. This is particularly useful to include them as a standard task while provisioning new resources in the cloud.
If the configured trigger (threshold alert) under “trigger config” is reached, CoreStack will receive a metric alert. User can see the alert in Cloud ops > Threshold Alerts.
Based on the configured remediation action, CoreStack will execute the remediation if it is not manual (immediate/delayed). In case of manual, user has to manually resolve using the “Resolve” button.