Posts

Introduction In my previous blog post I covered deploying Helm Charts from OCI registries. Today, I’d like to focus on ECR specifically and share an approach for managing access to ECR for ArgoCD in a secure and fully automated manner. Problem description For ArgoCD to access Helm charts from a private OCI registry, a set of credentials must be defined as a Kubernetes Secret object, similar to the following: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 apiVersion: v1 kind: Secret metadata: name: private-ecr-repo namespace: argocd labels: argocd.argoproj.io/secret-type: repository stringData: url: 1234567890.dkr.ecr.eu-central-1.amazonaws.com name: private-ecr type: helm enableOCI: "true" username: AWS password: <placeholder-for-aws-ecr-token> AWS credentials can be exchanged for an ECR token, for example by running aws ecr get-login-password. The challenge is that such a token is only valid for 12 hours. It can be tackled by issuing a token and updating the Secret periodically, before the token expires. ...

Introduction In this blog post, I’ll demonstrate two methods for deploying Helm charts stored in an OCI registry using ArgoCD. For this demonstration, I’m using a Kind cluster, but the process is the same regardless of your Kubernetes environment. Before OCI support, Helm charts were typically stored in custom chart repositories (ChartMuseum, Nexus, Artifactory) or in Git repositories. OCI registries have become a popular way to store and distribute Helm charts, providing a standardized approach similar to container images. Helm added experimental support for OCI registries in v3, and it became generally available in Helm 3.8.0. It’s a very convenient solution for organizations already leveraging container registries, as they already have what’s needed for storing their charts. ...

Introduction and motivation Terraform has been the most widely adopted tool for managing cloud infrastructure for a while now, and managing EKS is no exception. The majority of companies I’ve talked to use it. However, I’ve noticed that many are at least exploring alternatives, especially in the context of managing EKS - and there are valid reasons for that. Most of the time when you’re interacting with Kubernetes, you do so declaratively: you define the desired state (resource manifests) and rely on various controllers to update the “world” to match what’s defined. This approach is typically used to manage app configuration, deployments, networking, secrets, and more. However, when it comes to cluster configuration or application dependencies, it quickly falls short, and people resort back to good-old Terraform. Many will continue using Terraform whenever they deal with AWS API and only use Kubernetes for what “originally” belongs there. Some will identify bottlenecks and seek alternatives to improve operational efficiency or solve other problems. ...

Preface I ran a bunch of tools to check if my blog is SEO-friendly. One of the recommendation was to canonicalize the URLs by avoiding multiple addresses pointing to the same page. In my case, that was serving my website at both https://www.simonko.dev, as well as https://simonko.dev. The solution is rather simple - redirect www to non-www. My website is fully configured using Terraform. Since I’ve never done it before with Cloudflare Terraform provider, I thought I might share what I did. ...

Introduction One of the supported runtimes for AWS Lambda is containers. AWS offers a set of base images with a Lambda Interface Client built-in, which is required to run your code in the context of AWS Lambda. The actual usage varies depending on your language of choice. The Runtime Interface Client (RIC) is available as a library that you either call directly in your application’s entrypoint (in case of Go), or you use the provided entrypoint and pass a name to your handler, which is the case for Python or NodeJS. ...

Introduction Since its introduction, AWS Lambda’s supported runtimes have continually expanded. Around 2020, support for containerized Lambdas was added. In this post, I’ll walk you through the permissions needed for running Lambdas with images stored in ECR. We’ll look at these scenarios: Lambda and ECR repository in the same account Lambda and ECR in different accounts Multi-account setup with AWS Organizations I’ll be strictly focusing on the permissions. In my opinion, the official AWS Documentation covers the process of building container images for Lambdas really well, but it is somewhat scarce on the necessary permissions. Regardless, here’s a link to the official documentation on the permissions aspect. ...

Introduction The control plane is a set of components that together form the management layer of Kubernetes. These components manage the cluster’s state, coordinate between nodes, and provide APIs for interacting with the cluster. The security of this API component, known as the API Server, is the focus of today’s post. Ensuring the security of the API Server is critical because it serves as the interface to your cluster. It is used by both users and automation tools to interact with the cluster. Whether it’s kubectl, Helm, ArgoCD, or any other tool, they all communicate with the cluster via the API. Unauthorized access can lead to a complete or partial cluster compromise, data breaches, or service disruptions. ...

Preface In my previous post, I shared the steps I followed to set up a blog and promised to automate the Cloudflare setup. My goal was to automate as much as possible, minimize manual steps and establish a repeatable process, so I started exploring the use of Infrastructure as Code (IaC) for Cloudflare configuration. I reached a point where everything is automated except for: Domain purchase Terraform state storage (Cloudflare R2) Linking Cloudflare and GitHub accounts Cloudflare access tokens This is acceptable since these are one-off activities. Now, I can destroy and recreate my Cloudflare setup in just a few seconds. ...

Preface I started writing this post while my blog wasn’t yet published. The idea of setting up a blog has been developing in me for a while now. Over the past few weeks I’ve gone through several posts on the topic on Reddit to, confronted the plan with my wife, as well as with Google Gemini and reached a point where I just needed to start doing. I’ve bought the domain via Cloudflare and started setting up the blog locally. I am not a graphics designer or a frontend developer and I didn’t want to spend too much time maintaining that. I wanted to focus on content and wanted to do it as cheap as possible, with least maintenance burden, as well as not need to worry about the security of underlying infrastructure. A statically generated website hosted somewhere sounded perfect. I settled on Cloudflare Pages, but there’s plethora of options available: AWS Amplify, Netlify, Github Pages. Having the content of my website version controlled along the rest of the code sounded appealing to me as well. ...