Cloud Engineering weeknotes, 3 December 2021

Guest post by one of the team’s engineers

Our second week of the sprint carries on without our delivery manager who is taking some well earned rest. It’s a testament to the trust he has in us that we’ve been left to run our own show and tell and retro without the need for a substitute DM. It’s also a testament to how well the team works that we’re all aware of our roles and what needs to be done.

Account migrations have moved on a little. Advanced e5 was onboarded successfully with assistance from Advanced and the finance team, and GIS apps are being migrated to a dedicated account. The housing staging and production accounts are dependent on some development work being completed. The API accounts are all dependent on resources being migrated to their own accounts and we expect movement on that over the next few weeks.

In Globalprotect we are now looking to set up role-based access so that users can only see “their” applications. So that we can apply additional controls we are looking to implement two entry points (portals) for internal and external applications. As part of the security implementations we have added a set of scripts that enable API application creation, this enables us to restrict access to the management console.

A further security improvement is AWS Federation for GitHub actions, which would allow us to remove some credentials that are currently being stored in the Infrastructure repo. This will also allow for dynamic role assumption based on repo, tag or person running a workflow in the future.

We have started developing Ansible for the various Hackney websites. The idea behind this, is in a similar way to writing Terraform modules, we can start to create Ansible roles that are reusable blocks of configuration. This can then be used to do things like create our custom AMIs, that conform to stricter security standards or have any prerequisite customisations baked in. Additionally, we can use these to actually configure an EC2 after it has been deployed automatically. The intention is to deploy all the various websites and Backstage in this manner, creating a pattern for any other future applications that require hosting on EC2. 

+ posts

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.