DEV Community: Karanbir Singh

AWS API gateway JWT Authorizer with Zitadel

Karanbir Singh — Sun, 26 Feb 2023 18:12:50 +0000

AWS API gateway introduced HTTP API endpoints based integration in recent 2-3 years and they are different from the legacy REST API endpoint.

With this AWS also introduced JWT authorizer based authorization for the endpoints and made life easy for all the architects and developers, who were previously forced to use a custom authorizer only.

In this blog post which you are reading the primary focus is on AWS API gateway JWT Authorizer - with Pulumi as IAC provisioner & Zitadel for the identity/ authentication provider.

Reference to the zitadel setup for client_credentials flow here

Prerequisites

AWS account.
Average knowledge about AWS, AWS API Gateway, AWS Lambda Functions.
AWS CLI, Pulumi CLI on local machine.
NodeJS 16 on local machine.
Zitadel cloud account(setting up zitacloud is out of scope of this blog post) - refer my other blog post here for setting up zitadel cloud account
You may also use any other Identity provider. (like AWS cognito, etc.)
Great to have knowledge of JWT.

Flow Diagram Positive Scenario

client fetches the access token required by the API endpoint before hitting the actual endpoint.
client sends request along with JWT as part of an Authorization Header prefixed with Bearer or can be without Bearer, to API gateway.
AWS API gateway delegates the Authorization to it's self managed Authorizer(not sure how they might be doing it - could be internally lambda managed?!).
fetches the jwks based on the issuer property & validates the signature of the JWT based on the kid in the input JWT.
internal JWT authorizer will return back true/ success.
API gateway will pass on the original request to the AWS lambda function.
Lambda function will reply back the response.
Response received from the lambda function is sent back to the client.

Flow Diagram Negative Scenario

client fetches the access token required by the API endpoint before hitting the actual endpoint. (or if skipped for testing purpose)
client sends incorrect or blank or expired or misconfigured token.
AWS API gateway delegates the Authorization to it's self managed Authorizer(not sure how they might be doing it - could be internally lambda managed?!). It will delegate only if the header was present.
fetches the jwks based on the issuer property & validates the signature of the JWT based on the kid in the input JWT.
authorizer will reply back with false.
API gateway sends back the response as 401 (Unauthorized) or 403(forbidden).

Code and configuration

The code repository referred is from the previous blog post

change the configuration in the stack's yml files
domain, cert, zitacloud issuer, etc. as per your setup

Link to the repo is here and the branch is authorizer

The config related to the JWT authorizer are in the file:-

config:
  aws:profile: <AWS_PROFILE>
  aws:region: <AWS_REGION>
  non-mtls-apis:API_DOMAIN: <API_DOMAIN>
  non-mtls-apis:API_DOMAIN_MTLS: <MTLS_API_DOMAIN>
  non-mtls-apis:HOSTED_ZONE_NAME: <HOSTED_ZONE>
  non-mtls-apis:JWT:
    audiences:
      - test
      - aws_client
    issuer: https://instance_code.zitadel.cloud/
  non-mtls-apis:SUB_DOMAIN: <SUB_DOMAIN>
  non-mtls-apis:SUB_DOMAIN_MTLS: mtls.<SUB_DOMAIN>

Make changes to the audiences and issuer as per the setup.

audiences will be part of the JWT access token as aud claim.
issuer is also part of the JWT as iss claim.

If these configurations are not correct - then the API gateway will give error while accessing the endpoints

The error could be 401 unauthorized and relating to the below:-

issuer incorrect
jwks url not accessible
keys not resolvable, kid mismatch
JWT's - exp nbf, iat not correct

Please feel free to reach me over Linkedin here for further questions, doubts or suggestions.

Using & configuring zitadel for integration with AWS

Karanbir Singh — Sun, 26 Feb 2023 18:04:20 +0000

Introduction

This blog post is primarily related to setting up zitadel cloud account for the post - where I will be explaining the JWT authorizer.

I will skip the obvious setting up a zitadel account part, setting up of zitadel account is very straightforward and simple. Thanks to their great documentation on their site and great discussions over their discord server.

Configuration for client_credentials grant & Jwt type access token

Setup a service user.
Fill in the user details and access token type JWT
Generate Client credentials
Copy the client credentials
Call the token endpoint as below

Please feel free to reach out to me over Linkedin here for further questions, doubts or suggestions.

AWS API Gateway MTLS authentication - with SmallStep & Pulumi

Karanbir Singh — Fri, 17 Feb 2023 07:32:53 +0000

Introduction

During the 2022 Christmas holidays, I got (re-)introduced to Smallstep and believe me it is a very promising tech in PKI space, It eases a good number of complex problems that occur if you were self managing the PKI all by yourself from scratch.

This blog post's main focus is going to be about - Securing the APIs deployed on AWS API gateway using MTLS.

The second focus is on how we can leverage Smallstep for the PKI part.

Third most important part being the infra provisioning using Pulumi

Prerequisites

