Securely using the automation framework

When you adopt the automation framework, it is essential to consider the potential security risks and take the appropriate steps to protect your systems and prevent unauthorized access. Consider the following guidelines to optimize the secure usage of the automation framework.

Limiting the enablement of action sensors

Before you enable the action sensors on agents, you must understand how they might affect action execution on hosts and agents.

Deciding which sensors to enable on agents

On the default agent configuration, all the action sensors are disabled (off). You must opt in to use the action sensors. When you consider which agents to enable with action sensors, it is important to enable only those sensors where the actions must be run.

  • HTTP, Ansible, and Issue action sensors: Consider only enabling a single agent for each type of desired sensor to serve as a point of control for action execution.
  • Script actions: Consider enabling the script sensor on many agents to allow scripts or commands to run directly on the host operating system. Make sure that the script sensor is enabled for only those agents that are intended to expose this capability.

Why you must selectively enable sensors on agents

Selectively choose the agents on which you want to enable the action sensors to limit the possibility of action execution on an unintended host or system. Also, create a dedicated user with limited access for running the script actions.

  • HTTP, Ansible, and Issue action sensors: As these sensors are designed to communicate with the third-party (external) systems to invoke requests, you need to use a dedicated agent to serve as the single point of control. Using a dedicated agent helps to reduce the risk of unwanted access to the automation framework and also simplifies the action sensor configuration and maintenance.

  • Script actions: Enable the sensor only for the agents where it is safe and desired to enable potential access to system commands on the host.

Managing access with user permissions

Before you grant access to the automation framework, you must understand how these permissions might impact the operations on the Automation menu.

Deciding which permissions to grant on the automation framework

Use automation user permissions to selectively grant access to users for the various capabilities of the automation framework. The user permissions control access to the various capabilities in the Instana UI and through the API, and are disabled by default for most users.

  • Configuration of automation actions: The users with this permission can create, modify, and delete actions from the action catalog.

    • Only the users who are authenticated with two-factor authentication can work with the write operations on the action catalog. This authentication provides an extra layer of security to make sure that only the verified users can create or modify actions that can run through the action sensors.
  • Execution of automation actions: The users with this permission can run the actions from the catalog on agents with enabled sensors that matches the action type.

  • Configuration of automation policies: The users with this permission can create, modify, and delete automation policies.

  • Deletion of automation action history: The users with this permission can delete action runs from Action History.

Why you must selectively grant permissions to the automation framework

By using the automation framework, access to various capabilities of the framework from both the Instana UI and API is limited to the set of users with that access.

Creating a dedicated user for script actions

Before you grant access to a user on the host system, you must understand the scope of access. Defining the scope of access on the host system for a user

Defining the scope of access on the host system for a user

The script sensor requires the runAs user to be specified to run any scripts or commands on the host system. Create a dedicated user with limited system access for this purpose. Use the relevant operating system capabilities to create and limit this user’s scope. This user’s limited access must include:

  • Access to only the system commands, interpreters, binaries, libraries, and executables that are required for action invocation from Instana.

  • Access to only the file system locations, such as files and folders that are required for automation framework scripts to run successfully.

    • At minimum, the user needs only the read/write/execute access to the scriptExecutionHome directory as specified in the script sensor configuration.

Why you must define the scope of access for a user

Expected use of the script sensors with the automation framework includes script actions in the catalog that can be run by any Instana user with the appropriate permission. Creating a dedicated user with limited system access for these actions prevent the actions that are invoked from Instana from accessing unauthorized content or binaries on the file system.

Managing sensitive information with a secret manager

You must secure data when you use the automation framework.

How to protect sensitive data when you use the automation framework:

Use a secret manager to manage any sensitive data that might be required by the automation framework in the following places:

  • Sensitive parameters in the catalog. Use the Vault parameter type to pull the parameter values from a configured Hashicorp Vault at runtime. Use this parameter type to avoid referencing or storing any plain-text passwords, tokens, or other sensitive data when you define or run actions.

  • Sensitive data specified in agent configuration. Specifying the sensitive data includes fields, such as passwords for the Windows runAs user (script sensor) and Ansible token (Ansible sensor).

Why you must use secret manager when you use the automation framework:

Using Secret Manager for secret management prevents any plain text passwords, or tokens from being exposed when you use the automation framework UI or API. Similarly, using Vault can avoid the need to declare any plain-text passwords or tokens in an agent configuration file.