DEV Community: DNX Labs

Protecting URLs with AWS ALBs and OIDC in 6 minutes

Allan Denot — Mon, 15 Nov 2021 23:11:19 +0000

00:00:00

Problem: You have a web app with an administration page that should be restricted to internal users.

Here's some of the options that would solve this:

Program authentication into your app, which would be different from your main user login as it's targeted to internal users and not your customers.
Deploy the app privately (like an internal load balancer) and require VPN access
Use some third-party service like Cloudflare Access.

We would like to propose a solution that could be implemented very quickly if you already using AWS Application Load Balancer (ALB).

00:01:00

This example we will authenticate internal users in Google Workspace, but this works with any Identity Provider that supports OIDC/OAuth2.

Go to your Google Cloud Console (linked to your Google Workspace account) as Admin and under "APIs & Services", create a new OAuth2 Client, as shown below:

More details here: https://support.google.com/cloud/answer/6158849?hl=en

In "Authorized JavaScript origins", enter the main URL of your web application (without the /admin path). And in "Authorized redirect URIs" enter the same as before, but adding oauth2/idpresponse to the path.

After creation, copy the Client ID and Client Secret generated to a secure location.

Also make sure your Google project's OAuth Consent is set to Internal, if you want to authenticate only internal users. If your goal is to authenticate anyone with a Google Account, you can leave it External.

00:03:00

Login to your AWS Console, under EC2 select Load Balancers, choose your load balance and edit the Listener Rules, as shown below:

Click the "+" icon to add a new rule.

Click "Insert rule" above the normal URL for your web app (which could be the default action).

In the left side, enter the conditions for the rule. As this example is for path-based, we will enter all paths we want to protect with an OAuth login screen:

Enter all paths ending with a * (remove the trailing slash from the path).

In the right side, enter Add Action > Authenticate, and select OIDC.

And setup Google Workspace OIDC with the following parameters:

Name	Value
Issuer	`https://accounts.google.com`
Authorization endpoint	`https://accounts.google.com/o/oauth2/v2/auth`
Token endpoint	`https://oauth2.googleapis.com/token`
User info endpoint	`https://openidconnect.googleapis.com/v1/userinfo`

And under Advanced Settings, set the Session Timeout to a small value, like 43200 (12 hours), otherwise the authentication will last for 7 days by default.

Just below the OIDC action, you now have to add the Forward action to reach your web app.

Copy the same action as the rule used at the moment to reach your web app. In this example, we were using a Default Action, Forwarding to a Target Group called "Laravel", so we will mimic this action into our OIDC rule, as shown below:

Click on the Save button above to save the new rule.

00:05:00

That's it, now access your web app under the URL protected and you should be redirected to a Google authentication page.

After authenticated, ALB will add a cookie that lasts for 12 hours (or the Session Timeout set before).

If you like this post, you will love our 100+ open source repositories with moslty Terraform modules that help you achieve stuff like this.

Check out our repos at https://github.com/DNXLabs, specially https://github.com/DNXLabs/terraform-aws-ecs-app that comes with this feature built in.

Launching Amazon FSx for Windows File Server and Joining a Self-managed Domain using Terraform

maiconrocha — Tue, 19 Oct 2021 03:02:28 +0000

TL;DR:

The github repo with all scripts are here.

Because of specific requirements, reasons, or preferences, some customers need to self-manage a Microsoft AD directory on-premises or in the cloud.

AWS offers options to have their fully managed Microsoft Windows file servers (Amazon FSx for Windows File Server) join a self-managed Microsoft Active Directory.

In this post, I will provide an example of launching an FSx for Windows File Server and joining a self-managed domain using Terraform.

This article won’t go into details on the following items as they are presumed to already be created.

Requirements:

self-managed Microsoft AD directory
the fully qualified, distinguished name (FQDN) of the organisational unit (OU) within your self-managed AD directory that the Windows File Server instance will join; and
valid DNS servers and networking configuration (VPC/Subnets) that allows traffic from the file system to the domain controller.

In addition, I recommend to go through the steps “Validating your Active Directory configuration” from AWS Documentation at the following link to validate self-managed AD configuration before starting creation of the FSx filesystem:

On the file _variables.tf, we will provide the details for the self-managed AD, including IPs, DNS Name, Organisational Unit, and Domain Username and Password:

_variables.tf

variable "ad_directory_name" {
 type    = string
 default = "example.com"
}

variable "ad_directory_ip1" {
 type    = string
 default = "XXX.XXX.XXX.XXX"
}

variable "ad_directory_ip2" {
 type    = string
 default = "XXX.XXX.XXX.XXX"
}

variable "fsx_name" {
 type    = string
 default = "fsxblogpost"
}

variable "domain_ou_path" {
 type    = string
 default = "OU=Domain Controllers,DC=example,DC=com"
}

