Jhuk Tech News

My blog runs as a static S3 origin behind CloudFront, deployed by Terraform and GitHub Actions. The edge was producing access logs, but they were sitting inert in object storage. I could not yet answer questions and produce intelligence like: Who is requesting what? Why are certain clients requesting paths or filenames that result in 403 or 404? How often does CloudFront serve from cache versus reaching back to S3?

I wired up a GitHub Actions pipeline that runs terraform plan in the PR prior to merge. However before Terraform can pull the reality state of my existing AWS infrastructure to compare against terraform.tfstate and declarative *.tf files, the CI pipeline first needs to assume a properly scoped AWS IAM role. The mechanism for this depends on OIDC federation. This post walks through the technical procedure of issuing an OIDC token from the .yml pipeline, how the AWS IAM console is used to define authorization parameters, and finally how the CI pipeline uses those temporary AWS credentials to complete its Terraform job.

While cleaning up the CloudFront configuration for this blog, I removed a www.jhuk.tech → jhuk.tech 301 redirect that I assumed was redundant. My reasoning was simple: if both hostnames point at the same CloudFront distribution and the same S3 bucket, then both should serve the same site. Why force a redirect at all?

After deploying the change, I noticed something strange. The apex domain https://jhuk.tech rendered perfectly, but https://www.jhuk.tech returned the same page as a wall of unstyled HTML — no theme, no layout, no JavaScript. Two URLs, the same bytes on the server, two completely different experiences in the browser. This post is a breakdown of why that happened and the tradeoffs I weighed before settling on a fix.

For years, I used a managed WordPress instance behind a cPanel host to write this blog. Initially it was a great way to learn. I was able to abstract away hosting-as-a-service. But Wordpress exposes an administrative login page and my comments section was open to the public internet which resulted in many cybersecurity issues such as brute-force authentication and botnets posting XSS payloads and gambling links. As my interests grew farther into cloud and DevOps, I wanted my own site to reflect the way I now think about infrastructure—version-controlled, reproducible, and declarative in nature.

In the field of Cybersecurity and DevOps, there is no substitute for hands-on experience with cloud infrastructure. To further my own practice, I have recently started diving into the Microsoft Azure ecosystem. It’s an excellent sandbox for learning with $100 in credits and 750 hours of B1s compute, you have exactly what you need to keep a single VM instance running 24/7 while you experiment.

For this project, I set out to deploy a custom Nginx web server on a Linux VM. Here is a breakdown of the configuration and the logic behind my deployment.