DEV Community: Kazuya.Y

Automatically Committing Image Tags with Argo CD Image Updater

Kazuya.Y — Sat, 21 Mar 2026 12:44:45 +0000

In GitOps workflows using Argo CD, automating container image updates is essential.

In this article, we will walk through how to set up Argo CD Image Updater in practice based on the following assumptions.

Prerequisites

Argo CD is already installed
Argo CD is connected to GitHub
Kubernetes is running on EKS
The container registry is ECR

What is Argo CD Image Updater?

Argo CD Image Updater

Periodically scans kustomization.yaml or Helm values.yaml in registered repositories
Retrieves the latest tags from container registries (e.g., ECR, Docker Hub)
Compares them with the currently deployed image tags
If there is a difference, automatically commits the change (or creates a PR) to GitHub
Argo CD detects the change and performs a rolling update of the Deployment

Deployment Flow: Argo CD Image Updater × Argo CD

Directory Structure

First, create a Kustomize-based structure:

ops/kubernetes/eks/argocd-image-updater/
├── base/
└── overlays/
    └── stg/

Steps

① Setting up IAM Role and Pod Identity

② Install Image Updater using Helm Deploy it via Helm from Kustomize.

# ops/kubernetes/eks/argocd-image-updater/overlays/stg/kustomization.yaml

helmCharts:
  - name: argocd-image-updater
    repo: https://argoproj.github.io/argo-helm
    version: 0.12.1
    releaseName: argocd-image-updater
    namespace: argocd
    valuesFile: values.yaml

③ Configure values.yaml

config:
  logLevel: "info"

  registries:
    - name: ECR
      api_url: https://xxx.dkr.ecr.ap-northeast-1.amazonaws.com
      prefix: xxx.dkr.ecr.ap-northeast-1.amazonaws.com
      insecure: false
      credentials: ext:/scripts/ecr-login.sh

  git:
    writeBranch: develop
    commitMessageTemplate: "chore: update image tag to {{ .NewTag }}"
    authorName: "Argo CD Image Updater"
    authorEmail: "<your-email>"
    addSignature: false

argocd:
  config:
    enabled: true

rbac:
  create: true

serviceAccount:
  create: false
  name: argocd-image-updater-sa

authScripts:
  enabled: true
  scripts:
    ecr-login.sh: |
      #!/bin/sh
      aws ecr --region "ap-northeast-1" get-authorization-token \
        --output text \
        --query 'authorizationData[].authorizationToken' \
      | base64 -d

Key Point

credentials: ext:/scripts/ecr-login.sh

ECR does not use static credentials like Docker Hub
→ You must retrieve a temporary token each time
→ Use a script to fetch the token and pass it to Image Updater

④ Add Annotations to the Application
Image Updater works based on annotations.(v0.x)

metadata:
  annotations:
    argocd-image-updater.argoproj.io/write-back-method: git
    argocd-image-updater.argoproj.io/write-back-target: "kustomization:/ops/kubernetes/eks/service/overlays/stg"

    argocd-image-updater.argoproj.io/image-list: >
      app-image=xxx.dkr.ecr.ap-northeast-1.amazonaws.com/service-stg

    argocd-image-updater.argoproj.io/app-image.update-strategy: newest-build
    argocd-image-updater.argoproj.io/app-image.kustomize.image-name: app-image

⑤ Verification Push a new image to ECR.

If you see logs like the following in:

argocd-image-updater > Pod details > Logs

then the setup is successful.

How a Misconfigured CloudFront Cache Can Lead to Personal Data Leaks - Understanding and Securing API Caching

Kazuya.Y — Sun, 26 Oct 2025 04:20:04 +0000

Introduction

When using CloudFront, many developers tend to choose the default cache policy Managed-CachingOptimized.

However, applying this policy to APIs without fully understanding how it works can lead to serious personal data leaks and other security incidents.

What is a Cache Key

By default, CloudFront creates caches based on the request path.

In other words, the request path acts as the cache key.

Example: Image Requests

User A accesses /images/icon_1.png
→ CloudFront retrives the object from the origin (e.g., S3) and caches it.
User B accesses /images/icon_1.png
→ CloudFront returns the cached content (without accessing the origin).
User C accesses /images/icon_2.png
→ CloudFront fetches the new object from the origin and creates the new cache.

In short, CloudFront treats the request path as the cache key.

Example of the Incident

In 2021, a serious incident occurred at Klarna, a payment service provider based in Sweden.

Reference: Klarna Detailed Incident Report – Incorrect Cache Configuration

Here is what happened:

The CDN cached API responses intended for authenticated users, as a result, personal data was displayed to other users.

In other words, the response meant for user A was service to user B.

Why It Happened

The root cause was that CloudFront's cache key strategy was based solely on the request path.

Even if an API had a endpoint like /profile and returned responses for each logged-in user, CloudFront would interpret all those requests as the same path.

User A → /profile → Response A (cached)  
User B → /profile → CloudFront: “Same path!” → Response A returned

As a result, all users received the personal data of the first user who accessed the endpoint, which led to a serious information leak.

Countermeasures

Countermeasure 1. Disable Caching on the CloudFront Side

You can prevent API responses from being cached by setting the CloudFront cache policy to CachingDisabled.

Countermeasure 2. Set Cache-Control Headers on the Backend

To add an additional layer of protection at the application level, include this following headers in your API responses:

Cache-Control: private, no-cache, no-store, must-revalidate  
Pragma: no-cache  
Expires: 0

These headers ensure that:

CDNs and browsers do not cache the responses
The origin server is always revalidated before reuse

As a result, CloudFront and other intermediaries are forced to fetch a fresh response each time.

Countermeasure 3. Completely Separete Static Content and APIs

By hosting static content and APIs on different domains, you can prevent cache configurations from interfering with each other.

# For static content  
static.example.com → CloudFront → S3 (caching enabled)  

# For APIs  
api.example.com → ALB / API Gateway → Backend (caching disabled)

In this setup, the communication bacomes cross-origin, therefore you need to configure CORS on the API side.

Conclusion

Cashing on the API side can be useful, but it is also extremely dangerous.

For APIs that return data for authenticated users, you should completely disable caching.

If you need to use caching, leverage Redis or Memcached inside your application, and make sure no personal data is stored in the CDN edge cache.

Implementing Graceful Shutdown in Go

Kazuya.Y — Sat, 18 Oct 2025 15:37:41 +0000

Background

💎 This example demonstrates how to implement graceful shutdown for an asynchronous process that handles heavy email devivery tasks using SQS.

💎 In the case of an HTTP server, you can simply rely on the standard library Server.Shutdown() method to safely stop the server. However, since this is an asynchronous queue processor (not an HTTP server), we can't use that mechanism - so we need to implement graceful shutdown manually.

Why graceful shutdown is necessary

When a container is terminated, we want to ensure that some ongoing processes finish properly before the container actually stops.

SQS workers offen execute logn-running jobs. Some may takes several minutes, even close to 1 hour.

Without graceful shutdown, if a deployment happens while a worker is still processing a message, the process might be killed in the middle of the execution.

How to implement

We can handle graceful shutdown by responding to system signals.

SIGTERM - sent when the container is terminated (e.g., during a deployment)
SIGINT - sent when the process is manually stopped (e.g., Ctrl+C) If you consider to handle these signals, you can ensure that no matter when a deployment happens, the process is always wait for all ongoing tasks to finish before exiting — allowing the system to shud down safely and gracefully.

Example Implementation

I will show the flows and code below.🚀

Startup
 ↓ 
Create SQS session
 ↓
ReceiveMessage in a for loop
 ↓
Process each message in a goroutine
 ↓
SIGINT / SIGTERM received → ctx.Cancel()
 ↓
Exit loop & wait for all wg to finish
 ↓
Log output and perform graceful shutdown

// main.go
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)

ctx, cancel := context.WithCancel(context.Background())
defer cancel()

var wg sync.WaitGroup

// Listen for signals in the goroutine
go func() {
　<-sigChan
　cancel()

　wg.Wait()

　os.Exit(0)
}()

// Initialize AWS session
session, err := session.NewSession(&aws.Config{
　Region: aws.String("your-region"),
})
if err != nil {
　return errors.Wrap(err, "session.NewSession")
}
client := sqs.New(session)

// Define SQS receive message configuration
receiveMessageInput := &sqs.ReceiveMessageInput{
　QueueUrl: xxx,
　MaxNumberOfMessages: yyy
　MessageAttributeNames: zzz
}

for {
　select {
　case <-ctx.Done():
　　// Exit the loop if context is cancelled
　　return nil
　default:
　　result, err := client.ReceiveMessage(receiveMessageInput)
　　if err != nil {
　　　time.Sleep(1 * time.Second) // Retry after a short delay
　　　continue
  　}
　　if len(result.Messages) == 0 {
   　continue
  　}

　　for _, message := range result.Messages {
　　　wg.Add(1)
     go func(msg *sqs.Message) {
     // Process received messages
   　}(message)
　　}
　}
}