Sicura Console
  1. Introduction
  2. Installation
  3. RPM Installation
  4. Container Installation
  5. Upgrades
  6. Running Sicura Console
  7. Configuration - Accounts
  8. Configuration - Database
  9. Configuration - Collector
  10. Configuration - Security
  11. Configuration - Plugins
  12. Configuration - Experimental
  13. Sidebar - Administration
  14. Sidebar - Infrastructure
  15. Sidebar - Profiles
  16. Sidebar - Reports
  17. Sidebar - Scheduling
  18. Commands
  19. Known Issues
  20. How To - Enforce compliance
  21. How To - Enforce custom profiles
  22. How To - Use the API

API Usage

Sicura Console provides a robust backend with a thorough API that allows for easy access and manipulation of any data used in the Console. This page gives an overview of how to access and make use of the available APIs.

Health check & Readiness API

In order to allow the console to be used in a Kubernetes or Scaled environment. We’ve provided healthcheck endpoints for quick checking of basic console functionality.

GET /health

  Status: 200
  Body: 'SicuraConsole OK'

GET /readiness Statuses: 200 ready, 503 not ready, or 404 not found

{"all_ready":"ok",
  "checks":{
    "core_ready":"ok",
    "db_ready":"ok",
    "system_session_ready":"ok",
    "all_plugins_loaded":"ok",
    "all_workers_started":"ok"
  }
}

Swagger Documentation

In order to build any tooling that may interface with the console, you’ll need to use the the provided REST API. All API definitions can be accessed from the Swagger API reference which is easily found by clicking the user menu at the top-right corner of the toolbar and selecting API Reference

After clicking, the swagger documentation will appear with specific access based on the user logged into the console.

Provided is a list of every API Collection that is defined in our REST framework. By clicking one it will show you ALL of the operations that can be made on that collection. For this example we’ll show the most complex API: infrastructure/v1/nodes

Start by selecting the first GET option. This is for the entire collection as opposed to the later GET which is specifically used only if you know the ID of a particular indevidual object you want to grab.

Start by clicking Try it out

This above screen has 3 sections to focus on

##### Verbose (true/false) ‘False’ will return only the id attribute. The default of true will return additional attributes for the requested object. There is a set of default attributes that are always returned with verbose enabled, and you can use the following attributes selection to choose even more.

##### Attributes This is a list of all attributes associated with a particular object or collection (node or nodes in this example). You can limit the data returned by selecting only the attributes you want.

Note: Most APIs have a set of default attribues that will return regardless of the user’s selection in the attribute field.

##### Filter When querying a large collection, the filter option can be useful as it allows you to narrow down the returned list of objects in that collection. All attributes and their specified datatype are listed for you in the filter initially. Delete any attributes you do not want to filter by and change the datatype to the data you’re looking for on any attributes you do want to filter by. For example, to return only RHEL 7 nodes you would modify the filter to be "platform": "cpe:/o:redhat:enterprise_linux:7" and delete everything else from the filter. An empty response [] will be returned if there are no matches for your filter.

Once selections have been made, click execute to get the response. An example CURL with your selections is provided, for easy copy-paste into your tool.