Forem: Arkadiusz Bolewski

Provisioning infrastructure on AWS using Azure DevOps

Arkadiusz Bolewski — Thu, 02 Sep 2021 23:54:42 +0000

Introduction

This blog post will cover infrastructure deployment on AWS using CloudFormation in combination with Azure DevOps.

You might ask, why? There are brilliant Code family tools/solutions/services available on AWS. Moreover, if not the toolset that is already available on the best cloud ;) you could pick up something else.

The answer is pretty simple - I was forced to using it :). I jumped into the multi-cloud project where the team was already heavily using Azure DevOps, so there was no chance to introduce another CI/CD toolset - I had to align. In this blog post, I want to share my experience and write this 'quick start' guide on how to set up the environment to start deployment of your AWS infrastructure using CloudFormation templates. Maybe you are in the same position as I was.

Azure DevOps project configuration

If you already have the Azure DevOps project in place, you can skip this part, but if not you please log into the tool and create a new project just like in the picture below. Put a project name and meaningful description. You can also set up additional options like the visibility of your project (public/private) and version control.

After initial project creation, you should create a code repository for your project:

The next step is to create and configure the pipeline:

You have to decide where your code will be stored. In our case, it will be the "Azure Repos Git" option:

Pick up your code repository created in the previous step:

On the next screen, you can decide to create a new pipeline YAML file or select an existing one from your code repository. In this example, I'm choosing the first option:

On the last screen, review your newly created pipeline YAML file and hit the save&run button:

Important: you might end up with a similar error message: No hosted parallelism has been purchased or granted. To request a free parallelism grant, please fill out the following form https://aka.ms/azpipelines-parallelism-request

It is applicable only for new accounts. You have to visit the link from the error and submit the request form where you have to provide your name, email address, and your Azure DevOps Organization name:

The reason behind this is as follows:

Over the past few months, the situation has gotten substantially worse, with a high percentage of new public projects in Azure DevOps being used for crypto mining and other activities we classify as abusive. In addition to taking an increasing amount of energy from the team, this puts our hosted agent pools under stress and degrades the experience of all our users – both open-source and paid.

After successful pipeline creation you should see a similar view:

Installation of AWS Toolkit for Azure DevOps extension

At the current stage, our project configuration doesn't allow us to work with AWS services. To make this work, we need to install AWS Toolkit for Azure DevOps extension. This extension will add tasks so we can work with AWS services like:

Amazon S3
AWS Elastic Beanstalk
AWS Elastic Container Registry
AWS CodeDeploy
AWS Lambda
AWS CloudFormation
Amazon Simple Queue Service
Amazon Simple Notification Service
AWS Systems Manager
AWS Secrets Manager
AWS CLI

In this chapter, I would like to focus only on necessary steps to make this work, but if you would like to know more about this toolkit, please visit official AWS docs

To install the Toolkit, you have to visit the website https://marketplace.visualstudio.com/items?itemName=AmazonWebServices.aws-vsts-tools
and hit the "Get it free" button:

On the next screen, choose your Organization and click the "Install" button:

In your pipeline edit view on the right-hand side, you have the 'Tasks' panel. Try to filter it by typing 'AWS'. You should see now additional building blocks related to AWS services that you can use in your pipeline configuration.

Set up Service Connection to AWS on Azure DevOps

For now, we have DevOps Organization, code repository and some starter pipeline. We still need a service connection between Azure DevOps and our AWS account, where we will deploy our infrastructure. To do this, we can create an IAM user with programmatic access enabled. Please note that the service connection expects long-lived AWS credentials consisting of an access-key and secret-key pair. You can also define Assume Role credentials to scope down the access.

Navigate to the "Project settings" located on the lower-left side of the screen, next to "Pipelines->Service connections", and click the "Create service connection". A new panel on the right-hand side should pop up. Chose "AWS" and click "Next":

On the next screen, provide connection details. Minimum is Access Key ID and Secret Access Key of your IAM user, but as mentioned earlier, you could use Assume Role credentials as well. When done, click "Save":

Pipeline file configuration

Now it's time to edit the azure-pipelines.yml file for our CloudFormation deployments. You could use the web interface and tasks added by the AWS Toolkit extension like building blocks or edit it with the code editor of your choice (like VS Code) if you know the syntax.

I will create two tasks:

Upload CloudFormation template to the S3 bucket
CloudFormation Update/Create stack to deploy the infrastructure

The code for the first part:



trigger:
- master

pool:
  vmImage: ubuntu-latest

steps:
- task: S3Upload@1
  inputs:
    awsCredentials: 'AWS'
    regionName: 'eu-west-1'
    bucketName: 'bolewski-cfn'
    sourceFolder: 'source'
    globExpressions: '**'
    targetFolder: 'AWSCommunityBuilders'
    createBucket: true

