Book Image

PowerShell Core for Linux Administrators Cookbook

By : Prashanth Jayaram, Ram Iyer
Book Image

PowerShell Core for Linux Administrators Cookbook

By: Prashanth Jayaram, Ram Iyer

Overview of this book

PowerShell Core, the open source, cross-platform that is based on the open source, cross-platform .NET Core, is not a shell that came out by accident; it was intentionally created to be versatile and easy to learn at the same time. PowerShell Core enables automation on systems ranging from the Raspberry Pi to the cloud. PowerShell Core for Linux Administrators Cookbook uses simple, real-world examples that teach you how to use PowerShell to effectively administer your environment. As you make your way through the book, you will cover interesting recipes on how PowerShell Core can be used to quickly automate complex, repetitive, and time-consuming tasks. In the concluding chapters, you will learn how to develop scripts to automate tasks that involve systems and enterprise management. By the end of this book, you will have learned about the automation capabilities of PowerShell Core, including remote management using OpenSSH, cross-platform enterprise management, working with Docker containers, and managing SQL databases.
Table of Contents (19 chapters)

Listing out the execution policies and setting a suitable one

This is a Windows-only recipe. Skip this if you never plan to work on Windows.

There was a time when running scripts on Windows computers was a cakewalk. Windows computers were highly prone to remote script executions. With PowerShell, Microsoft added a safety belt that allowed the user some control over how PowerShell scripts were loaded. Some specific models of script executions got restricted, which plugged some holes in the system.

It is important to remember that execution policies are not a security feature. There are ways to circumvent this fence. Execution policies are in place only to ensure that users don't accidentally run scripts without awareness.

PowerShell Core on Windows and Windows PowerShell contain this feature. Running PowerShell scripts on Windows is still restricted by default. On PowerShell Core on Linux, execution policies do not work at the moment, and, based on the interactions in the community, it is uncertain whether this feature will ever make it to PowerShell on Linux. Regardless, if you are reading this book, you are more than capable of understanding the perils of scripts from unknown sources.

An execution policy determines what type of scripts can be executed. Here are the six execution policies (excluding Default):

  1. AllSigned
  2. RemoteSigned
  3. Restricted
  4. Unrestricted
  5. Bypass
  6. Undefined

There are three scopes as well:

  1. Process
  2. CurrentUser
  3. LocalMachine

A combination of an execution policy and a scope are what determine the condition that scripts can be loaded under. Microsoft has documented in detail what each of the policies is. In general, AllSigned requires that all of the scripts that run on the computer are signed using a code-signing certificate by a trusted certification authority. If this policy is set, PowerShell will not run unsigned scripts, even if you were the one to create them.

Restricted is the default policy: commands can be run, but not scripts. RemoteSigned allows scripts that have been created on your own computer to run. Scripts that have been downloaded from the internet cannot be run.

Bypass is similar to Unrestricted, however, it is used in specific scenarios, such as when PowerShell forms the basis of a certain application, and the application has its own security implementation.

Unrestricted means that all scripts and commands can run after a simple confirmation. Undefined means that no policy has been defined for a particular scope. Follow the recipe to find the execution policy that is effective on the session, and change it to suit your needs.

Getting ready

This recipe can only be run on Windows. If you're running a pure Linux environment, you cannot work with this recipe. You may run the commands, but you will see the Unrestricted policy set at all levels.

If you have a Windows computer to work with, you can proceed with this recipe, regardless of whether it has PowerShell or Windows PowerShell.

How to do it...

Open a PowerShell window by running pwsh or powershell. The pwsh command calls PowerShell, and powershell calls Windows PowerShell.

Windows PowerShell comes preinstalled on all modern Windows operating systems; PowerShell, on the other hand, has to be installed. Note that all of the current PowerShell cmdlets will run on Windows PowerShell as well:

  1. First, run the Get-Command cmdlet to find out how to work with execution policies:
PS> Get-Command -Noun Execution*
  1. Now, let's get help on running the cmdlet:
PS> Get-Help Get-ExecutionPolicy
  1. We want to know the execution policy set on the machine. Therefore, we will run the following code:
PS> Get-ExecutionPolicy

This shows that the execution policy is currently effective on the current PowerShell session.

  1. To list out the policies set at various scopes, run the following command:
PS> Get-ExecutionPolicy -List

We can see that the policy is only set at the LocalMachine level, and that it is set as RemoteSigned, which is the same as what is reflected in the previous step. The policy at the LocalUser and the Process scopes is Undefined, which made the session pick the execution policy from LocalMachine.

Now, let's set the execution policy for the local machine to be Undefined and see what our session picks up.

  1. For this to work, close the current PowerShell session and open a new session as the administrator.
  2. Next, run the following command:
PS> Get-Help Set-ExecutionPolicy

  1. The help document shows that the value of the ExecutionPolicy parameter is mandatory, and that Undefined is one of the valid values it will accept. We want to set the policy at the LocalMachine scope, and so we will use the following code:
You will need to launch PowerShell (either Core or Windows) with elevated privileges to set the policy at the LocalMachine level.
PS> Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope LocalMachine
  1. Now, list the execution policies at the various scopes:
PS> Get-ExecutionPolicy -List
  1. Now, let's check the currently effective execution policy:
PS> Get-ExecutionPolicy

  1. Finally, let's set the execution policy back to how it was before we began the recipe. You may want to change the policy to suit your needs, based on what authority you have on the computer:
PS> Set-ExecutionPolicy RemoteSigned -Scope LocalMachine

How it works...

Execution policies are nothing but conditions that are set on the system to avoid accidental script runs. They work at different scopes.

There are three scopes in PowerShell, as we have already stated. The LocalSystem scope is at the end of the chain. Right above it is the CurrentUser scope. At the top is the Process scope. The level of precedence is Process > CurrentUser > LocalMachine. Therefore, if any policy other than Undefined is set at the Process scope, the session will use the policy that's currently set on the process. In case it is Undefined, it will look for the policy set on the CurrrentUser scope. If CurrentUser has the policy marked as Undefined as well, the session will apply the policy that was applied at the LocalMachine level. If LocalMachine has Undefined set, the session will pick the Default policy, which is based on what PowerShell has defined as the policy, which may vary based on the version of your operating system. On Windows 2016, for instance, the default policy is RemoteSigned.

The policies set at the CurrentUser and LocalMachine levels are stored in the Windows Registry. The policy set on the Process scope is stored in the ephemeral environment variable, that is, $env:PSExecutionPolicyPreference.

See also