Forem: TeamCloudSkills

The Beginners Guide to Running Docker Containers on AWS

TeamCloudSkills — Sat, 06 Mar 2021 18:50:05 +0000

Learning the basics of AWS and Docker containers?

In this episode, we explain the basics of Docker and how to run containers on AWS.

This a one-hour project focused tutorial from our AWS Certified Solutions Architect training.

AWS Quick Tip: Working with EC2 and IAM Roles

TeamCloudSkills — Sat, 06 Mar 2021 18:40:12 +0000

Allowing your applications to access cloud services on your behalf can sometimes be tricky. In AWS, you can take advantage of IAM roles to make this a lot easier.

Working with IAM roles and delegating service access to applications is a core concept when it comes to dealing with AWS.

In this AWS Quick Tip, CloudSkills Author Michael Levan explains how this works.

AKS Virtual Nodes with Chad Crowell

TeamCloudSkills — Sat, 06 Mar 2021 18:37:41 +0000

Working with Azure Kubernetes Service (AKS)?

If you're in Azure and planning to work with Kubernetes, definitely check out how to SCALE virtual nodes and get your billing under control.

This 13 minute YouTube video is by CloudSkills Author Chad Crowell.

Packer and Terraform with Immutable Infrastructure

TeamCloudSkills — Tue, 02 Feb 2021 15:00:32 +0000

Terraform is red hot right now, and you probably know that it's an open-source Infrastructure as Code (IaC) solution.

OK, but what is Packer?

Well, Packer is an open source tool for creating identical machine images for multiple platforms from a single source configuration. It's lightweight, runs on every major operating system, and is highly performant, creating machine images for multiple platforms in parallel.

In this CloudSkills Community Call replay, Luke Orellana shows you how to get started with Packer, Terraform, and Immutable Infrastructure.

Resources from this episode:

HashiCorp Learn:
https://learn.hashicorp.com/terraform

Introduction to Packer
https://www.packer.io/intro

Learning Application Security with Tanya Janca

TeamCloudSkills — Tue, 02 Feb 2021 12:10:54 +0000

Tanya Janca, who was on the podcast last year, is back! Since the last time we talked, she’s been very busy founding her own company, We Hack Purple. Tanya’s an expert on App Security, and through her company, she’s sharing those skills with online on-demand courses.

In this episode, we talk about…

Tanya’s new community centered around her online academy, which has been a positive and kind space for discussing related topics.
Why, if you’re a software developer, you should learn about app security and have a strategy to talk to management to get what you want and legitimize your job.
Tanya’s book and how she teaches each lesson within it several different ways to make it accessible for various learning styles.
Tanya’s current free mini-course offering about scaling your security program and security team.
The best career advice Tanya has ever gotten.
The importance of mentors in everyone’s careers and why it’s very important to build a community.

Resources from this episode:

Follow Tanya on Twitter
Check out the We Hack Purple Academy
Read Tanya's new book: Alice and Bob Learn Application Security
Join the We Hack Purple Newsletter

Azure Automation: Managing Runbook Authentication and Modules

TeamCloudSkills — Tue, 02 Feb 2021 11:16:28 +0000

In my previous post, we took a look at creating your first Azure Automation PowerShell runbook. We set up the Azure Automation account, authored a PowerShell runbook, and incorporated parameters and variable assets. The next step is to understand how we can access and manage Azure resources from our runbooks.

In this guide, you will learn how Azure Automation can authenticate and access Azure resources. We will also take a look at importing PowerShell modules to add cmdlets to our runbooks. When you're finished, you'll have the skills to elevate your runbooks to the next level.

Prerequisites

Before you begin this guide, you'll need the following:

Azure tenant and subscription
Administrator account with sufficient permissions on a subscription, such as Owner, or a role containing Microsoft.Automation resource authorization
PowerShell knowledge

Azure Automation Run As Account

When I created the Azure Automation account in the first article, I enabled the option to create an Azure Run As account. By enabling this option, Azure will automatically create an Azure AD application. You can use this application identity to authenticate to an Azure subscription to access and manage resources. During the Run As account creation, Azure performs several other functions such as:

Adding a self-signed certificate to the application account.
Creating a service principal identity for the application.
Assigning the Contributor role for the account in the current subscription.
Creating Automation connection assets named AzureRunAsCertificate and AzureRunAsConnection.

If you want to view more information about the Run As account, from the Automation Account resource page, navigate to Account Settings > Run as accounts.

You can view the account's properties in the portal, including the certificate thumbprint, the Azure AD application information, service principal ID, role assignments, and runbooks utilizing the account.

At the top of the properties page, note an action named Renew Certificate. The account's certificate is only valid for one year, so be sure to renew before expiration to keep your runbooks from failing.

Along with the Run As account, Azure will create two connection assets: AzureRunAsCertificate and AzureRunAsConnection. The certificate asset authenticates to Azure so the runbook can manage Azure Resource Manager resources. The connection asset contains the application ID, tenant ID, subscription ID, and certificate thumbprint. Basically, everything you need to connect to Azure to start managing resources! In an upcoming example, I'll use this connection to connect to Azure and to retrieve some resources.

Automation Account Modules

Before I create a new runbook to manage my Azure resources, I need to make sure I have the right PowerShell commands available. When you create a new Automation Account, Azure will automatically import some PowerShell modules for you, such as AzureRM.Automation, AzureRM.Computer, and AzureRM.Resources. However, these modules are a part of the older AzureRM PowerShell module, which Microsoft is no longer developing. Microsoft has replaced this module with the newer Az PowerShell module.

Luckily, I'm not stuck using the older modules in my PowerShell runbooks. I can import the new Az modules into the Automation Account for use with my PowerShell code. From the Automation Account, navigate to Shared Resources > Modules gallery. The first module I need to import is the Az.Accounts module so I can use the Connect-AzAccount cmdlet in my runbook. Search for "Az.Accounts", then select the resulting module.

From the module page, I can search the module for the cmdlets and functions to verify it has what I need. From here, I can select the Import action at the top. Once the import is successful, I need to navigate the Modules gallery and perform the same steps for the Az.Resources module so I can use the Get-AzResourceGroup in my runbook.

The imports can take a few minutes, but you can verify the status by navigating back to Shared Resources > Modules. In this list of modules, verify the module import progress in the Status column. From this Modules page, also note there are options to import a custom module. Select the + Add a module and choose a .zip file that contains the module code. Note that the module code's file name must match the file name of the zip file. Importing custom written module is a fantastic feature of Azure Automation that allows you to write a runbook to fit any scenario.

Connect to Azure from PowerShell Runbook

Back in the Automation Account, I will create a new runbook that will connect to Azure and retrieve my resource groups. In the Automation Account, navigate to Process Automation > Runbooks, then select + Create a runbook. From here, input a name for the runbook, select the PowerShell runbook type, then select Create.

In the Edit PowerShell Runbook window, I need to write code that will retrieve the information stored in AzureRunAsConnection. For this, I use the Get-AutomationConnection cmdlet and specify the name of the Run As connection. If I store the connection information to a variable, I can reference the tenant ID, application ID, and certificate thumbprint in the Connect-AzAccount cmdlet to authenticate to my Azure tenant.

$connection = Get-AutomationConnection -Name AzureRunAsConnection