General fields:
trigger specifies which branches cause a build to run - in our case "master"
pool agent pool to use - I'm using the default one "ubuntu-latest"
steps here is the section where our tasks definitions are located

For the S3 Upload task:
awsCredentials credentials that we've created for service connection
regionName region of our S3 bucket where we want to upload our CloduFormation template
bucketName our target S3 bucket name
sourceFolder from which folder in our code repository we want to move files
globExpressions basically just filename patterns
targetFolder prefix (folder) on our S3 bucket where we want to upload files
createBucket if the bucket doesn't exist shall we create it or not

There are of course more options, but I highly encourage you to explore them on your own.

The code for the second task:



- task: CloudFormationCreateOrUpdateStack@1
  inputs:
    awsCredentials: 'AWS'
    regionName: 'eu-west-1'
    stackName: 'AzureDevOpsDemo'
    templateSource: 's3'
    s3BucketName: 'bolewski-cfn'
    s3ObjectKey: 'AWSCommunityBuilders/network.yml'

awsCredentials credentials that we've created for service connection
regionName region where we want to deploy our CloudFormation template
stackName CloudFormation stack name
templateSource source location for our template, in this case, it's the S3 bucket
s3BucketName S3 bucket name
s3ObjectKey location of our template in the S3 bucket

After some tweaks, the final code looks like below:



trigger:
- master

pool:
  vmImage: ubuntu-latest

variables:
  credentials: 'AWS'
  region: 'eu-west-1'
  bucket: 'bolewski-cfn'

steps:
- task: S3Upload@1
  inputs:
    awsCredentials: $(credentials)
    regionName: $(region)
    bucketName: $(bucket)
    sourceFolder: 'source'
    globExpressions: '**'
    targetFolder: 'AWSCommunityBuilders'
    createBucket: true

- task: CloudFormationCreateOrUpdateStack@1
  inputs:
    awsCredentials: $(credentials)
    regionName: $(region)
    stackName: 'AzureDevOpsDemo'
    templateSource: 's3'
    s3BucketName: $(bucket)
    s3ObjectKey: 'AWSCommunityBuilders/network.yml'

And the results:

Summary

As you can see, deployment of the CloudFormation templates is possible even with tools provided by the competitor cloud provider. If you are stuck with the tools you don't like, don't panic, there is always a solution ;). I highly encourage you to play with it on your own, because nothing can replace the hands-on experience. This was a very simple example build from scratch, but I hope it is useful for you.

If you have any feedback or question, please put a comment or drop me a message.

How to configure cross-account AWS Backup

Arkadiusz Bolewski — Wed, 31 Mar 2021 00:17:06 +0000

Introduction

This blog post will describe how to set up cross-account AWS Backup. Let's imagine situation where you need to store your cloud backups in one central location, like another AWS account? Maybe because of some compliance or other organizational/contractual reasons. This is where cross-account AWS Backup jump on the stage :)

Pre-requisites

First of all you must have at least two accounts that belong to the same organization in the AWS Organizations service. One for backup source and second for desired target location.

Next you need to enable cross-account backup functionality. By default it's disabled.

Creating Customer Managed Key for backup encryption

For all services except Amazon EFS, cross-account backup only supports customer managed CMKs. It does not support backup vaults that are encrypted using AWS managed CMKs, including default vaults, because AWS managed CMKs are not intended to be shared between accounts that's why we need to create our own key.

Set up alias, key type and key administrators. For key users we need to pickup IAM Role used by AWS Backup. Last thing is to allow usage of our key with Source account.

Create Service Linked Role for AWS Backup (optional)

You might encounter similar error:
The provided role arn:aws:iam::1234567890:role/aws-service-role/backup.amazonaws.com/AWSServiceRoleForBackup cannot be assumed by AWS Backup.

This means you are missing service linked role. AWS Backup uses the service linked role named AWSServiceRoleForBackup. This role provides AWS Backup permission to create backups on your behalf across AWS services. If you have used AWS Backup in the past, most probably you already have it but if don't we can create it running below command:



aws iam create-service-linked-role --aws-service-name backup.amazonaws.com

We can use new cool feature to do this - AWS CloudShell

Create Backup Vaults

Next step is to create Backups Vaults in source and destination accounts where we will copy our backups. Backup vault is a container where you can organize your backups in.

Note:You must use vaults other than your default vaults to perform cross-account backup.

Another task to do with Backup Vaults is to set up an access policy. We want to allow access to our Vault from AWS Organizations.

Policy JSON should look like this:

We need to switch to our source account and repeat these steps with creating KMS key and Backup Vault. We need a place to store our encrypted backups before we copy them to the target account.

Configure Backup Plans

