Popular posts
-

Your workflow has
id-token: write. The role ARN is right. The trust policy looks exactly like the one in every tutorial. Andaws-actions/configure-aws-credentialsstill tells you to get lost:Not authorized to perform sts:AssumeRoleWithWebIdentityNothing changed on the AWS side. Nothing changed in the workflow. So what broke?
The thing that changed was GitHub
GitHub now issues immutable OIDC subject claims for some repositories — new repos created after the rollout, plus repos that opted in, were renamed, or were transferred. The
subclaim quietly grew a pair of numeric IDs: -
Setting Up CloudFront Functions for Hugo Page Routing
When hosting a Hugo site on AWS CloudFront, URLs ending with a trailing slash (like
/about/) don’t automatically resolve to their correspondingindex.htmlfiles. While Lambda@Edge can solve this, CloudFront Functions provide a more cost-effective and faster solution. This article will guide you through setting up a CloudFront Function to handle this routing properly.Why CloudFront Functions?
CloudFront Functions are a perfect fit for this URL rewriting task because:
-
Creating the Pipeline Execution Role
To deploy your Hugo site to AWS S3 using GitHub Actions OIDC, you’ll need to set up a specific IAM role. Here’s a step-by-step guide to creating and configuring this role.
Step 1: Configure the OIDC Provider
First, you need to create an OIDC provider in AWS IAM if you haven’t already:
- Navigate to the AWS IAM Console
- Go to Identity Providers
- Click “Add Provider”
- Select “OpenID Connect”
- For the Provider URL, enter:
https://token.actions.githubusercontent.com - For the Audience, enter:
sts.amazonaws.com - Click “Add provider”
Step 2: Create the IAM Role
- Go to IAM Roles in the AWS Console
- Click “Create Role”
- Select “Web Identity”
- Choose the GitHub OIDC provider you just created
- For the Audience, select
sts.amazonaws.com - Add the following trust relationship:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::<YOUR-AWS-ACCOUNT-ID>:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" }, "StringLike": { "token.actions.githubusercontent.com:sub": "repo:<GITHUB-USERNAME>/<REPOSITORY-NAME>:*" } } } ] }Replace:
-
Looking to automate your Hugo website deployments to AWS S3? The
hugo-to-s3-action-oidcGitHub Action makes this process seamless by handling both the build and deployment in a single step, all while using secure OIDC authentication.Prerequisites
Before you begin, ensure you have:
- A Hugo website in a GitHub repository
- An AWS S3 bucket set up for static website hosting
- AWS configured with GitHub OIDC authentication
- Appropriate IAM roles and permissions
For detailed instructions on setting up OIDC in AWS, refer to the official GitHub documentation.
-
Writing Cross-Divisional Consumable Applications
Creating applications that can be used across different divisions of a company is crucial for efficiency and consistency. Over the past three years, I’ve been working on an application aimed at cross-divisional use.
This experience has shown me critical factors in product adoption. I wish more companies would build their code in a way that other divisions can reuse. Here are key strategies I’ve used to encourage adoption and prevent redundant solutions:
-
In today’s digital world, image recognition and matching have become crucial in various applications. AWS API Gateway, coupled with AWS Rekognition, offers a powerful combination to upload and process images, enabling us to find the closest matches effortlessly. In this article, we will explore how to utilize AWS API Gateway to upload images and leverage Velocity Template Language (VTL) to construct requests for AWS Rekognition to identify the closest image matches.