Connect-AzAccount -ServicePrincipal `
    -Tenant $connection.TenantID `
    -ApplicationId $connection.ApplicationID `
    -CertificateThumbprint $connection.CertificateThumbprint

If you do not remember the cmdlet to retrieve the Run As connection asset, remember you can expand Assets on the left to view saved connections and other assets. Selecting Add to canvas will insert the necessary PowerShell code.

Once the runbook connects, I can now use other Az cmdlets to work with Azure resources. Since I imported the Az.Resources module, I can retrieve all my resource groups using the Get-AzResourceGroup cmdlet.

From here, I will save the runbook code, publish, and then execute it. When I view the runbook job status, the Output tab will show the runbook successfully authenticating to Azure. It will then start displaying my resource groups.

Retrieving resource groups is only the beginning of what is possible. Imagine what other tasks you could automate within a runbook, such as taking snapshots of virtual machine disks, turning off virtual machines, or automatically resizing resources based on a schedule.

Managing Runbook Authentication without Run As Accounts

You might be asking, "If I don't create a Run As account with the Automation Account, how can I authenticate to Azure?". There are a few options for managing authentication in this scenario, which I outline in the following sections. Remember, if you choose not to use the built-in Run As account, you will need to ensure that whichever account used has permissions to the Azure resources the script is trying to access. The built-in Run As account accomplishes this by being a Contributor at the subscription level, but you may want to apply more granular permissions.

Create the Run As Account

I can still enable the Run As account after the Automation Account has been created. In the account, navigate to Account Settings > Run as accounts. Previously in this screen, we viewed the existing account, but I can also create one if it doesn't exist already. No additional inputs or settings are needed to set up the account.

Create a Service Principal

Applications use a service principal to access resources secured by Azure AD. The service principle represents the application inside the tenant, and you can assign it permissions to resources (just like a user account).

To create a service principal, navigate to Azure Active Directory in the Azure portal. In the Manage section, select App registrations. Select + New registration, then input the application's name, support account type (for now, leave at the default), and redirect URI (this can be blank).

After you create the app registration, on the Overview page, take note of the application ID and tenant ID. You will need this information later to create a new connection or credentials asset (see following sections). In the Manage section, you can navigate to Certificates & secrets to upload a certificate or generate a secret (essentially a password for the account). You can then use either of these to authenticate out to Azure.

Create a New Connection Asset

You can create your own connection asset that includes an ApplicationId, TenantId, Certificate Thumbprint, and Subscription Id. If you created a service principal in the previous section, you could use it for this purpose.

Create a connection asset in the Automation Account by navigating to Shared Resources > Connections, then select + Add a connection. Give a name to the connection asset, select AzureServicePrincipal as the type, and enter the required information from the service principal. Once the connection is created, I can use it just like the AzureRunAsConnection asset in my PowerShell code from earlier.

Create a Credentials Asset

Finally, you can store security credentials as a shared resource. The credentials asset includes a username and password, and you can use these on cmdlets that accept a PSCredential object. In the Automation Account, navigate to Shared Resources > Credentials and select + Add a credential. Name the credential and enter the username and password.

Once you create the asset, you can retrieve the credentials using Get-AutomationPSCredential and store it in a variable. You then pass the credentials to the Connect-AzAccount cmdlet, like so:

$creds = Get-AutomationPSCredential -Name '{CredentialAssetName}'

Connect-AzAccount -Credentials $creds

Don't forget, you can use the Asset explorer on the left to input the correct code and asset name into your script.

Conclusion

In this post, you learned how to configure authentication so your runbooks can access Azure resources. Being able to authenticate to Azure without storing usernames and passwords in the runbook code is a security best practice. Now that you can connect to Azure, start thinking about what tasks you can automate using runbooks. You will need to be sure to import any modules required by your code.

Check back soon for my next post on Azure Automation where I will show how to configure a hybrid worker so you can execute a runbook anywhere.

Jeff Brown is a Systems Engineer and Cloud Administrator with over a decade of experience in server and application administration. In his career, he has managed a wide range of technologies including Windows Server, Exchange Server, Skype for Business, Azure, and Microsoft 365. Jeff enjoys writing about technology topics and creating content for the community. You can find more of his content over at jeffbrown.tech.

Azure Automation: Creating a PowerShell Runbook

TeamCloudSkills — Tue, 02 Feb 2021 11:08:50 +0000

Azure Automation is a cloud-based automation and configuration service that you can use for process automation through runbooks. You can author runbooks using a graphical interface or in PowerShell or Python programming languages. Think of these runbooks as replacing scripts you have scheduled to run on a server.

In this guide, you will set up an Azure Automation Account and deploy your first PowerShell runbook. When you're finished, you will have the necessary skills to get started deploying runbooks in your Azure tenant.

Prerequisites

Before you begin this guide, you'll need the following:

Azure tenant and subscription
Administrator account with sufficient permissions on a subscription, such as Owner or Contributor
PowerShell knowledge

Create an Azure Automation Account

Before creating your first runbook, you need to create an Azure Automation Account. This account is responsible for executing runbooks and authenticating to Azure resources required by the runbook. The account groups together Automation resources, runbooks, and configuration settings. You can create multiple accounts to separate their functionality, such as accounts for development and production.

To get started creating your first Azure Automation Account, log into the Azure portal at https://portal.azure.com. In the Search bar, enter Azure Automation, and select Automation Accounts from the results.

Here on the Automation Accounts resource page, you can view and manage any existing Automation Accounts. Click on + Add to create your Automation Account. In the Add Automation Account page, you need to define some information for your account:

Name: Enter a descriptive name for the account. Following Microsoft recommendations, I will name mine based on the resource type, its purpose, environment, Azure region, and instance. For example, aa-cloudskills-prod-westus-001.
Subscription: Select a valid Azure subscription.
Resource Group: Select an existing resource group or create a new one. For this demo, I am creating a new resource group named azacct-rg.
Location: Select a location to host the Automation Account.
Create Azure Run As account: Enabling this option will automatically create an Azure Run As account for authenticating to other Azure resources. For now, configure this to Yes.

Once you have entered the account information, click on Create. Once Azure creates the account successfully, select the account in the Automation Account list (this may require a refresh before it appears).

Create a PowerShell Runbook

Now that the Automation Account has been created, you can author the runbook that hosts your PowerShell code. Using the left menu in the Automation Account resource, scroll down to Process Automation and select Runbooks. Here you will see some examples of each type of runbook you can create: Graphical, Python, and PowerShell. You can view each of these runbooks to learn how to perform different actions in runbooks, such as using variables or connecting to Azure resources. You can also import a runbook or browse the PowerShell Gallery and Azure Automation GitHub organization for resources created by Microsoft and the community.

Let's get started creating a runbook by selecting Create a runbook. In the form, enter a runbook name, select the runbook type, and enter a description. This demo is using a PowerShell runbook type. Once you have entered all the runbook information, select the Create button.

After Azure creates the runbook, it should redirect you to the Edit PowerShell Runbook page. This page is where you can enter in the PowerShell code that the Automation Account executes. The menu actions include the ability to save the runbook, publish a new version of the runbook, revert to a previously published version, or run a test of the runbook. On the left, you can view the modules and cmdlets available to use in the runbook, import references to other runbooks, or view assets that you can use in the script, such as variables or certificates for authentication.

For this runbook, I am keeping the code simple and displaying the phrase "Hello, Azure Runbooks!" to the console.

"Hello, Azure Runbooks!"

Once you have entered the code, select the Save button, then the Publish button. You will receive a warning that publishing the runbook will override the existing published version. Select Yes to this prompt. Once the runbook is successfully published, the Azure portal will redirect to the Overview page.

Execute the Runbook

With the runbook created and published, you can now execute the runbook and view the output. From the Overview page, select the Start icon. It will prompt you to make sure you want to start the runbook, go ahead and select Yes. Once Azure begins executing the runbook, the portal will redirect to the overview page for this runbook job instance. Here, you can view the instance ID, the status, and the input and output streams of the runbook. From here, select the Output tab to view the "Hello, Azure Runbooks!" message to the console.

Add Warning and Error Output

In the above example, the PowerShell runbook output the string "Hello, Azure Runbooks!". You can also use the cmdlets Write-Warning and Write-Error to output warning and error messages to the console logs.

Back on the runbook Overview page, select the Edit icon at the top to go back to the Edit PowerShell Runbook page with the existing code. In the code editor, add the following lines of code:

Write-Warning -Message "This is the warning message."

Write-Error -Message "This is the error message."

Save and publish this version of the runbook. Back in the Overview page for the runbook, select the Start icon to execute the runbook again, just as you did previously. In the job results window, select the Errors and Warnings tabs to view the custom messages outputted from the script. You can also select All Logs to view all output from the script in one place.

Using the appropriate PowerShell cmdlets, you can create a runbook that shows regular, warning, and error messages. Customizing this output can quickly ascertain if the script has any issues by correctly displaying warnings and errors.

Enhance Runbook Execution with Parameters

PowerShell parameters enable passing information to a script to use during execution. Parameters allow PowerShell scripts to be more dynamic instead of setting static variables. Azure Automation PowerShell runbooks can also use parameters when you define them in the script code. Let's examine this functionality now.

Follow the instructions from earlier in this post to edit the runbook code. In the code editor, add a parameter that will accept a name to display in the greeting message. Since this parameter is not mandatory, I'm defining the parameter with a default value of "CloudSkills." Here is the new runbook code.

param (
    [Parameter()]
    [string]
    $Name = "CloudSkills"
)

"Hello, $Name"

After saving and publishing the runbook, execute the runbook just as you have done previously. However, this time Azure will display a Start Runbook window to allow you to input a value for the Name parameter. It also indicates that "CloudSkills" will be used as the default if you don't enter another value. Enter your name and select OK.

In the job results window, the Input tab will show the value of the Name parameter passed to the runbook, and the Output tab will show the output message using the value of the parameter.

Creating a Variable Asset

While you can define variables within the runbook code, you can also define variables within the Automation Account to be used by multiple runbooks. Back in the Automation Account, navigate to Shared Resources > Variables. From here, select Add a variable. In the New Variable window, enter a variable name, description, data type, value, and encryption type. Once completed, select Create.

With the variable create, you can now reference it in a runbook. Navigate back to the runbook and edit the code. Inside the script, you can retrieve the variable's value by using the Get-AutomationVariable with the variable name and storing it into a script-level variable.

$congratsMessage = Get-AutomationVariable -Name 'congratsMessage'

You can now use the defined variable as needed in the script. Suppose you don't remember the name of the variable asset you defined in the Automation Account. In that case, you can view variable assets under Assets and use the context menu to auto-generate the PowerShell command.

Save, publish, and then execute the runbook to verify the variable output in the job results window.

Conclusion

In this post, you learned how to create an Azure Automation Account to host your first PowerShell runbook. You saw how to view the runbook output and use Write-Warning and Write-Error to customize the output. Finally, you extended the functionality of your runbook with parameters and variable assets.

Check back soon for my next post on Azure Automation where I will show how to configure authentication to access and manage Azure resources.

Windows Virtual Desktop with Travis Roberts

TeamCloudSkills — Tue, 02 Feb 2021 10:55:17 +0000

In this episode we're catching up with Travis Roberts to chat about all things Windows Virtual Desktop, Azure, and a lot more.

In part due to the COVID-19 Pandemic, 2020 saw the use of Windows Virtual Desktop soar. Many companies are in the process of switching their networks over to the Cloud. Mike’s guest today is Travis Roberts, the Senior Networking Systems Administrator at RBA Consulting. Travis has a background of working in corporate IT for over 20 years, but he made a switch when he realized he wanted to focus less on management and more on consulting. He has lots of experience with Windows Virtual Desktop (and more) and creates content online to help others learn how to better utilize this technology.

In this episode, we talk about…

Travis’s background, how he got into consulting, and what the transition was like coming to that from corporate jobs.
How Azure has been ramping up and is currently neck and neck with AWS.
Why, at this point, most Systems Administrators are essentially Cloud Developers, as well.
How you have to think a bit differently when using ARM templates and PowerShell.
Why moving to the Cloud can save a business a lot of overhead expenses.
The mindset shift involved in maintaining a server rack with manual switches and buttons, versus working within Azure.
Why setting up a virtual network within Windows Virtual Desktop is so much faster than the traditional means.
Why you need to continuously learn given the way technology is shifting now -and how if you learn it sooner, you can help others as they shift to the Cloud during the next decade.
How building a brand can help you, and if you’re interested, you should start writing a blog or making Youtube videos.
The importance of Source Control and how Travis has been using Github.
The switch from using JSON to using HCL.
How Travis has been seeing that he’s been needing to learn more about Continuous Integration.

Resources from this episode:

Travis on Twitter
Travis onYouTube
Travis on LinkedIn
Udemy Course Discount: Zero to Hero with Windows Virtual Desktop

AWS for Azure Pros: The Ultimate AWS to Azure Service Comparison

TeamCloudSkills — Tue, 02 Feb 2021 10:52:28 +0000

Already know Azure but need to learn AWS? In this CloudSkills Community Call replay, MSFT MVP Mike Pfeiffer delivers a one-hour training that maps what you already know in Azure to comparable services in AWS.

Note: Throughout the video Mike mentions an upcoming AWS class at CloudSkills.io; it ended up becoming the Cloud Native DevOps Bootcamp:

https://cloudskills.io/cloudnative