Use OIDC to securely connect CircleCI to AWS

[eternaltyro]

This PR introduces OpenID Connect for CircleCI to access AWS. Only jobs running inside a context can fetch AWS credentials. AWS provides temporary (30 min) access tokens for CircleCI to use for running AWS API ops.

Note:

1. The duration of access token validity can be increased later if necessary
2. The permissions associated with the ephemeral tokens are defined in the IAM role specified in config.yml. If more permissions are needed, we can of course add them to the IAM role

Benefits:

This obsoletes the need to specify an AWS key pair - risking them to exposure. This is a security measure primarily and to an extent a convenience measure to ease-up improvements to CircleCI config later.

[Aadesh-Baral]

I went through the PR, and I have a few questions.

1. What is frontend-modern job used for?
2. In frontend and backend deploy jobs, what function does the frontend-modern job play?
3. I saw that frontend-modern was using a cimg/node:lts image, and I believe that the TM frontend build is not successful in node >=18.

[eternaltyro]

Thanks for the review, @Aadesh-Baral

1. What is frontend-modern job used for?

It's an experimental job I used to play around with different settings. I will remove it in a subsequent commit. But for now it stays because I can work with CircleCI without clobbering on others' work.

2. In frontend and backend deploy jobs, what function does the frontend-modern job play?

Doesn't play any role. It's an independent workflow.

3. I saw that frontend-modern was using a cimg/node:lts image, and I believe that the TM frontend build is not successful in node >=18.

This is a discussion for later. But we need to get TM frontend to work with LTS releases as we move forward. I can switch the version to cimg/node:14.21 if my experiments fail.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[eternaltyro]

Related to #5539

[dakotabenjamin]

@eternaltyro is this still relevant to review?

[eternaltyro]

@dakotabenjamin yes, please. I will resolve the conflicts, but for now, can you review for any pitfalls and things like that?

[eternaltyro]

@dakotabenjamin I have resolved the conflicts. Please review once. If all is good, I'll merge this and then move on to improving the syntax further.

[dakotabenjamin]

I love how we have separated out the jobs in this new workflow. LGTM, but I have a question: will splitting out some of these jobs into separate containers significantly increase overall runtime or storage capacity? Since they have different base images

[eternaltyro]

will splitting out some of these jobs into separate containers significantly increase overall runtime or storage capacity? Since they have different base images

@dakotabenjamin Those different tests don't save anything to cache. I don't think there will be a significant increase in project storage usage through saved caches.

Re: Runtime - it actually reduces the runtime because the tests are parallelised. There is no change in overall runtime since the build flows are dependent on the test flows and it is all sequential. I have ideas to shorten that too. I will increase the OIDC key lifetime to 45min in the interim.

Do you think this PR is good to be merged?

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information