This post is what I wish I read before recently working on replacing the SSH access to the bastion in my terraform project with SSM & EC2 Instance Connect.

Motivation

I'm a bit paranoid about security. Not as paranoid as Amelia who's a cybersecurity consultant but paranoid nonetheless.

I didn't always care about security until I got burnt.

7 years ago, while working for an early-stage startup, I woke up one day to find an email from Digital Ocean about a compromised server being shut down by their team.

An attacker had identified an insecure port and gained access to the server. They had integrated it with a botnet, connecting it to a C&C server.

I was new to managing servers then, DigitalOcean didn't have their firewall feature and I didn't even know about firewalls anyway.

I was determined to protect our servers from future attacks so I spent the next few days learning about security, IP-tables, firewalls, and general server hardening.

I've come a long way from my self-taught server hardening crash course but I still have a strong drive for security and that's what has driven this exercise.

My use case

I had a terraform configuration with:

• An ECS cluster in a private subnet behind an ALB.
• A Postgres RDS instance in a private subnet.
• A bastion in a public subnet.

With this configuration, I would connect to the database, and EC2 instances using SSH tunneling via the bastion.

The networking module

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 2.69.0"

  name = "staff-advocacy-vpc"
  cidr = var.vpc_cidr
  azs  = var.availability_zones

  # ALB & Bastion
  public_subnets = var.public_subnets_cidr

  # ECS CLUSTER
  private_subnets = var.private_subnets_cidr

  # RDS CLUSTER
  database_subnets = var.database_subnets_cidr

  # DNS
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Terraform   = "true"
    Environment = var.environment
  }
}

The database module

locals {
  create_test_resources = true
}

module "db" {
  source  = "terraform-aws-modules/rds/aws"
  version = "2.20.0"

  vpc_security_group_ids = [module.postgres_security_group.this_security_group_id]
  create_db_subnet_group = false
  db_subnet_group_name   = local.create_test_resources ? var.subnet_group_name : ""

  username       = var.database_username
  password       = var.database_password
  port           = var.database_port
  identifier     = var.identifier
  name           = var.database_name
  engine         = "postgres"
  engine_version = var.database_engine_version

  create_db_option_group    = false
  create_db_parameter_group = false

  allocated_storage  = db_storage
  instance_class     = var.db_instance_class
  maintenance_window = var.db_maintenance_window
  backup_window      = var.db_backup_window

  tags = {
    Terraform   = "true"
    Environment = var.environment
  }
}

module "postgres_security_group" {
  source  = "terraform-aws-modules/security-group/aws//modules/postgresql"
  version = "~> 3.0"

  name   = "${var.identifier}-sg"
  vpc_id = var.vpc_id
  
  # using computed_* here to get around count issues.
  ingress_cidr_blocks = var.vpc_cidr_block
  computed_ingress_cidr_blocks = var.vpc_cidr_block
  number_of_computed_ingress_cidr_blocks = 1

  ingress_rules       = ["postgresql-tcp"]

  egress_cidr_blocks = ["0.0.0.0/0"]
  egress_rules       = ["http-80-tcp", "https-443-tcp"]

  tags = {
    Terraform   = "true"
    Name = "${var.environment}-rds-sg"
    Environment = var.environment
  }
}

The bastion module

module "bastion" {
  source  = "terraform-aws-modules/ec2-instance/aws"
  version = "2.16.0"

  ami                         = "ami-0e2e14798f7a300a1"
  name                        = var.name
  associate_public_ip_address = true
  instance_type               = "t2.small"
  vpc_security_group_ids      = [module.bastion_security_group.this_security_group_id]
  subnet_ids                  = var.vpc_public_subnets
  key_name                    = var.bastion_key_name
}

module "bastion_security_group" {
  source  = "terraform-aws-modules/security-group/aws"
  version = "3.1.0"

  name   = "${var.name}-sg"
  vpc_id = var.vpc_id

