ScriptRunner is the central hub for PowerShell and communicates with its users, the target systems as well as with third party systems. Several aspects are important for communication:
the underlying safety concept
the communication protocols used
The communication partners involved
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 the zones – the shell model
Three security levels are defined in the figure:
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.
A second zone contains the ScriptRunner host and central PowerShell code management. The necessary security level is high.
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:
Client in the user zone
ScriptRunner Host in the ScriptRunner Zone
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 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
VMWare, Citrix or others
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.
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.
https://support.scriptrunner.com/wp-content/uploads/2019/05/Secure1zu1-t.jpg10001000Daniel Finkenzellerhttps://support.scriptrunner.com/wp-content/uploads/2018/02/ScriptRunner_logo.pngDaniel Finkenzeller2019-08-08 15:44:422019-10-09 13:35:56Manage PowerShell credentials with Pleasant password server
https://support.scriptrunner.com/wp-content/uploads/2019/04/Network_1zu1.jpg387387Frank Kresse, Head of Productshttps://support.scriptrunner.com/wp-content/uploads/2018/02/ScriptRunner_logo.pngFrank Kresse, Head of Products2019-04-04 19:34:152019-10-09 13:36:15ScriptRunner version 2019R1 - what's new?
https://support.scriptrunner.com/wp-content/uploads/2019/02/Neue-Version-2018R3-gold-2.png319400Frank Kresse, Head of Productshttps://support.scriptrunner.com/wp-content/uploads/2018/02/ScriptRunner_logo.pngFrank Kresse, Head of Products2018-10-26 16:20:472019-10-09 13:36:45Feature overview of the new version 2018R3