Next step is to configure Backup Plans. Backup plan is a policy (set of rules) that defines when and how you want to back up your AWS resources. You can assign resources to backup plans and AWS Backup automatically backs up and retains backups for those resources according to the backup plan. You can create multiple backup plans if you have workloads with different backup demands.

You can pick up from pre-defined templates or create your own plan:

Configure backup rule by defining schedule, backup window, lifecycle policy, target vault:

And what's most interesting, we can define here our copy to destination with copy to another account's vault switch:

It's worth to mention that we can have multiple copies.

When we have defined our backup plan and rules now it's time to assign resources that are going to be backed up:

We can assign resources by specific Tags which is very useful and by Resource ID:

Supported resource types

Unfortunately not all resource types support cross-account and cross-region backup at the same time. One of the example is RDS. You may encounter similar error:

I couldn't find any confirmation in official docs that this setup is not supported. I hope AWS team responsible for AWS Backup will work on it and in the near future all resource types will support cross-account and cross-region backup ;-)

I've worked with below resource types without any issues:

EC2
EBS
EFS (non-default/automatic EFS backup)

Verify your backup and copy jobs

Final thing is to review if your backups are working as planned. Verify backup jobs and copy jobs in your dashboard and troubleshoot any potential misconfigurations/issues:

Next steps

There is always space for improvement :). If you would like to experiment more with AWS Backup you might want to try centralized management and creating Backup Policies across your AWS Organization.

If you have any additional questions or spot any error please feel free to contact me!

P.S. Always test your backups.

AWS SSO with Azure Active Directory

Arkadiusz Bolewski — Tue, 03 Nov 2020 02:07:43 +0000

Introduction

Recently in one of my project we had to setup AWS SSO with Azure AD as our primary identity provider. There are couple good reads available on the web like this one from 2019 but things are changing dynamically, so they are quickly becoming outdated. This is the reason why I decided to write my own detailed guide!

Pre-requisites

Before we start we need two pieces in place which are not described in this guide:

Azure Active Directory
AWS SSO

Add Enterprise Application on Azure

Go to your Azure subscription. Navigate to Azure Active Directory, next in the menu on the left hand side click Enterprise applications.
Click New application.
Click Create your own application, add meaningful name, check Integrate any other application you don't find in the gallery and click Create when ready
We have created our Enterprise application, now let's go back to our AWS account.

Configure AWS SSO with external identity provider

Log into your AWS account, navigate to AWS SSO service and click Choose your identity source.
Under Identity source settings, click Change.
You will be redirected to the new page with additional settings. On that page choose External identity provider. Scroll down to Service provider metadata section and click Download metadata file. We are going to upload this file to our Azure application. Leave this page open, we will need it later.

Now let's go back to our Enterprise application on Azure.

Configure Enterprise application

Navigate to the previously created Enterprise application and click Setup single sign on.
On next page choose SAML.
Upload metadata file downloaded from AWS SSO configuration and click Save on next dialog.
Now you should see the link to download Federation Metadata XML file which we will upload to AWS SSO as IdP SAML metadata (you didn't close it, right? (: ). If you can't see the link, please refresh the page.

Finish AWS SSO configuration

Go back to the AWS SSO configuration page and upload Federation Metadata XML file from Azure as IdP SAML metadata. Click Review when ready.
Carefully read warning message. When ready write ACCEPT in the text box and click Change identity source button.

Congrats! You have configured AWS SSO with AzureAD as your main identity provider. Now let's configure automatic provisioning of your users and groups.

Enable automatic provisioning

Navigate to AWS SSO console, click Settings and then click Enable identity synchronization link. New dialog will open with your SCIM endpoint address and Access token. Copy these values, you will need them later.
Let's go back to Azure portal. Navigate to your Enterprise application and click Provisioning on the left hand side menu.
Set Provisioning mode to Automatic. Provide Tenant URL (SCIM endpoint) and Secret Token (Access token). You can click Test Connection button to verify if Azure can establish connection with SCIM endpoint.
Mappings section will be available as soon as you hit Save button with your SCIM endpoint and Access token fields populated. It's good idea to set up Notification Email field so you will get notified if you synchronization fails. You can set Provisioning Status to On.

Pro tip: AzureAD allows you to create user without First Name and Last Name defined but AWS SSO won't like it. Please pay attention to any synchronization errors.
Last but not least is to define our users and groups that we want to be synchronized from AzureAD to AWS SSO. To do this navigate to your Enterprise application, click Users and Groups in the left hand side menu and then Add user button.
You can now login to your AWS accounts using AWS SSO User portal URL or myapplications.microsoft.com webpage.

Closing remarks

Hope you will find this guide useful.

I would like to thank my team mate Guru for help with the screenshots! ;)