DEV Community: Alonso Suarez

This is THE simplest way to create a serverless HTTP App

Alonso Suarez — Wed, 03 Jul 2024 06:04:38 +0000

Let’s provision a new HTTP server:
Create a new Github Repo
Add a workflow on push

# .github/workflows/on-push-main.yml
name: demo
on:
  push:
    branches:
      - main
jobs:
  deploy:
    environment:
      name: main
      url: ${{ steps.backend.outputs.url }}
    permissions: 
      id-token: write
    runs-on: ubuntu-latest
    steps:
      - name: Check out repo
        uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: us-east-1
          role-to-assume: ${{ secrets.ROLE_ARN }}
          role-session-name: ${{ github.actor }}
      - uses: alonch/actions-aws-backend-setup@main
        with: 
          instance: sample
      - uses: alonch/actions-aws-http-node@main
        with:
          name: actions-aws-http-node-sample
          artifacts: src
          allow-public-access: true
          routes: |
            - entrypoint-file: plus
              entrypoint-function: handler
              path: "/plus/{z}"
              method: post
              parameters:
                path:
                - name: z
                  type: number
                query:
                - name: x
                  type: number
                body: 
                - name: y
                  type: number

Create function handler

// src/plus.js
exports.handler = async function (parameters) {
  const {
    path: { z },
    query: { x },
    body: { y }
  } = parameters
  return {
    status: 200,
    body: {
      total: z+x+y
    }
  };
};

Add AWS ROLE_ARN repo secret
Git push changes to Github
Navigate to Github Actions Tab, less than a minute later, the api-docs will be generated

But wait there is more, clients sending invalid payload will get 400 status code with the following payload:

$ curl -X 'POST' \
  'https://riga7yssypqgxndyz3xigmzsxy0jkhip.lambda-url.us-east-1.on.aws/plus/2?x=1' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{ }'  # <-- Invalid body  

{"in":["request","body-params"],"coercion":"malli","type":"request-coercion","value":{},"humanized":{"y":["missing required key"]}}

Code available on this sample repo and the full documentation here

Infra as GitHub Actions - AWS Serverless Function for nodejs

Alonso Suarez — Thu, 13 Jun 2024 04:27:34 +0000

In the last post we talked about the need to simplify infra while also moving it back to the application repo

As I started to work on the next infra as GitHub actions, which was a secured website with authentication@edge. It became clear that AWS lambda was a fundamental building block in the journey

Introducing actions-aws-function-node 🎉
Now with very few dependencies, you can provision your node backend in literally a minute 🏎️

Getting started

Let's start with familiar code

// src/index.js
exports.handler = async (event, context) => {
    return {
        "statusCode": 200,
        "headers": {
            "Content-Type": "*/*"
        },
        "body": "hello world"
    }
}

Add the workflow

# .github/workflows/on-push-main.yml
name: demo
on:
  push:
    branches:
      - main
jobs:
  deploy:
    environment:
      name: main
      url: ${{ steps.backend.outputs.url }}
    permissions: 
      id-token: write
    runs-on: ubuntu-latest
    steps:
      - name: Check out repo
        uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: us-east-1
          role-to-assume: ${{ secrets.ROLE_ARN }}
          role-session-name: ${{ github.actor }}
      - uses: alonch/actions-aws-backend-setup@main
        with: 
          instance: sample
      - uses: alonch/actions-aws-function-node@main
        with: 
          name: actions-aws-function-node-sample
          entrypoint-file: index.js
          entrypoint-function: handler
          artifacts: src
          allow-public-access: true

Add the secret ROLE_ARN with access to AWS and that's it, after pushing to main you have a GitHub deployment with you backend running 🎉
You can clone this sample from Github too
Of course, there are a lot more options

Permissions

You can allow access to services by just adding the resource name and the access, either read or write

For example:

      - uses: alonch/actions-aws-function-node@main
        with: 
          name: actions-aws-function-node-demo
          entrypoint-file: index.js
          entrypoint-function: handler
          artifacts: src
          allow-public-access: true
          permissions: |
            s3: read
            dynamodb: write

