feat: Amazon Elastic Container Registry plugin

[blakeromano]

Issue # (if applicable)

Closes #1

Reason for this change

We want to visualize data surrounding ECR images including specifically Image Scan Results

Description of changes

This adds a new ECR plugin for the frontend and backend which results in a new tab in the entity page showing up (if configured with the correct annotation).

Description of how you validated changes

I have run this locally with an AWS account with and without AWS Inspector enabled which both seem to render as expected.

Checklist

• My code adheres to the CONTRIBUTING GUIDE

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[niallthomson]

Thanks @blakeromano its awesome you can contribute this!

With RIV it will take me a little while to spin it up locally to properly check it out. Initially I see some changes we'll want to make for consistency with the other plugins:

1. We create our backend APIs so that it accepts the catalog entity then looks up the relevant annotation(s). This gives us an easy way to inherit access control from RBAC on the catalog entity this belongs to. Example
2. Our annotations right now are generally an ARN or set of tags. We use an ARN because it encapsulates account ID and region and that gives us consistent cross-region and cross-account behavior. I'm fine keeping the name as long as we can get it aligned with the next point.
3. Driving off (2) we'll want to implement the standard resource location pattern that can find AWS resources potentially across multiple accounts and regions. This is largely abstracted in to a common library. Example

[blakeromano]

@niallthomson Thanks for the initial feedback!

I updated it so it is now using the catalog entity and does the lookup that way now RBAC should be respected.

I also updated to use an ARN rather than a name. From my understanding ECR API essentially is based off the registryId (which is the accountID), the region and then the repository name so I'll look more into the resource location pattern from the common library but at least it is using the ARN for now so at least there is alignment on using ARN versus having a one off on the name usage for now.

[fabbazon]

This could end up not returning all the images. Far fetched, but not impossible.

Three things I would suggest:

1 - Make maxResults configurable and make it the maximum number of images that will be fetched
2 - Use a maxBatchSize for each request - possibly configurable? -
3- Iterate getting maxBatchSize entries until you get no nextToken or you reach maxResults

What do you think?

[blakeromano]

I think I agree with you my main thoughts are:

1. How easy do you make it to blow up the UI or by the backend by reading a ton of data into either the server memory?
2. It kind of feels like pagination in the frontend may make the most sense but I think would require a decent amount of rethinking of frontend logic.

I think I'll implement 1 for now as I think to your point that makes the most sense to me and is the easiest to implement.

[niallthomson]

In the CodePipeline plugin we just hard-coded the limit to 100 executions for now.

I'm happy with this also being hard-coded to the same number and we open a different issue to figure out a consistent way to handle configuring these.

[fabbazon]

Use the logger or remove - I guess it's a leftover from debugging?

[blakeromano]

This also is https://github.com/awslabs/backstage-plugins-for-aws/blob/main/plugins/cost-insights/backend/src/service/router.ts#L58 but I do agree I moved it to a debug log with logger

[fabbazon]

It looks good overall, @blakeromano let me know what you think of the comments.

[blakeromano]

@fabbazon Thanks for comments I think I addressed everything you mentioned.

[niallthomson]

Hmmmm, I want this to work with this repo and the example CDK without any modification as all the other examples do.

Think we have two options:

1. Add back in an annotation aws-ecr-repository-name, which doesn't have an equivalent in the other plugins
2. Support tags. The backend code for this is relatively simple because we've abstracted the hard work. The frontend gets annoying because you have to be able to handle potentially getting multiple repositories back.