SECURITY FIRST

WHITE PAPER

Security Features and Best Practices

Introduction

An infrastructure orchestration platform is central to an enterprise deployment and by definition, it must have access to data and configurations throughout the network. Therefore the security of the system itself is of primary concern. It is essential that all components of the orchestration platform be both designed and deployed securely.

The security concepts of the Orchestral Intent Based Intelligent Infrastructure Orchestration (iBiio) solution can be organized into four areas:
  • Server Security

  • Application Security

  • Communication Security

  • Content Security

Each of these layers need to be designed and deployed with security as a central goal for the overall system.

Server Security

The core software of the iBiio solution is the iBiioST2 application, which can be installed on RedHat/CentOS and Ubuntu Linux systems. Server administrators should follow enterprise best practices for Linux server hardening to ensure that the underlying operating systems are adequately secure. For more information on options and recommendations for secure installations refer to the documentation for RedHat/CentOS and Ubuntu.

Application Security

Authentication

iBiioST2 includes an authentication service that is responsible for handling user authentication and generating time-limited access tokens. When authentication is enabled (the default), those access tokens are used to authenticate against the iBiioST2 REST APIs.

The service can be configured with different backends (i.e. PAM, LDAP, etc.) to handle the authentication. Different backend packages are available from the iBiioST2 repo.

API Keys

iBiioST2 also supports API keys. These differ from tokens in that they do not expire. This makes them suitable for integrations with other applications, e.g. through webhooks.

For security purposes the is only shown at create time. iBiioST2 itself does not store this API Key value in its database, only a one-way hash is stored. It is not possible to retrieve an API Key after creation. In the event the API key is lost, there is no method available within iBiioST2 to read and access the same key, the only alternative is to delete the old key and create a new key.

Role Based Access Control (RBAC)

Role Based Access Control (RBAC) allows system administrators to restrict users’ access and limit the operations they can perform. For instance, a team is granted access to a limited set of contents such as a set of iBiioST2 packs or as granular as a number of iBiioST2 actions that the team can list, view, and/or execute.

A user represents an entity (person/system) which needs to be authenticated and interacts with iBiioST2 through the API. User permissions are represented as a union of permission grants which are assigned to all the user roles.

A role contains a set of permissions (permission grants) which apply to the resources. Permission grants are usually grouped together in a role using specific criteria (e.g. by project, location, team, responsibility, etc.). Permission can be granted at different levels of the application: platform level, pack level or action level.

By default, when a new iBiioST2 user is created, this user has no roles assigned to it, meaning the user has access to perform any API operation which is behind the RBAC wall. Roles are assigned to the users. Each user can have multiple roles assigned and each role can be assigned to multiple users.

Patch Schedule

Major releases are typically introduced every three to six months. However, any security vulnerabilities discovered in between releases are considered high priority and will be addressed in an immediate update.

The industry de facto standard of Responsible Disclosure for handling security issues is followed. This means the issue will only be disclosed after a fix for the issue has been developed and released and full credit will be attributed to the person who reported the issue.

It is recommended that users update as soon as practical whenever a new release is available.

Default Passwords

There is no default admin username or password for the platform, but those are required during installation. It is recommended to choose a unique admin username and strong password prior to or during the installation process.

In addition, when attached services, such as MongoDB, RabbitMQ, Redis, Corosync or Pacemaker are installed, they have authentication disabled or use a default static password. It is also essential to update these passwords. Note that if installed with the installation script, this is done automatically.

Communication Security

iBiioST2 interacts with the environment through actions and sensors. Sensors are a way to integrate external systems and events with iBiioST2. Sensors either periodically poll some external system, or passively wait for inbound events. These sensor events, when matched to conditions in rules, will trigger action execution in iBiioST2.

Sensors must follow the iBiioST2-defined sensor interface requirements. Actions are pieces of code that can perform arbitrary automation or remediation tasks in your environment.

Sensors and actions should be configured to interact with the infrastructure elements over encrypted TLS/SSL sessions. In addition to sensors, webhooks allow you to integrate external systems with iBiioST2 using HTTP webhooks. Unlike sensors which use a “pull” approach, webhooks use a “push” approach. They push triggers directly to the iBiioST2 API using HTTP POST requests. Webhook POSTs should also be encrypted with TLS/SSL.

Services

For MongoDB, RabbitMQ, Redis, Corosync and Pacemaker services, SSL/TLS should be enabled for encrypted communication. When deployed locally, they should be configured to only listen to the localhost. If deployed separately, then they should be deployed with internal IP addresses, and protected with an external firewall that only allows the platform server access to them. The clustering software necessary for High Availability deployment should communicate on a private internal network. These services do not need to be directly accessed by users.

Content Security

Contents include iBiioST2 packs where actions, workflows, rules, sensors, and configuration are defined. iBiioST2 has a datastore service where configuration that is used by workflows and actions can be encrypted. The goal of the datastore service is to allow users to store common parameters and their values within iBiioST2 for reuse in the definition of sensors, actions, and rules. The datastore service stores the data as a key-value pair.

The key-value store allows users to store encrypted values (secrets). Symmetric encryption using AES-256 is used to encrypt secrets. The iBiioST2 administrator is responsible for generating the symmetric key used for encryption/decryption. Note that the iBiioST2 operator and administrator (or anyone else who has access to the key) can decrypt the encrypted values.

By default, getting a key tagged as secret (via –encrypt) will always return encrypted values only.

Summary

The Orchestral iBiio solution is designed to enhance the security of any enterprise in which it is deployed through a variety of tools and features. The first step of leveraging these advantages is to deploy the platform itself in a secure fashion. These best practices are a high level roadmap to secure deployments, and will be built upon as new features and capabilities are introduced.

Getting Started

iBiioST2 is available as a free 45-day Proof of Value evaluation. To get started, just click the "FREE TRIAL" button at the top of this page and complete the Trial Request Form. If you'd like to see a demo first, just click the "Book an iBiioST2 Demo" button below to book a date/time that works best for you. Otherwise, you can get started by emailing us at info@orchestral.ai.

Ready to see for yourself?

We'd love to show you how iBiioST2 enables you to address a broad spectrum of orchestration & automation challenges.
Book an iBiioST2 Demo
About Orchestral.ai
Orchestral.ai is pioneering the advent of "Autonomous Infrastructure" where artificial intelligence, IT orchestration and workflow automation come together for infrastructure & operations (I&O) teams to achieve their organization's digital aspirations. Founded by a team of highly experienced tech-industry professionals, Orchestral.ai is delivering its Intent-Based Intelligent Infrastructure Orchestration (iBiio) platform to Fortune 500 and Global 2000 companies.
Subscribe to receive updates:
Subscribe
Orchestral handles your data in accordance with our privacy policy.