Gitops

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. ...