Repol

ECR Repository Policies

Manage ECR repository policies with a diffable Ruby DSL

Manages: Amazon ECR Repository Policies
Language: Ruby
Package: repol
CLI: repol
Config file: Repolfile

The repol repository is archived on GitHub with no activity since 2016, so treat it strictly as a legacy audit tool and prefer Terraform for new ECR policy management.

Repolfile

require 'other/repolfile'

repository "my_ecr_repo" do
  {"Version"=>"2008-10-17",
   "Statement"=>
    [{"Sid"=>"PullOnly",
      "Effect"=>"Allow",
      "Principal"=>{"AWS"=>"arn:aws:iam::123456789012:root"},
      "Action"=>
       ["ecr:BatchCheckLayerAvailability",
        "ecr:BatchGetImage",
        "ecr:GetDownloadUrlForLayer"]}]}
end

In short

Repol is a Ruby command-line tool that manages Amazon ECR repository policies as code. It exports the policies on your container image repositories into one file called a Repolfile. You review each change in Git, dry-run it, then apply it idempotently.

What is Repol?

Repol is a Ruby command-line tool in the codenize-tools family. It manages ECR repository policies as code. It exports the resource policies on your container image repositories into one file, then applies your edits back. This is the standard codenization loop: export, review, dry-run, apply.

An ECR repository policy decides who can pull and push your images. The grants usually go to:

Other AWS accounts that share your images.
CI systems that push new builds.
ECS or EKS tasks in sibling environments that pull to run.

Teams add these grants one console edit at a time, then forget them. That is a real problem, because those images are what runs in production.

Repol turns that access config into a text file with history. Every new principal or action becomes a reviewable diff. It is the container-registry sibling of Bukelatta for S3 bucket policies, and it sits next to Miam on the identity side of AWS access control.

Key facts

Manages ECR repository policies, the grants that let accounts pull and push images.
One export writes every repository policy into a Repolfile.
Policies are Ruby hashes, so a standard pull-only grant can be defined once and reused.
A dry-run shows the statement changes first; the apply is idempotent.
Pairs with Miam for the IAM identities on the other side of access.
It is the oldest archived codenize tool, untouched since 2016.

Illustration: Amazon ECR Repository Policies managed as code with Repol

Getting started

Install and run Repol

Install

Install the repol gem (Ruby required).

$ gem install repol

Export current state

Pull the live ECR Repository Policies configuration into a Repolfile.

$ repol -e -o Repolfile

Dry-run, then apply

Preview the diff, then apply the change for real.

$ repol -a --dry-run

Repol runs the export, review, apply loop. Export the live state once in export mode (the -e flag) and commit it. That file now records exactly which principals can pull or push each container repository.

To grant a new account pull access, or to tighten an over-broad statement, edit the Repolfile in a branch and run the apply with --dry-run. The dry-run prints the exact policy change per repository, which makes the pull request self-evident. After merge, apply for real; the apply is idempotent. Registry grants tend to be added in a hurry when a new environment needs images, so a scheduled dry-run is worth setting up as drift detection: any console-added grant appears as a diff to codify or revoke.

Pro tip

Build the canonical pull-only statement in a Ruby helper and reuse it for every consumer account. No repository can then grant push access by accident.

Capabilities

What Repol can do

Policies as Ruby data

Each repository block returns its policy as a Ruby hash. A shared statement, like a pull-only grant for a CI account, can be defined once and reused.

One-command export

Export mode writes the current policy of every ECR repository into the DSL. You get a complete inventory of who can pull and push images.

Dry-run diffs before apply

The dry-run prints the statements that would change on each repository without touching ECR. Access changes get verified in review and in CI.

Idempotent apply

The apply only calls the API where the declared policy differs from the live one. Re-running after a partial failure is safe.

Targeted and split operation

The --target regex scopes a run to matching repository names. The --split option exports one file per repository, keeping ownership clean.

Composable files via require

A Repolfile can require other files. A base policy library and per-team policy files can be combined into one apply.

In practice

When teams reach for Repol

Cross-account image sharing

Letting a staging or partner account pull images is the most common reason to touch an ECR policy. With Repol the grant is a small diff naming the exact account and ecr actions, recorded in Git history.

Audit who can access your images

A single export gives you a greppable file of every repository policy. Finding stale grants, like old vendor accounts or decommissioned CI roles, becomes a text search instead of a console expedition.

Standardize pull-only policies

Because the DSL is Ruby, a helper can generate the read-only statement for every consumer account. That keeps push access from slipping into a repository by mistake.

FAQ

Repol questions, answered

Does Repol create or delete ECR repositories?

No. It manages only the resource policies attached to existing repositories. Repository creation, lifecycle policies, and image scanning settings are outside its scope.

What is the Repolfile?

It is Repol's Ruby DSL file. Each repository block contains the policy document as a Ruby hash, and a file can require other files so common statements are written once.

How does Repol handle large registries?

Use --split to export one file per repository, --target to scope runs by name with a regex, and --request-concurrency to run API calls in parallel across many repositories.

Is Repol still maintained?

No. The repository is archived, with no activity since 2016, making it the oldest of the archived codenize tools. It still works as an export and audit utility. For ongoing management, use Terraform's aws_ecr_repository_policy resource or CloudFormation.