basic knowledge of mtls & PKI.
above average knowledge of AWS.
must own a domain. buy it from AWS route 53, or buy it from somewhere else and configure in AWS route 53 using NS entries.
AWS CLI installed.
configure AWS credentials on local, profile based.
some knowledge of Pulumi IAC.
Pulumi CLI on local machine.
account at Pulumi
account at Smallstep
step CLI on the developer machine. (OPTIONAL)

Stack Diagram & Details

The following are the important stacks which are part of this POC:-

infra stack (REQUIRED)
- manages the Certificates required for the API gateway custom domains, using the AWS certificate Manager.
- holds the s3 bucket that is required for the trust store certificate chain.
functions stack (REQUIRED)
- manages the lambda function(s), presently a very basic single lambda function, and related permissions, etc.
mtls-apis stack (REQUIRED)
- manages the API gateway related configuration, routes, integration, etc.
- it refers the infra stack to pull certificate ARNs etc.
- it refers the infra stack to pull s3 bucket & the ca.pem reference for the API gateway.
- it refers the functions stack to pull lambda function ARNs etc.
non-mtls-apis stack (OPTIONAL)
- manages the API gateway related configuration, routes, integration, etc.
- it refers the infra stack to pull certificate ARNs etc.
- it refers the functions stack to pull lambda function ARNs etc.

Code details

The code repository for the successful POC is here

The folder structure is same as per the above stack diagram.

Important points:-

The Public DNS zone in AWS route 53 was created manually. That is not part of the stack provisioning.
The order of executing the stack is infra, functions & then mtls-apis
Change the config in the pulumi yaml files in respective folders of all stack, for AWS credentials, region, and DNS domain related changes
The ca.pem in the infra stack needs to be replaced based on the own set of smallstep account. It is currently related to my own smallstep account.

create the ca trust store file.

Make sure you have a SmallStep Account & you are logged in to same.
By default intermediate and root are created for your account. Click on view details by clicking three dots against the entries of root and intermediate certificates and copy both of certificates into a single file.
Place the ca.pem in the infra stack's folder.

create client certificate

In the smallstep dashboard goto -> Authorities -> Click on the authority -> create certificate using UI, fill subject & expiration, as shown below:-
Authorize.
Download key and certificate, key is only downloadable at this time, later on it will not be available, keep it safe, otherwise the MTLS protected API endpoint might be compromised

Testing the API endpoint using POSTMAN

Configure the client cert and key in the certificates section in the settings of POSTMAN
If client cert not provided, the we will get -** Error: read ECONNRESET**
If the client cert and key combo is not correct we will get 403
If all successful, the API will response back as below:-

the path is going to be https://domain.com/v1/ping

{
    "ping": "pong",
    "success": true,
    "timestamp": 1676617772241
}

Please feel free to reach out to me over Linkedin here for further questions, doubts or suggestions.

AWS EC2 Metadata sidecar using Nginx

Karanbir Singh — Sun, 28 Aug 2022 18:27:00 +0000

AWS EC2 Metadata viewer using Nginx Docker Image

This one is just a hobby docker image to view/ look out for the ec2 instance’s metadata using a UI/ html hosted inside/ via nginx docker image.

While managing the AWS ec2 instances checking the instance metadata via curl is very manual and very repetitive work. So to fetch the same using some UI would be very easy for most us.

So here I was with the same challenge of removing the unwanted repeated stuff via curls and commands.

Prerequisites

AWS knowledge, AWS ec2 instance, etc. ❕
Docker installed on ec2 instance (obviously) ❕
⚠️Be Aware of the fact that your metadata will be available over web via html. As exposing/ sharing metadata might be security threat. (for hobby purpose or private ips it might be ok or public ip with proper security group etc.)
❗️ Metadata v1 for ec2. Extra work would certainly be required to expose v2 (that is based on tokens etc. and provides extra security over the metadata v1)

The Docker image can be accessed using the pull command as below:-

docker pull neuw/aws-ec2-nginx

Source code of the same is here available on Github

For Running the command the container the command is like below:-

docker run -itd --name nginx -p 80:80 neuw/aws-ec2-nginx

And after the UI will be available at :-

http://machine_host_or_ip:port/metadata.html

Replace hostname or ip and port accordingly

And UI should be available as below by default

In the first input box you can change the url to /latest/** and it will show you response accordingly.

Example:- /latest/meta-data

Further one may use the following user-data script while bootstrapping the ec2 instance(applicable for the AWS Linux 2 AMI only), details below:-

#!/bin/sh

yum update

# install docker and start the docker service
yum install docker -y
service docker start

# add ec2-user to the docker group
usermod -a -G docker ec2-user

# pull the image that was mentioned above
docker pull krnbr/ec2-nginx:latest

# run the same image as a container available on host's port 80
docker run -itd --name nginx -p 80:80 neuw/aws-ec2-nginx

Change port 80 to something more specific - And this image can run as sidecar to your other images, for debug purpose in lower environments