Secure communication with ScriptRunner – the shell model

In this blog article you get to know the shell model and learn which security concept ScriptRunner is based on and how the communication relationships of ScriptRunner look like in a typical customer environment.

Shell by shell – the shell model as a security concept

Before we deal in detail with the individual communication protocols and partners, it is worth taking a look at the basic security concept, which ScriptRunner depicts. The starting point is a shell model. In contrast to conventional views of network sections, firewalls and VPNs, the shell model offers the advantage of defining security levels and thus zones independently of the concrete infrastructure.

The ScriptRunner shell model with three security zones

Three security levels are defined in the figure:

1. The first, inner zone accommodates the central IT resources, e.g. Active Directory, Exchange Server, etc. From ScriptRunner’s point of view, the target systems are located in this zone. The necessary security level is highest here.
2. A second zone contains the ScriptRunner host and central PowerShell code management. The necessary security level is high.
3. The user zone is the area in which the users and their resources are located. In the case of ScriptRunner these are help desk users and administrators who use the browser apps and DevOps who work with the PowerShell ISE Add-on. The security level here would be “normal.”

The core principle in this model is that communication between two partners may only take place across a shell boundary. Access from the user zone to the inner zone is not permitted.

This means that communication can only take place between actors in neighboring shells.

This results in the following permitted communication relationships:

• An administrator or help desk employee uses the browser app to start a PowerShell action in ScriptRunner.
• An external system can start an action for automation only via a connector in ScriptRunner. The call by the source system would be assigned to the user zone.
• Only the ScriptRunner host is allowed to run PowerShell scripts on the target systems.

As a consequence, there are significant advantages for the entire IT security because only this model enables an effective separation of rights and access. A help desk employee only has access to the actions assigned to him with his user account. Only the ScriptRunner host has the necessary rights to execute the script of the action on the target system. The user is completely decoupled from this and therefore requires no knowledge of the administrative rights for the target systems. The same applies to calling systems such as monitoring, ITSM and workflows.

The concept of security shells can be extended by further shells, e.g. for administrative access via the Internet or from Internet-based monitoring or ITSM systems to ScriptRunner.

The communication partners

In a typical customer environment, different actors are involved in the communication with ScriptRunner. The communication partners are distributed over the three levels mentioned above:

1. Client in the user zone
2. ScriptRunner host in the ScriptRunner zone
3. Target systems in the system zone

The ScriptRunner communication relationships

1st Client in the User Zone

At this level, users as well as various third party systems call functions in ScriptRunner:

• The ScriptRunner Admin and Delegate App user interfaces are browser-based. Authorized users can administrate ScriptRunner as well as start ScriptRunner Actions.
• You can use the PowerShell ISE to execute commands and write PowerShell scripts. The ScriptRunner ISE Add-on allows DevOps to directly access the script repository on the host.
• This level also includes the third-party webservice clients (monitoring, ITSM, workflows) and the ScriptRunner mailbox for the email inbound connector.
  
  

2. ScriptRunner Host in the ScriptRunner Zone

At the ScriptRunner level two central components of ScriptRunner are shown:

• The Internet Information Server (IIS) from Microsoft serves as the web server for the web apps, but other web servers can also be used. The functionality serves exclusively to deliver the JavaScript and HTML files of the Web Apps to the calling browser.
• The core of ScriptRunner, the ScriptRunner Host is the central instance for all activities around PowerShell. It controls and monitors all central functions for automating, executing, monitoring, managing, and developing PowerShell scripts. Installed on a Windows server, it also monitors licenses, access rights, and host configuration.

At the execution level, there are typically the various target systems on which PowerShell scripts are to be executed in a controlled manner, for example:

• Hyper-V and Windows Server
• Windows clients
• exchange server
• VMWare, Citrix or others
• Microsoft365 Services
• Azure Services

From ScriptRunner’s point of view, there are optionally two further systems on this level:

• SQL Server for the reporting/auditing database for long-term storage
• Mail Server for sending reports
  
  

The communication flow

The following example shall illustrate the entire process. A user starts the Delegate App and performs an Action in his role context.

The web browser contacts the IIS to call up the Delegate App and requests the website content.

The IIS web server returns the requested content in HTML, JavaScript and CSS format to the browser. Communication takes place via the standardized transmission protocols HTTP and HTTPS, usually via port 80 (HTTP) and port 443 (HTTPS).

The JavaScript application then starts in the browser and contacts the ScriptRunner host via the web service interface. The client uses the web service protocol ODATA/REST on the standard port 8091 for this purpose. If the authentication was successful, the data is loaded into the application. The Delegate App displays the tiles assigned to the user or group.

Now the user can select an Action, fill in the necessary entries and start the action. All execution policies, target systems, connectors, administrative accounts, roles and settings are organized in the central ScriptRunner repository. The host now starts an isolated PowerShell process in the script policy with all necessary data and information, contacts the target system and sends it the job “Execute this script”. After the scripts in the PowerShell have been executed on the target system, the result data is sent back to the ScriptRunner host.

The ScriptRunner Service then checks the result. If it is correct, it is forwarded to the application and the user is informed about the successful execution or, alternatively, an error.

The communication between ScriptRunner Service and target system depends primarily on the target system. This can be done using the standard PowerShell protocol (ports 5985 and 5986), http/https (Exchange), or management protocols from products from various vendors. In this case, the protocol conversion takes place in the PowerShell module of the respective product.

For an error-free operation it is very important to understand the communication and the process of the specific target system and to adapt the configuration in ScriptRunner accordingly.