In this guide, we’ll take you through building a segmented, secure SOHO (Small Office/Home Office) network using Ubiquiti UniFi hardware. The network will be tailored to isolate different types of traffic, set up VLANs for specific use cases, and apply strong firewall rules to protect sensitive data and infrastructure.

While the principles outlined here are generally applicable to most networks, this implementation is specifically designed for UniFi OS version 4.06 and Network Application version 8.4.62.

As Terraform projects grow in complexity, organizing your modules effectively becomes critical to maintaining clean, reusable, and scalable infrastructure code. How you choose to organize these modules can significantly impact collaboration, code reuse, and overall project maintainability. In this blog post, we will explore three primary approaches to organizing Terraform modules: using local modules, storing all modules in one remote repository, and distributing modules across multiple remote repositories. We’ll discuss the benefits and limitations of each approach, with practical examples to help you decide which strategy best suits your needs.

This blog post is a follow-up to our previous post, where we implemented tiered access to S3 data using presigned URLs.

In most production applications, CloudFront is used to serve static content to users. In this post, we will explore how to implement restricted access when serving content through CloudFront.

You can find the complete example here.

What is CloudFront?

In simple terms, CloudFront is a content delivery network (CDN) managed by AWS. A CDN is a network of servers deployed close to end users, serving as a caching layer to improve content delivery speed and reliability.

In this blog post, we will look at how to implement a multi-account deployment pipeline on AWS using GitHub Actions and Terraform.

We will assume that you have access to at least two AWS accounts: one to hold pipeline resources and one target account where resources will be deployed.

Architecture

We will use two accounts: a pipeline account and a target account. The target account is your dev/staging/prod account. Usually, there is more than one target account in a given pipeline, but we will use one for simplicity. The same approach can be extended to an arbitrary number of target accounts.

Managing access to your Amazon S3 data is crucial for ensuring security and efficiency in your cloud architecture. You typically have three options for managing access to S3 data for client applications: using Amazon CloudFront distribution, leveraging S3 presigned URLs, or routing through backend APIs.

In this blog post, we will delve into S3 presigned URLs as an effective method for implementing tiered access to your S3 data. We’ll discuss their benefits, limitations, and provide a straightforward example to illustrate their use.

Security is a major concern in continuous integration (CI), especially when managing sensitive information like API keys, passwords, and other secrets. For Kubernetes resources, Sealed Secrets offer an effective solution for securely managing sensitive information within your repository. In this blog we will explore what are Sealed Secrets, how to use them and some common management tasks around Sealed Secrets.

What are Sealed Secrets?

Sealed Secrets is a set of Kubernetes resources, controller and custom resource definition, that enables secure storage of secrets in your version control system (VCS). Unlike standard Kubernetes Secrets, which are base64-encoded and easily decoded, Sealed Secrets use asymmetric encryption to ensure your secrets remain encrypted until deployed to your Kubernetes cluster. Once deployed, the Sealed Secrets controller decrypts them into regular Kubernetes secrets, making them accessible to your applications.