Added ECR pull-through configuration

[amarin-dspace]

As the title says, this will create ECR rule to set up pull-through cache in your private ECR registry.
It includes necessary credentals' secret, IAM policy and the pull-through rule itself.
The creation of resources is controlled through object variable.

Actual functionality from EKS cluster (ie IAM permissions, usage of images from upstream repository in cluster) is tested.

Terraform v1.9.4
on windows_amd64

• provider registry.terraform.io/gavinbunney/kubectl v1.14.0
• provider registry.terraform.io/hashicorp/aws v5.37.0
• provider registry.terraform.io/hashicorp/cloudinit v2.3.4
• provider registry.terraform.io/hashicorp/helm v2.13.2
• provider registry.terraform.io/hashicorp/http v3.4.3
• provider registry.terraform.io/hashicorp/kubernetes v2.30.0
• provider registry.terraform.io/hashicorp/local v2.5.1
• provider registry.terraform.io/hashicorp/null v3.2.2
• provider registry.terraform.io/hashicorp/random v3.6.2
• provider registry.terraform.io/hashicorp/time v0.11.2
• provider registry.terraform.io/hashicorp/tls v4.0.5
• provider registry.terraform.io/terraform-aws-modules/http v2.4.1

[lukabudak]

Why don't you be more specific and inside the map use an object instead of random combination of string key value pairs?
I take it we'll always expect username and accessToken for registry_credentials.
Therefore, it'd be in our best interest to use a defined object like so.

[amarin-dspace]

For this particular registry, this could be considered an overkill, since it does not require any authentication at all.
Generally, yes, it's always username and accessToken, but there's discussion below with SimonG to have this hardcoded instead, for this particular registry...

[amarin-dspace]

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/secretsmanager_secret_version#key-value-pairs

[lukabudak]

If registry_credentials variable is agreed upon, I would urge that you map an object to the proposed attributes in order to prevent the injection of any unexpected/harmful key-value pairs.

[amarin-dspace]

Agreements can be re-agreed 😈
In any case, this was copied from upstream, I understand there is possibility for end user to inject unwanted kv pair(s), but what you propose is just a measure to prevent end-user shooting themselves in the foot (they should do it simply, c/p what is already there and put correct values).
Waiting for response from SimonG (below; it's connected to your input as well, because he wants it hard-coded).

[lukabudak]

LGTM
@sgrdn could you also leave a review