  ingress_cidr_blocks = ["0.0.0.0/0"]
  ingress_rules       = ["ssh-tcp"]

  egress_cidr_blocks = ["0.0.0.0/0"]
  egress_rules       = ["postgresql-tcp", "http-80-tcp", "https-443-tcp"]
}

Fargate cluster

The full cluster module includes a lot more than a cluster, and alb resource definition but all of this is irrelevant here.

module "ecs_cluster" {
  source = "terraform-aws-modules/ecs/aws"

  name               = "${var.name}-${var.environment}"
  container_insights = true

  capacity_providers = ["FARGATE", "FARGATE_SPOT"]

  default_capacity_provider_strategy = [{
    capacity_provider = "FARGATE"
    weight            = "1"
  }]

  tags = {
    Environment = var.environment
  }
}

resource "aws_lb" "main" {
  name               = "${var.name}-alb-${var.environment}"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = var.vpc_public_subnets

  enable_deletion_protection = false

  tags = {
    Name        = "${var.name}-alb-${var.environment}"
    Environment = var.environment
  }
}

resource "aws_lb" "main" {
  name               = "${var.name}-alb-${var.environment}"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = var.vpc_public_subnets

  enable_deletion_protection = false

  tags = {
    Name        = "${var.name}-alb-${var.environment}"
    Environment = var.environment
  }
}

resource "aws_alb_target_group" "main" {
  name        = "${var.name}-tg-${var.environment}"
  port        = 80
  protocol    = "HTTP"
  vpc_id      = var.vpc_id
  target_type = "ip"

  health_check {
    healthy_threshold   = "3"
    interval            = "30"
    protocol            = "HTTP"
    matcher             = "200"
    timeout             = "3"
    path                = var.health_check_path
    unhealthy_threshold = "2"
  }

  tags = {
    Name        = "${var.name}-tg-${var.environment}"
    Environment = var.environment
  }
}

# Redirect to https listener
resource "aws_alb_listener" "http" {
  load_balancer_arn = aws_lb.main.id
  port              = 80
  protocol          = "HTTP"

  default_action {
    type = "redirect"

    redirect {
      port        = 443
      protocol    = "HTTPS"
      status_code = "HTTP_301"
    }
  }
}

# Redirect traffic to target group
resource "aws_alb_listener" "https" {
  load_balancer_arn = aws_lb.main.id
  port              = 443
  protocol          = "HTTPS"

  ssl_policy        = "ELBSecurityPolicy-2016-08"
  certificate_arn   = var.alb_tls_cert_arn

  default_action {
    target_group_arn = aws_alb_target_group.main.id
    type             = "forward"
  }
}

To connect to my database, I use local ssh port forwarding:

# Run in the foreground
ssh -N ubuntu@<bastion_ip> -L 8888: rds-db.weoweio.ap-southeast-2.rds.amazonaws.com:5432

# Run in the background
ssh -Nf ubuntu@<bastion_ip> -L 9999: rds-db.weoweio.ap-southeast-2.rds.amazonaws.com:5432

This setup has always worked, and with fail2ban/Guardduty and IP whitelist via security groups, it works great.

Challenges with this configuration

• I have to keep OpenSSH updated to mitigate emerging attacks that target vulnerabilities in outdated versions.
• I have to manage ssh keys. ssh key management is hard, especially with large teams.
• Auditing ssh sessions is a painful task.
• Keeping public IP/DNS increases my attack surface.

The solution

EC2 Instance Connect

When I read about EC2 Instance Connect in 2019 as a way to connect to an ec2 instance with temporary SSH keys, I was excited.

EC2 Instance Connect lets me manage SSH access via IAM.

It works by allowing a user to send temporary public keys to the EC2 instance using a CLI, the user then has 60seconds to authenticate using the private key.

So instead of using long-term SSH keys that live on the bastion, I can use temporary/disposable keys that are automagically discarded after 60seconds.

SSM

Using EC2 Instance Connect helps eliminate most of the problems listed above except the last one.