variable "domain_fsx_username" {
 type    = string
 default = "fsx"
}

variable "domain_fsx_password" {
 type    = string
 default = "placeholder"
}

variable "fsx_deployment_type" {
 type    = string
 default = "SINGLE_AZ_1"
}

variable "fsx_subnet_ids" {
 type    = list(string)
 default = ["subnet-XXXXXXXXXXXX"]
}

variable "vpc_id" {
 type    = string
 default = "vpc-XXXXXXXXXXXX"
}


variable "fsx_deployment_type" {
 type    = string
 default = "SINGLE_AZ_1"
}

variable "fsx_subnet_ids" {
 type    = list(string)
 default = ["subnet-XXXXXXXXXXXX"]
}

variable "vpc_id" {
 type    = string
 default = "vpc-XXXXXXXXXXXX"
}

The file fsx.tf is where we will effectively create FSx filesystem, and also KMS encryption key and KMS Key policy. The KMS key is optional, however I strongly recommend having the filesystem encrypted.

fsx.tf

data "aws_iam_policy_document" "fsx_kms" {
 statement {
   sid       = "Allow FSx to encrypt storage"
   actions   = ["kms:GenerateDataKey"]
   resources = ["*"]
   principals {
     type        = "Service"
     identifiers = ["fsx.amazonaws.com"]
   }
 }
 statement {
   sid       = "Allow account to manage key"
   actions   = ["kms:*"]
   resources = ["arn:aws:kms:${data.aws_region.current.name}:${data.aws_caller_identity.current.account_id}:key/*"]
   principals {
     type        = "AWS"
     identifiers = ["arn:aws:iam::${data.aws_caller_identity.current.account_id}:root"]
   }
 }
}

resource "aws_kms_key" "fsx" {
 description             = "FSx Key"
 deletion_window_in_days = 7
 policy                  = data.aws_iam_policy_document.fsx_kms.json
}

resource "aws_fsx_windows_file_system" "fsx" {
 kms_key_id          = aws_kms_key.fsx.arn
 storage_capacity    = 100
 subnet_ids          = var.fsx_subnet_ids
 throughput_capacity = 32
 security_group_ids  = [aws_security_group.fsx_sg.id]
 deployment_type     = var.fsx_deployment_type

 self_managed_active_directory {
   dns_ips                                = [var.ad_directory_ip1, var.ad_directory_ip2]
   domain_name                            = var.ad_directory_name
   username                               = var.domain_fsx_username
   password                               = var.domain_fsx_password
   organizational_unit_distinguished_name = var.domain_ou_path
 }
}

resource "aws_security_group" "fsx_sg" {
 name        = "${var.fsx_name}-fsx-sg"
 description = "SG for FSx"
 vpc_id      = data.aws_vpc.selected.id

 tags = {
   Name = "${var.fsx_name}-fsx-sg"
 }
}

resource "aws_security_group_rule" "fsx_default_egress" {
 description       = "Traffic to internet"
 type              = "egress"
 from_port         = 0
 to_port           = 0
 protocol          = "-1"
 security_group_id = aws_security_group.fsx_sg.id
 cidr_blocks       = ["0.0.0.0/0"]
}

resource "aws_security_group_rule" "fsx_access_from_vpc" {
 type              = "ingress"data "aws_iam_policy_document" "fsx_kms" {
  statement {
    sid       = "Allow FSx to encrypt storage"
    actions   = ["kms:GenerateDataKey"]
    resources = ["*"]
    principals {
      type        = "Service"
      identifiers = ["fsx.amazonaws.com"]
    }
  }
  statement {
    sid       = "Allow account to manage key"
    actions   = ["kms:*"]
    resources = ["arn:aws:kms:${data.aws_region.current.name}:${data.aws_caller_identity.current.account_id}:key/*"]
    principals {
      type        = "AWS"
      identifiers = ["arn:aws:iam::${data.aws_caller_identity.current.account_id}:root"]
    }
  }
}

resource "aws_kms_key" "fsx" {
  description             = "FSx Key"
  deletion_window_in_days = 7
  policy                  = data.aws_iam_policy_document.fsx_kms.json
}

resource "aws_fsx_windows_file_system" "fsx" {
  kms_key_id          = aws_kms_key.fsx.arn
  storage_capacity    = 100
  subnet_ids          = var.fsx_subnet_ids
  throughput_capacity = 32
  security_group_ids  = [aws_security_group.fsx_sg.id]
  deployment_type     = var.fsx_deployment_type

  self_managed_active_directory {
    dns_ips                                = [var.ad_directory_ip1, var.ad_directory_ip2]
    domain_name                            = var.ad_directory_name
    username                               = var.domain_fsx_username
    password                               = var.domain_fsx_password
    organizational_unit_distinguished_name = var.domain_ou_path
  }
}

resource "aws_security_group" "fsx_sg" {
  name        = "${var.fsx_name}-fsx-sg"
  description = "SG for FSx"
  vpc_id      = data.aws_vpc.selected.id

  tags = {
    Name = "-${var.fsx_name}-fsx-sg"
  }
}

resource "aws_security_group_rule" "fsx_default_egress" {
  description       = "Traffic to internet"
  type              = "egress"
  from_port         = 0
  to_port           = 0
  protocol          = "-1"
  security_group_id = aws_security_group.fsx_sg.id
  cidr_blocks       = ["0.0.0.0/0"]
}

resource "aws_security_group_rule" "fsx_access_from_vpc" {
  type              = "ingress"
  from_port         = 0
  to_port           = 0
  protocol          = "-1"
  security_group_id = aws_security_group.fsx_sg.id
  cidr_blocks       = [data.aws_vpc.selected.cidr_block]
}

 from_port         = 0
 to_port           = 0
 protocol          = "-1"
 security_group_id = aws_security_group.fsx_sg.id
 cidr_blocks       = [data.aws_vpc.selected.cidr_block]
}