This configuration will attach AmazonS3ReadOnly and AmazonDynamoDBFullAccess managed policies to the function's role

Environment Variables

Similar to permissions, you can attach function variables as follow:

      - uses: alonch/actions-aws-function-node@main
        with: 
          name: actions-aws-function-node-demo
          entrypoint-file: index.js
          entrypoint-function: handler
          artifacts: src
          allow-public-access: true
          env: |
            DD_ENV: production 
            DD_SERVICE: demo
            DD_VERSION: ${{ github.sha }}

The rest of the options are standard attributes like memory, timeout or selecting ARM architecture

The best part is that it takes a minute to provision it and even less time to destroy 👏

I’m excited about the future developments and improvements that can be made to this workflow. If you have any feedback, questions, or suggestions, feel free to leave a comment below or reach out directly. Let’s continue this journey of simplifying infrastructure together!

Thank you for reading, and happy coding!

Next Generation SQL Injection: Github Actions Edition

Alonso Suarez — Fri, 07 Jun 2024 20:16:53 +0000

In the evolving landscape of software development, Continuous Integration and Continuous Deployment (CI/CD) tools like GitHub Actions have become indispensable. However, with great power comes great responsibility, and it's crucial to be aware of potential security pitfalls. One such vulnerability is treating untrusted inputs, such as branch names or pull request (PR) titles, as static parameters.
Spoiler alert, they should NOT be trusted

I enjoy puzzles, so here goes one:

steps:
  - name: Generate summary
    run: |
      echo "Pull Request for [${{ github.event.pull_request.title }}](https://github.com/${{ github.repository }}/pull/${{ github.event.pull_request.number }}) has been updated 🎉" >> $GITHUB_STEP_SUMMARY
      echo "Image tagged **v${{ needs.determine_app_version.outputs.app_version }}** has been built and pushed to the registry." >> $GITHUB_STEP_SUMMARY
This will generate a workflow summary like:

Can you spot the vulnerability?

The Problem

When a developer clicks on the Revert PR button in GitHub, the new PR title is Revert "<OLD TITLE>". This breaks the Generate summary step.

Try again if you haven’t spotted the vulnerability

The vulnerability lies in how github.event.pull_request.title input is handled. GitHub Actions expressions dynamically generate code. Unfortunately, if the PR title contains any special characters or unexpected input, it can cause the script to fail or behave unexpectedly.

The Impact

When developers click on Revert PR button, the PR title is Revert "<OLD TITLE>", the echo command in the Generate summary step generates the bash command:

echo "Pull Request for [Revert "<OLD TITLE>"](https://github.com/${{ github.repository }}/pull/${{ github.event.pull_request.number }}) has been updated 🎉" >> $GITHUB_STEP_SUMMARY

The presence of the double quotes within the PR title closes the echo early. However, this allows for bad actors to craft a title that could be used take full control of the runner

The Solution

To prevent this issue, one approach is to use env as an input “encoder” and avoid directly using GitHub Actions ${{ }} expressions. For example:

env:
  TITLE: ${{ github.event.pull_request.title }}
steps:
  - name: Generate summary
    run: |
      echo "Pull Request for [$TITLE](https://github.com/${{ github.repository }}/pull/${{ github.event.pull_request.number }}) has been updated 🎉" >> $GITHUB_STEP_SUMMARY

By using the env context to store untrusted inputs, you avoid potential script-breaking issues caused by special characters pre-rendered by Github Actions.

Leave a comment if you can think on a different way to solve this problem!

Provisioning AWS solutions in minutes with Infra as Github Actions

Alonso Suarez — Fri, 31 May 2024 21:40:00 +0000

I remember those days when I created infra by clicking in the console 😬 eventually that became a nightmare to manage and infra as code came to save the day 🦸 but with that, it also started an awkward phase of coupling infra code and app code
Some platform teams decided to move infra code to their own repos, that worked, specially for access control, but that required exceptions like:

