Amazon ECRリポジトリのライフサイクルポリシー設定について

2025.09.05

このブログシリーズ「クラウドセキュリティ実践集」では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか？」というリスクの解説から、「どうやって直すのか？」という具体的な修復手順（コンソール、AWS CLI、Terraformなど）まで、分かりやすく解説します。

この記事では、Amazon ECRリポジトリのライフサイクルポリシー設定について、リスクと対策を解説します。

ポリシーの説明

すべてのAmazon ECR（Elastic Container Registry）リポジトリにライフサイクルポリシーを設定し、コンテナイメージの自動管理を実装する必要があります。これにより、未使用イメージの自動削除、古いイメージのクリーンアップ、脆弱性を含む可能性のあるイメージの排除が可能になります。ライフサイクルポリシーは、タグの有無、プッシュ日時、イメージ数などの基準に基づいて設定し、組織のデプロイメントパイプラインとセキュリティ要件に合わせて定期的に見直してください。

修復方法

コンソールでの修復手順

AWSのコンソールを使用して、Amazon ECRリポジトリにライフサイクルポリシーを設定します。

AWSコンソールにログインし、「Amazon ECR」サービスに移動します。
左側のナビゲーションペインで「プライベートレジストリ」→「リポジトリ」を選択します。
ライフサイクルポリシーを設定したいリポジトリの名前をクリックします。
リポジトリの詳細ページで「ライフサイクルポリシー」タブを選択します。

「ライフサイクルルールを作成」または「編集」ボタンをクリックします。
「ルールを追加」をクリックして、以下の設定を行います：
- ルールの説明: わかりやすい説明を入力（例：「7日以上経過したタグなしイメージを削除」）
- ルールの優先度: 1から開始（数字が小さいほど優先度が高い）
- ルールのスコープ: 「タグのステータス」を選択
- 一致条件: 適切な条件を設定
必要に応じて複数のルールを追加します。
「プレビュー」をクリックして、ポリシーの影響を確認します。
「保存」をクリックしてポリシーを適用します。

Terraformでの修復手順

Amazon ECRリポジトリにライフサイクルポリシーを設定するためのTerraformサンプルコードです。aws_ecr_lifecycle_policy リソースで適切なライフサイクルポリシーを設定するようにしましょう。

# ECRリポジトリの作成
resource "aws_ecr_repository" "application" {
  name                 = var.repository_name
  image_tag_mutability = "MUTABLE"

  image_scanning_configuration {
    scan_on_push = true
  }

  encryption_configuration {
    encryption_type = "KMS"
    kms_key        = var.kms_key_arn
  }

  tags = {
    Name        = var.repository_name
    Environment = var.environment
    ManagedBy   = "Terraform"
  }
}

# ECRライフサイクルポリシーの設定
resource "aws_ecr_lifecycle_policy" "application_lifecycle" {
  repository = aws_ecr_repository.application.name

  policy = jsonencode({
    rules = [
      {
        rulePriority = 1
        description  = "Delete untagged images after ${var.untagged_image_expiry_days} days"
        selection = {
          tagStatus   = "untagged"
          countType   = "sinceImagePushed"
          countUnit   = "days"
          countNumber = var.untagged_image_expiry_days
        }
        action = {
          type = "expire"
        }
      },
      {
        rulePriority = 2
        description  = "Keep only ${var.production_image_count} production images"
        selection = {
          tagStatus     = "tagged"
          tagPrefixList = var.production_tag_prefixes
          countType     = "imageCountMoreThan"
          countNumber   = var.production_image_count
        }
        action = {
          type = "expire"
        }
      },
      {
        rulePriority = 3
        description  = "Keep only ${var.staging_image_count} staging images"
        selection = {
          tagStatus     = "tagged"
          tagPrefixList = var.staging_tag_prefixes
          countType     = "imageCountMoreThan"
          countNumber   = var.staging_image_count
        }
        action = {
          type = "expire"
        }
      },
      {
        rulePriority = 4
        description  = "Keep only ${var.development_image_count} development images"
        selection = {
          tagStatus     = "tagged"
          tagPrefixList = var.development_tag_prefixes
          countType     = "imageCountMoreThan"
          countNumber   = var.development_image_count
        }
        action = {
          type = "expire"
        }
      },
      {
        rulePriority = 5
        description  = "Delete all images older than ${var.max_image_age_days} days"
        selection = {
          tagStatus   = "any"
          countType   = "sinceImagePushed"
          countUnit   = "days"
          countNumber = var.max_image_age_days
        }
        action = {
          type = "expire"
        }
      }
    ]
  })
}

ベストプラクティス

環境別のタグ戦略
- 本番環境: prod-v1.2.3 形式で明確なバージョニング
- ステージング環境: stage-YYYYMMDD 形式で日付管理
- 開発環境: dev-feature-name 形式で機能別管理
段階的なポリシー適用
- まずプレビューモードで影響を確認
- 開発環境から段階的に適用
- 本番環境への適用は慎重に実施
監視とアラート
- CloudWatchでリポジトリサイズを監視
- 異常な削除が発生した場合のアラート設定
- 定期的なポリシー効果のレビュー
バックアップ戦略
- 重要なイメージは別リージョンにレプリケーション
- タグ付けによる重要イメージの保護
- 削除前の確認プロセスの確立