Once you apply the scripts on Terraform, it should take around 15 minutes for the resources to be created:

aws_fsx_windows_file_system.fsx: Creation complete after 15m54s [id=fs-05701e8e6ad3fbe24]

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

You should see the FSx created and in Available state on AWS Console, which means FSx was able to join the self-managed domain:

Conclusion

I hope the instructions and terraform scripts provided can make your life easier when launching FSx for Windows File Server and joining a self-managed domain using Terraform.

When recently working on a project, I noticed there weren’t many examples online, so I decided to write this blog post to help others.

I would encourage you to open an issue or feature request on the github repo in case you need any additional help when using the scripts.

ARM vs Intel - A real-world comparison using EC2

Allan Denot — Wed, 02 Dec 2020 11:38:32 +0000

With the recent move from Apple to ARM-based CPUs, everyone seems to be in awe of the performance of the ARM-based Apple M1s.

As a cloud engineer, I couldn't avoid asking if this performance translates to cloud computing too.

AWS has their line of ARM CPUs called Graviton, available in their second generation as the m6g family in EC2. Those CPUs are on average 20% cheaper for the same amount of vCPUs and RAM, but how do they compare in terms of real-world performance, against traditional Intel CPUs? That's what we are here to find out.

Setup

	Intel	ARM
Instance Count	1	1
Instance Type	m5.large	m6g.large
CPU Tested	Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	Custom built AWS Graviton2 Processor with 64-bit Arm Neoverse cores
CPU Count	2	2
Clock (MHz)	3397.426	N/A
Region/AZ	ap-southeast-2c	ap-southeast-2c
Price (Sydney)	$0.120 per Hour	$0.096 per Hour

cat /proc/cpuinfo didn't show much information for the Graviton CPUs, I guess AWS wants to be secretive about it.

Platform

The goal is to simulate a workload close to a real-world scenario, so we chose to use a Laravel API connecting to a MySQL database, which is a popular stack today.

The infrastructure used:

AWS ECS running in EC2
2 Docker containers (ECS tasks) running the same App in one instance
Containers limited to 1GB RAM (soft and hard limit), but no limit on CPU usage

Application

RealWorld Example API, Laravel
PHP 7.1
Apache/2.4.38 (Debian)

Container

Intel: FROM php:7.1-apache
ARM: FROM arm64v8/php:7.1-apache

Test Tool

ab -n 1000 -c 20 https://${HOST}/api/articles/test-post
^      ^      ^
⎮      |      ⎩ 20 concurrency
⎮      ⎩ 1000 requests
⎩ Apache Benchmark

Results

TL;DR

Graviton2 processors (m6g.large) are on average 25% faster than Intel on an m5.large instance.

Given that m6g.large is 20% cheaper, we get a total of 40% gain in price/performance.

Data (higher is better)

Graviton2 is almost 29% faster when shooting requests to a single container and the database behind is exactly the same.

When adding a second container to answer requests, interestingly Gravitons didn't see any improvement, while Intel did. The difference fell to 8% only

Testing with requests that do not require database access, the number of requests per second were higher for both, and Graviton kept a good margin against Intel of 26%.

As a bonus, we decided to match the same instance type in the database. That means that now the m5.large EC2 instance is connected to a db.m5.large RDS instance and the m6g.large to a db.m6g.large RDS instance.

Results were pretty similar to before, with a 22% advantage to Gravitons, meaning that for this specific test, the database was not a bottleneck.

Final Thoughts

A simple change in your Dockerfile could mean a 40% cost reduction in your compute costs.

As M1 Macs become more popular, dev teams will be multi-platform, requiring environments (both local and cloud) to support different architectures.

Docker also is working on better support for multi-platform images with docker buildx, making it more portable and easier to use the most cost-effective computing platform, independent of architecture.