goharbor/harbor

Harbor ECR replication : ECR Cross-Account Replication Cannot Create Repository & Cannot Assume Cross-Account Role

クローズ

#22,858 opened on 2026/02/19

 (3 件のコメント) (0 件のリアクション) (0 人の担当者)Go (5,235 件のフォーク)batch import
Stalehelp wantedreplication/adapters

Repository metrics

Stars
 (28,490 個のスター)
PR merge metrics
 (平均マージ 8d 17h) (30d で 74 merged PRs)

説明

When using Harbor to replicate images to AWS ECR across accounts, i’m seeing the following limitations:

1️⃣ Repository Must Pre-Exist

If the target ECR repository does not already exist, replication fails.

Even when the Harbor pod is running with an IAM role (via IRSA / Pod Identity), Harbor does not create the repository in the target account. The repository must be manually or externally provisioned (e.g., Terraform).

Expected behavior: • If IAM permissions allow ecr:CreateRepository, Harbor should automatically create the target repository during replication.

Current workaround: • Pre-create the repository in the target account. • Apply a repository policy allowing ecr:PutImage from the source account role. • This allows pushing images, but still requires manual repo creation.

2️⃣ Cannot Assume Cross-Account Role

I am able to configure Harbor to use the pod’s IAM role (via IRSA), but Harbor does not appear to support assuming a role in another AWS account for replication.

As a result: • I cannot use sts:AssumeRole into the target account. • I must instead rely on ECR repository policies in the target account. • Even then, repository creation is still not possible cross-account.

Question: Is this limitation due to how the AWS SDK is implemented in Harbor’s ECR driver (i.e., no STS role assumption flow)?

Expected Improvements • Support cross-account AssumeRole for ECR replication. • Allow repository auto-creation when IAM permissions allow. • Native support for IRSA / Pod Identity without static access keys.

This would significantly improve Harbor’s usability in multi-account AWS environments following IAM best practices.

コントリビューターガイド