Ignoring the image version since it was going to be managed by the app pipeline
The awkward environment variables setup

I've been searching for ways to bring infra back infra code to app repos

The first experiment was to keep network and LBs and move ECS services with Fargate to the app repo, this continuous to work surprisingly well after 3 years, environment variables changes are in the same PR as app that depended on it, another advantage was that terraform itself managed the newly built docker image tag. However, app developers rarely touched most of the terraform code, as terraform requires significant effort to learn, there has to be a better way 🤔

Entering Infra as GitHub Actions

With just a few line of YML, we can create pretty complex depended workflows, what if we can use Github Actions to compose infra?

I write a couple of actions that will provision the S3, CloudFront and Route53 with fairly simple steps:

Login to AWS
Setup the Backend
Provision the website

The whole workflow relies on only 3 inputs- Instance name: an identifier for the infra- Domain: DNS for the website, you need to own it on Route53- Path: content to publish as root on the website

permissions: 
  id-token: write
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repo
        uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: us-east-1
          role-to-assume: ${{ secrets.ROLE_ARN }}
          role-session-name: ${{ github.actor }}
      - uses: alonch/actions-aws-backend-setup@main
        with: 
          instance: demo
      - uses: alonch/actions-aws-website@main
        with: 
          domain: ${{ env.DOMAIN }}
          content-path: public

How it works

When a GitHub Action job is initialized, it checks out its source code from the repo, this unlocks interesting capabilities, for example: an action could apply terraform as if the terraform code is part of the current repo

actions-aws-backend-setup (repo)

  - uses: alonch/actions-aws-backend-setup@main
    with: 
      instance: demo

This action requires a custom instance name to query AWS by tag, we need to find the S3 and Dynamodb to setup the terraform backend

In case where it doesn’t exist, it will provision it and setup the environment variables:

TF_BACKEND_s3: bucket name
TF_BACKEND_dynamodb: table name

actions-aws-website (repo)

      - uses: alonch/actions-aws-website@main
        with: 
          domain: ${{ env.DOMAIN }}
          content-path: public

This action assumes the backend setup has run, and it requires a domain and the path to the content that needs to be publish as the website
Similar to the backend action, GitHub checks the source code which includes the terraform code to provision a Bucket, Cloudfront, Certificate and route53 routes
Using Github Actions is incredible flexible as the only dependency is on the AWS role and the backend instance name, in the case were we need to upgrade the infra, we just need to tag the new action version and terraform will sync the resources to the latest desired state

New degree of freedom

With Infra as Github Actions we basically can achieve ephemeral environments with a 31 lines of YML

name: Deploy Ephemeral Environment
on:
  pull_request:
    types: [opened, synchronize, reopened, closed]
env: 
  DOMAIN: ${{github.head_ref}}.test.realsense.ca
permissions: 
  id-token: write
jobs:
  deploy:
    environment:
      url: "https://${{ env.DOMAIN }}"
      name: ${{github.head_ref}}
    runs-on: ubuntu-latest
    steps:
      - name: Check out repo
        uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: us-east-1
          role-to-assume: ${{ secrets.ROLE_ARN }}
          role-session-name: ${{ github.actor }}
      - uses: alonch/actions-aws-backend-setup@main
        with: 
          instance: demo
      - uses: alonch/actions-aws-website@main
        with: 
          domain: ${{ env.DOMAIN }}
          content-path: public
          # destroy when PR closed
          action: ${{github.event.action == 'closed' && 'destroy' || 'apply'}}

This will create a new infra for that PR, update it in sync and destroy it when the PR is closed

What’s next?

This is just the beginning, I believe GitHub actions dependency could be use to compose and orchestre complex infra with simple interfaces
I'm considering building:

actions-aws-http-lambda: Serverless API from folder path
actions-aws-edge-auth: Website behind social media login from client secrets
actions-aws-http-server: Web hosting from docker image

What do you think? What should I focus on next?