Secure communication with ScriptRunner – the shell model

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 the zones – the shell model

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 Service Desk users and administrators who use the browser apps and DevOps who work with the PowerShell ISE app. 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 neighbouring shells.

This results in the following permitted communication relationships:

• An administrator or service 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 service 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 zone Central IT resources

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 PowerShell actions.
• You can use the PowerShell ISE to execute commands and write PowerShell scripts. The ScriptRunner ISE app allows DevOps to directly access the script repository on the host.
• This level also includes the third-party Web service clients (monitoring, ITSM, workflows) and theScriptRunner mailbox for the e-mail 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.

Atthe 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
• Office365 Services
• Azure Services
• uses
• 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

An example is intended to 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 WebService 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 host then checks the result. If it is correct, it is forwarded to the application and the user is informed about the successful execution or an error.

The communication between ScriptRunner host 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 function it is very important to understand the communication and the process of the specific target system and to adapt the configuration in ScriptRunner accordingly.