Using the AWS systems manager StartSSHSession document, I'm able to take the security a notch higher by eliminating the public DNS on the bastion.

How to do this in terraform

To do this in terraform, I have to :

• Configure IAM permissions for the bastion — Add an IAM instance profile that includes 2 policies.
  • arn:aws:iam::aws:policy/EC2InstanceConnect
  • arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
• Install EC2 instance connect on the bastion or update my AMI. I found that EC2 instance connect comes pre-installed with certain AMIs (Amazon Linux > 2 2.0.20190618 and Ubuntu > 20.04 ).
• Install ec2_instance_connect CLI on my local environment.
• Install SSM plugin for the AWS CLI to my local environment. Reference here

And some cleanup steps:

• Remove the SSH key pair on the bastion.
• Remove the SSH ingress rules from my bastion security group.
• Move the bastion from the public subnet to a private subnet.

The changes to the bastion module

module "bastion" {
  source  = "terraform-aws-modules/ec2-instance/aws"
  version = "2.16.0"

  ami                 = "ami-0e2e14798f7a300a1"
  name                        = var.name
  associate_public_ip_address = true
  instance_type               = "t2.small"
  vpc_security_group_ids      = [module.bastion_security_group.this_security_group_id]
  
  # Move the bastion into a private subnet
  subnet_ids                  = var.vpc_private_subnets
  
  # remove the redundant ssh key pair
  key_name                    = var.bastion_key_name
}

module "bastion_security_group" {
  source  = "terraform-aws-modules/security-group/aws"
  version = "3.1.0"

  name   = "${var.name}-sg"
  vpc_id = var.vpc_id

  # remove redundant ssh ingress rule
  ingress_cidr_blocks = ["0.0.0.0/0"]
  ingress_rules       = ["ssh-tcp"]

  egress_cidr_blocks = ["0.0.0.0/0"]
  egress_rules       = ["postgresql-tcp", "http-80-tcp", "https-443-tcp"]
}


module ec2_connect_role_policy {
  source  = "terraform-aws-modules/iam/aws//modules/iam-assumable-role"
  version = "~> 3.7.0"

  role_name               = "${var.name}-ec2-connect-role"
  role_requires_mfa       = false
  create_role             = true
  create_instance_profile = true

  trusted_role_services   = ["ec2.amazonaws.com"]
  custom_role_policy_arns = ["arn:aws:iam::aws:policy/EC2InstanceConnect", "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"]
}

SSH Tunneling

To set up the ssh tunnel I:

• Generate a temporary ssh key.
• Use ec2-instance-connect to upload the key to the bastion
• SSH to the server over session manager using SSH ProxyCommand and the AWS CLI SSM plugin

# Generate a temporary ssh key. 
ssh-keygen -t rsa -f /ssh_key -N ''

# Use ec2-instance-connect to upload the key to the bastion
aws ec2-instance-connect send-ssh-public-key --instance-id <instance_id> --instance-os-user <os_user> --availability-zone <az> --ssh-public-key file:///ssh_key.pub

#ssh to the server over session manager using the aws cli SSM plugin
ssh <os_user>@<instance_id> -i /ssh_key -Nf \
  -L 9999:<rds_endpoint> \
  -o "StrictHostKeyChecking=no" \
  -o "UserKnownHostsFile=/dev/null" \
  -o ProxyCommand="aws ssm start-session --target %h --document AWS-StartSSHSession --parameters portNumber=%p --region=<region>"

My primary concern here is rds access. I haven't had the need to ssh into a fargate managed container in the ECS cluster but I imagine it would work the same way.

Recently, I’ve worked on setting up testing for a mono-repo at Assignar.
We use jest for testing, and although jest added a [multi-project runner] over a year ago, I couldn’t find any guides on it which made the implementation a bit of a pain.

This post is about my experience with the implementation.

The Problem.

Monorepos are a source control pattern where all of the source code is kept in a single repository. This pattern has it's challenges. For testing, they include:

• Management. Testing can become unmanageable in a monorepo as there are many smaller projects that have their own setup and configuration.
• Running tests. Having to cd into every directory and run tests for each project is time consuming, and you miss out on unified coverage report.

The solution

Jest projects helps you manage and run tests for project in a mono-repo using a single instance of jest.

Goals

• Run tests globally from the root.
• Run tests from individual project directories.
• Let developers manage their own jest, babel, and typescript configurations, i.e. shared common configuration in the root, and have custom configuration in each package.

Project Structure

 ├──assignar   
 │   ├── packages
 │   │   ├── packageA
 │   │   │   ├── jest.config.js - jest config file for packageA (extends base.config.base.js)
 │   │   │   ├── .babelrc - used by `babel-jest` to transpile ts in packageA
 │   │   ├── packageB
 │   │   │   ├── jest.config.js - jest config file for packageB (extends base.config.base.js)
 │   │   │   ├── .babelrc - used by `babel-jest` to transpile ts in packageA
 │   │   │── packageC
 │   │   │   ├── jest.config.js - jest config file for packageC (extends base.config.base.js)
 │   │   │   ├── .babelrc - used by `babel-jest` to transpile ts in packageA
 │   ├── jest.config.base.js - (base jest config, imported by other packages)
 │   ├── babel.config.js - (used to instruct babel to use `.babelrc` files within the each package root directory`
 └── └── jest.config.js - config used to configure projects and run all tests 

Root Configuration

The root of the app contains:

• jest.config.js
• jest.config.base.js
• babel.config.js

jest.config.js
To setup jest projects for the directory structure above, I specify a path glob.

// jest.config.js
module.exports = {
...,
projects: [ '<rootDir>/packages/*/jest.config.js']
}

I end up with a file that looks like this.

const baseConfig = require('./jest.config.base')

module.exports = {
    ...baseConfig,
    projects: [
            '<rootDir>/packages/*/jest.config.js',
    ],
    coverageDirectory: '<rootDir>/coverage/',
    collectCoverageFrom: [
        '<rootDir>/packages/*/src/**/*.{ts,tsx}',
    ],
    testURL: 'http://localhost/',
    moduleNameMapper: {
        '.json$': 'identity-obj-proxy',
    },
    moduleDirectories: [
        'node_modules',
    ],
    snapshotSerializers: [
        'enzyme-to-json/serializer',
    ],
}

jest.config.base.js
The base config ./jest.config.base.js contains configuration that's shared across the monorepo.

babel.config.js
We use babel-jest for ts transpilation, and so I had to figure out a way to let babel use the babelrc files in individual project directories. I was shocked to find that this doesn't work out of the box.
After a bit of digging, I found this comment on github that explains that you have to specify babelRcRoots: "packages/*" in babel.config.js(which is a new non-heirarchical config file that loads from the root directory) to instruct babel to use the configurations in subdirectories.
There's more information on that config file in the babel docs

Project Configuration

Based on my monorepo's jest.config.js configuration above, jest looks for jest.config.js files in my packages directory and sets up the parent directories of those files as projects.

Root Directory
I set the root directory of all project configurations as the root directory of the mono-repo.i.e. {rootDir: '../..'}.

As a result I have to specify absolute path all over my configuration instead of relative path. e.g.

 {
 setupTestFrameworkScriptFile:rootDir>/packages/${packageName}/jest/setupJest.ts
 }

Naming
Jest provides a displayName option, which is shown nexts to the tests in the terminal.

Module Paths
I ran into ts path issues while running the tests. Some typescript project configurations specify a baseUrl of ./src, and typescript tries to resolve modules using monorepoRootDir/src.

Jest has a modulePaths option to let you provide an array of absolute paths to search when resolving modules. This solved the above issue.

Each package ends up with a configuration like this.

'use strict'
const baseConfig = require('../../jest.config.base')

const packageName = require('./package.json').name.split('@assignar/').pop()

module.exports = {
    ...baseConfig,
    roots: [
        `<rootDir>/packages/${packageName}`,
    ],
    collectCoverageFrom: [
        'src/**/*.{ts,tsx}',
    ],
    setupFiles: [
        `<rootDir>/packages/${packageName}/jest/polyfills.ts`,
        `<rootDir>/packages/${packageName}/jest/setupEnzyme.ts`,
    ],
    setupTestFrameworkScriptFile: `<rootDir>/packages/${packageName}/jest/setupJest.ts`,
    testRegex: `(packages/${packageName}/.*/__tests__/.*|\\.(test|spec))\\.tsx?$`,
    testURL: 'http://localhost/',
    moduleNameMapper: {
        '.json$': 'identity-obj-proxy',
        'lodash-es': 'lodash',
    },
    moduleDirectories: [
        'node_modules',
    ],
    modulePaths: [
        `<rootDir>/packages/${packageName}/src/`,
    ],
    snapshotSerializers: [
        'enzyme-to-json/serializer',
    ],
    name: packageName,
    displayName: packageName,
    rootDir: '../..',
}

Alternatives

Lerna is a tool that optimizes the workflow around managing multi-package repositories.
Lerna has a test command you can run. lerna run test runs a script that goes through each package and runs the test script declared in package.json. This is very slow, might lose syntax highlighting, and use up too much resources as it spawns tests in seperate processes. Also it doesn't solve any of the problems we faced, so it wasn't a viable option.

This has worked out well, as we now able to run pre-commit hooks using lerna's --onlyChanged option, and we have one coverage report for all projects across the mono-repo.

One challenge is that I've been unable to use jest's --findRelatedTests option, which would be greate for CI.
I hope to figure that out soon.

One last thing

Last year, I fell in love with Terraform and I used it with AWS and Digital ocean with really great results.

I recently began to explore Azure and I faced a couple of challenges getting to use Terraform with Azure, so I thought I'd write an article about it.

In this article, I will talk about Terraform and show the steps I followed, and challenges faced while setting up virtual machines in a Virtual network and all the supporting infrastructure (subnets, resource groups, security groups, etc).

Background

HashiCorp's Terraform is my preferred tool for orchestration. Although I still use Ansible for configuration management, I prefer to use Terraform for orchestration.

Configuration management tools install and manage software on a machine that already exists. Terraform is not a configuration management tool, and it allows existing tooling to focus on their strengths: bootstrapping and initializing resources.

With the availability of docker and packer, there's little need for configuration management, so I have found my need for ansible has reduced significantly.

Why I use terraform

I could probably write a blog post about how great terraform is, but I'll just list 2 reasons here.

• Declarative code : Terraform lets you use a declarative style to write your code, so you just write your desired end state, and leave it to decide the order in which your declared resources need to be created.
• Client-side architecture : Terraform connects to cloud providers directly through their APIs, so you don't need to setup or run any special softwares on your servers.

Requirements

• Terraform
• Azure-CLI

Installing Terraform

To install Terraform, you need to download the appropriate package, unzip the package, and add the executable file to your PATH.

# step 1. Download the package
wget https://releases.hashicorp.com/terraform/0.8.7/terraform_0.8.7_linux_amd64.zip
# step 2. Unzip the package
unzip terraform_0.8.7_linux_amd64.zip
#move the execuatable to directory in PATH 
sudo mv terraform /usr/bin/

At this point, terraform should be added to your path. You can confirm this by running terraform --version which should show your installed version 0.8.7 in my case.

Installing Azure CLI

pip install --user --upgrade azure-cli

If you don't have python or pip installed and would rather not install them, you can read here for alternative installation methods.

Connecting to Azure subscription

Every account on Azure is part of a subscription. To connect to azure services, Terraform needs to be able to provision resources unto your Azure subscription for you.

Azure Active Directory manages access to subscriptions. It is an Identity and Access management solution that provides a set of capabilities to manage users and groups.
I'm still wrapping my head around the idea of Azure Active Directory so you can join me to read about it here

To connect Terraform to azure, you need the following credentials:

• A subscription ID
• A client ID
• A client secret
• A Tenant ID

HashiCorp and Microsoft have produced scripts to help with obtaining these here however the script continually failed for me, so here's how I went about obtaining these credentials.

Login

# first step, run the login command follow the steps 
$ az login

#you should see an output like below.
[
  {
    "cloudName": "AzureCloud",
    "id": "ads238932-2323-209239-SUSI-02ksjdk",
    "isDefault": true,
    "name": "BizSpark",
    "state": "Enabled",
    "tenantId": "fo90dfoi-23-232ji-a233-c2389jkk2389832",
    "user": {
      "name": "email@outlook.com",
      "type": "user"
    }
  }
]
#save the tenantId and id. The id here is your subscription ID

Now we have the subscription ID and tenant ID, next we find the client secret and client ID.

Set subscription ID

#replace SUBSCRIPTION_ID with the id above or set it as the SUBSCRIPTION_ID environmental variable.

az account set --subscription="${SUBSCRIPTION_ID}"

Create role for subscription

Three things need to be done here:

• Create Azure active directory application
• Create Azure service principal
• Assign a contributor role

#Create a service principal, configure its access to Azure resources and assign Contributor role.

az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/${SUBSCRIPTION_ID}"

# This should return JSON with the appId and password

{
  "appId": "12332skdu-we32-23df-se43-wew23243223",
  "displayName": "azure-cli-2017-02-10-02-18-22",
  "name": "http://azure-cli-2017-02-10-02-18-22",
  "password": "jsiue981289-12-12er-we2344-23ksjksd",
  "tenant": "fo90dfoi-23-232ji-a233-c2389jkk2389832"
} 

The appId returned above is the client ID, and password is the client secret we need to use with terraform.

You can confirm the credentials by running the login command on the cli using the app ID, password and tenant ID obtained above.

az login --service-principal -u [APP ID] -p [PASSWORD] --tenant [TENANT ID]

Terraform script

After obtaining credentials we can move on to create the terraform script. In this part, I'll create an empty resource group and a virtual network with 3 subnets.

I'll create two files; one for variables and one to create resources. I like to keep my variables in a different file, so they can be referenced in my script.

First I'll create a file to save my variables, I'll call this variables.tf

#variables.tf
variable "tenant_id" {
	default = "o90dfoi-23-232ji-a233-c2389jkk2389832"
}

variable "client_id" {
	default="12332skdu-we32-23df-se43-wew23243223"
}

variable "client_secret" {
	default="jsiue981289-12-12er-we2344-23ksjksd"
}

variable "subscription_id" {
	default="ads238932-2323-209239-SUSI-02ksjdk"
}

Next I'll create a file called main.tf with code to create my resources.

#main.tf
# Configure the Microsoft Azure Provider
provider "azurerm" {
  subscription_id = "${var.subscription_id}"
  client_id       = "${var.client_id}"
  client_secret   = "${var.client_secret}"
  tenant_id       = "${var.tenant_id}"
}

# Create a resource group
resource "azurerm_resource_group" "development" {
    name     = "development"
    location = "North Europe"
}

# Create a virtual network in the web_servers resource group
resource "azurerm_virtual_network" "network" {
  name                = "developmentNetwork"
  address_space       = ["192.168.0.0/16"]
  location            = "${azurerm_resource_group.production.location}"
  resource_group_name = "${azurerm_resource_group.production.name}"

  subnet {
    name           = "subnet1"
    address_prefix = "192.168.1.0/24"
  }

  subnet {
    name           = "subnet2"
    address_prefix = "192.168.2.0/24"
  }

  subnet {
    name           = "subnet3"
    address_prefix = "192.168.3.0/24"
  }
}

Running the script

I'll run terraform plan to see what changes will be made. If you're new to terraform. The plan command helps you catch bugs and verify changes before deployment.

$ terraform apply

Refreshing Terraform state in-memory prior to plan...

+ azurerm_resource_group.development
    location: "northeurope"
    name:     "development"
    tags.%:   "<computed>"

+ azurerm_virtual_network.network
    address_space.#:                  "1"
    address_space.0:                  "192.168.0.0/16"
    location:                         "northeurope"
    name:                             "developmentNetwork"
    resource_group_name:              "development"
    subnet.#:                         "3"
    subnet.1008457452.address_prefix: "192.168.3.0/24"
    subnet.1008457452.name:           "subnet3"
    subnet.1008457452.security_group: ""
    subnet.1321000609.address_prefix: "192.168.2.0/24"
    subnet.1321000609.name:           "subnet2"
    subnet.1321000609.security_group: ""
    subnet.3646277238.address_prefix: "192.168.1.0/24"
    subnet.3646277238.name:           "subnet1"
    subnet.3646277238.security_group: ""
    tags.%:                           "<computed>"


Plan: 2 to add, 0 to change, 0 to destroy.

Everything looks okay, I'll run terraform apply to deploy these resources to azure.

$ terraform apply

azurerm_resource_group.development: Creating...
  location: "" => "northeurope"
  name:     "" => "development"
  tags.%:   "" => "<computed>"
azurerm_resource_group.development: Creation complete
azurerm_virtual_network.network: Creating...
  address_space.#:                  "" => "1"
  address_space.0:                  "" => "192.168.0.0/16"
  location:                         "" => "northeurope"
  name:                             "" => "developmentNetwork"
  resource_group_name:              "" => "development"
  subnet.#:                         "" => "3"
  subnet.1472110187.address_prefix: "" => "192.168.1.0/24"
  subnet.1472110187.name:           "" => "subnet1"
  subnet.1472110187.security_group: "" => ""
  subnet.2796830261.address_prefix: "" => "192.168.2.0/24"
  subnet.2796830261.name:           "" => "subnet2"
  subnet.2796830261.security_group: "" => ""
  subnet.4132282879.address_prefix: "" => "192.168.3.0/24"
  subnet.4132282879.name:           "" => "subnet3"
  subnet.4132282879.security_group: "" => ""
  tags.%:                           "" => "<computed>"
azurerm_virtual_network.network: Creation complete

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Conclusion

I decided to make this into a 2-part series. In the next part, I'll create a network with subnets, network interfaces, storage blocks, virtual machines and storage disks.

If you've faced any other challenges or have any other comments, please let me know in the comments.

Although I have worked with Angularjs for a while, I never got to explore Ionic until very recently.

In this post, I write about my first experience with setting up Ionic and building a simple application with it.

I found a client who wanted to hire me to work on an android project that was built using Angularjs/Ionic and cordova. .

I was asked to create a very basic android application using Ionic/Angularjs. The features are:

• share text from my app to another app.
• take a screenshot of my screen, save it and share it.

Step1 : Installation

You need to have node.js installed.

• Install cordova $ npm install -g cordova

• Install ionic, set platform, and run. You can replace android with ios here

After instlalling cordova. if you use a windows machine, you'll have to set up Java JDK, Apache Ant and Android SDK. Download these and refer to the phonegap guide for help with PATH setup.

I installed this plugin to use android's sharing feature.
Installing via CLI is easy. Just run
$ cordova plugin add https://github.com/EddyVerbruggen/SocialSharing-PhoneGap-Plugin.git

Step2: Setting Up Angular

For my Angular setup first. I created a module, a controller(in a sperate module), and defined functions to handle my screenshots which will be applied to my views.

• Controller

• Main module. Here i included ionic and MainCtrl as dependencies.

• Main View
  My main view is really simple with a header-bar and two buttons that call toShare() and takeScreenshot() when clicked.

To run the aapp. Connect your android phone, and run ionic run android

Testing

Head on to github and download the code to tweak or test it.