Look at access management this week and how we can make that either self-service and/or federated/and or any other ideas so we can get some basic blockers out the way - under the ethos of ‘if you can’t access infrastructure, how are you going to do anything else?’

We should look at replicating something similar to Cloud Platform's Costs by Namespace but for costs per application.

We should document and improve our account modelling strategy to share openly and publicly.

We should define a networking strategy for VPCs, DNS, and CIDR ranges to ensure we can automate, monitor and configure application VPCs centrally.

We should write a simple hello world application to deploy as part of onboarding into the Modernisation Platform, and to use within the user guide to explain concepts.

As we're using GitHub as our version control, we should move the infrastructure definitions (repositories, teams, etc) from clickops to Terraform, so we can recreate if needed, but also to be able to configure repositories in the same way easily.

Add a single budget rule to see if this is useful. Can this be done by resource, by account?

What are the notification options? Let's go with the simplest, which is probably an email to our group gmail.

Do we want alerts to go to tenants as well? Should probably keep it to notifications to the platform team at first.

Adding budgets will allow us to be alerted to excessive or unusual usage

This is probably a duplicate of #1897

At MOJ we use a mix of external collaborators and GitHub organisation members to define access to repositories. With the current AWS SSO implementation, we import all organisation members and team affiliations. GitHub external collaborators aren't part of a team, but are part of repositories; so we need to explore options for importing external collaborators and a "team membership" to provide access to AWS accounts.

As part of the new platform requirements we have decided to use Sonarqube as the static code analyser.

Building this solution will require many other components to be decided and in place for this to be completed.

We should look at creating something similar to the Cloud Platform's Orphaned Resources but for non-tagged resources in AWS, so we can find their owner.

Evaluate our resources and member resources vs the guidance - list of non compliant resources. We can then look at the automation / process for reporting on this regularly as a next step.

Ask Craig
Is there something AWS native that will do the job for us?

We want to record our architecture decisions during the design and build of the Modernisation Platform.

We should centrally manage SecurityHub and GuardDuty findings in the core-security account.

We should investigate configuring an ELK stack for the Modernisation Platform to allow us to visualise and centralise logging dashboards that are key to the performance and management of the Modernisation Platform.

We need to create a CI user in the MoJ organisational root account to provision new OUs and new accounts from environment definitions.

We should investigate Terraform workspaces to see if it would benefit us, namely for making it easier to only specify one set of Terraform providers for reuse across accounts rather than generating a provider file for each account.

@davidkelliott and I had a brief discussion about this and it'd be good to investigate this further.

As part of AWS Backup you can specify what databases to backup automatically using an AWS Backup selections. We should always backup databases that are tagged is-production: true.

AWS SecurityHub is enabled via the modernisation-platform-terraform-baselines Terraform module. It uses the AWSServiceRoleForSecurityHub service-linked role. It integrates with AWS Config to configure a standard set of rules.

When SecurityHub assumes the service-linked role, and tries to perform config:GetComplianceDetailsByConfigRule on its own standard set of rules, the resource throws an AccessDenied error. This only happens on the SecurityHub-created rules, not any that are configured manually.

The error it throws is:
User: arn:aws:sts::${accountId}:assumed-role/AWSServiceRoleForSecurityHub/securityhub is not authorized to perform: config:GetComplianceDetailsByConfigRule on resource: securityhub-${rule-name}.

This full error stack is viewable in CloudWatch Logs if you search for AccessDenied.

Time box to 1 day.

The AWS Backup terraform only gets configured in the calling region. We should change this to configure AWS Backup in every region, similar to GuardDuty.

As part of modernisation-platform-terraform-baselines we create CloudWatch Alarms to comply with the CIS AWS Foundations Benchmark security standard.

We should integrate these with Slack channels so they're visible to everyone in the team rather than having to individually subscribe people. We should be able to specify a Slack channel to post these to, so we can reuse it for any accounts configured within the Modernisation Platform.

We should look at using StatusPage, PagerDuty, Pingdom etcetera for service monitoring

We've previously discussed using IAM Federated Access. We've put together a sample implementation using Auth0.

We should record a decision in the ADR.

We should automate terraform init and terraform plan when a PR is opened that changes the GitHub resources as configured in terraform/github. We should add the output as a PR comment so we know what changes are pending if the PR is merged.

To run plan, we need to set a PAT that has the scope for organisation and repository management within the Ministry of Justice organisation on GitHub.

For this, we should use a dedicated GitHub user that is part of the organisation and has the right scope set, as the preset GITHUB_TOKEN in GitHub Actions only has the scope for the repository it is called in.

As our team starts to grow, we should use GitHub releases for self-created modules that we've written, and pin them in versions.tf. This will allow us to work on modules collaboratively rather than currently where it uses the latest commit on the main branch.

It also means we can rearchitect modules and release new major versions if there are breaking changes.

The baseline module currently fails to provision CloudTrail logs because it doesn't wait for the log group to finish being created.

We should utilise AWS Trusted Advisor to provide us with some monitoring for the following, across other AWS services:

• Cost optimisation
• Performance
• Security
• Fault tolerance
• Service limits

Trusted Advisor allows you to refresh metrics via the console and Support API to get up-to-date information. We should look at sending this information to CloudWatch, Slack, etc.

Follow-on from #111, to actually build it and provide an ADR.

As we're growing as a team, we should discuss and decide working principles within the team and document these openly and publicly.

We should build a standardised module to deploy an ALB + several EC2s and anything else required for a "simple" HA application so we can use it as a base for other applications.

We should define what tooling we'll be using for CI/CD and any applicable setup. We've previously talked and thought about:

• GitHub Actions
• CircleCI
• Concourse
  ...and other CI/CD providers.

We also need to think if we're going for a self-hosted approach or not. We should record a decision in the ADR.

We should have an ADR for accessing EC2 instances:

• ssm
• bastion host
• workspaces

We need to decide on the approach of a multi-account management structure.

We've previously spoken about:

• AWS Organisations and organisation accounts
• Landing Zones
• Control Tower
  ...and more.

We should record a decision in the ADR.

We should centrally log all Modernisation Platform managed logs into the core-logging account.

We should update our configuration for our Terraform state s3 bucket to either use the modernisation-platform-terraform-s3-bucket module or to mimic what that automates, such as bucket logging, lifecycle rules and automatic cross-region replication.

We should investigate the possibility of automating our secrets rotation in AWS Secrets Manager. We currently hold two sets of secrets in which both services they're for provide APIs to update tokens.

As a team we've agreed our account structure for core Modernisation Platform services, and we have decided to rename "shared-services-dev" to "sandbox" as part of this.

As a team, we should discuss and decide on whether to use AWS SSO or IAM Federated Access for the Modernisation Platform.

There are currently proposed ADRs for both:

• IAM Federated Access
• AWS SSO

We should report Trusted Advisor findings straight to Kibana.

Following a brief conversation on Slack initiated by @davidkelliott, we should discuss and decide on, if applicable, a preferred coding language for things like GitHub Actions, Lambdas, etc.

Notable information:
Lambda cold startup times from GitConnected:

The Cloud Platform team use Ruby.