Allow ability to create ad-hoc backups on developer role

[richgreen-moj]

User Story

As a MP developer
I want the ability to perform ad-hoc backups via the console
So that I can do this for myself without the intervention of the Mod Platform team

Value / Purpose

The purpose of this ticket is to consider granting the MP Developer role the ability to perform ad-hoc backups in the console.

Currently members need to request it via the #ask-modernisation-platform slack channel. This adds an unnecessary middle-man and delay to performing the task.

MP should consider the impact of making this available and the right level of permissions to grant.

Context / Background

Requested here: https://mojdt.slack.com/archives/C01A7QK5VM1/p1732801669766849

Also likely to have been requested by others in the past.

Useful Contacts

No response

Additional Information

No response

Definition of Done

• Consider permissions required
• Update Developer policy/role as required
• Test using role to create an ad-hoc backup
• Deploy to the role and notify members

[mikereiddigital]

The significant issue is whether to add delete privs and if so, how they are restricted so that the main backups cannot be accessed.

[mikereiddigital]

Checked with @VinceChiuMOJ in the LAA Ops team & can confirm that using the standard developer role in a non-sandbox account, that role already has the necessary permissions to create EBS and RDS snapshots. It does not have permissions to delete those snapshots.

Suggest that no further action is required on this issue.

[richgreen-moj]

Hi @mikereiddigital could you check in with the originator of the request just to make sure they are aware/content? https://mojdt.slack.com/archives/C01A7QK5VM1/p1732801669766849

I think it's fine if it's already available in the developer role.

[mikereiddigital]

Put out a message on the "Update" channel & have contacted Dominic Robinson to check whether it is a different role he needs.

[mikereiddigital]

Spoke with Dominic. The requirement he has is to be able to create ad-hoc AWS Backups, ideally using the AWSBackup role. Currently this is prevented. He stated that it's far more convenient to use the ad-hoc AWS Backup as the wrapper for the backups rather than take them individually. Also he has the need to generate EFS backups using this method.

I will pick this up again tomorrow morning.

[mikereiddigital]

Having done some testing in sprinkler & had a call with AWS, the issue is that the developer SSO permission set being used requires the "IAM:PassRole" permission for the role AWSBackUp as defined here.

For reference - https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html

That role has attached it the AWS Managed role AWSBackupServiceRolePolicyForBackup that a number of permissions that we have not yet granted the developer role, including:

• rds:DeleteDBInstanceAutomatedBackup
• rds:DeleteDBClusterAutomatedBackup
• rds:DeleteDBSnapshot
• ec2:DeleteSnapshot
• ec2:DeregisterImage

etc.

An best approach to limit this would be to restrict its use through the "iam:PassedToService" condition. For example:

  # Additional statement that allows for the creation of on-demand AWS Backups.
  statement {
    sid    = "AllowPassRoleForBackup"
    effect = "Allow"
    actions = ["iam:PassRole"]
    resources = ["arn:aws:iam::${data.aws_caller_identity.current.account_id}:role/AWSBackup"]
    condition {
      test     = "StringEquals"
      variable = "iam:PassedToService"
      values   = ["backup.amazonaws.com"]
    }
  }

Will discuss with colleagues before progressing.

[mikereiddigital]

Spoke with David & confirmed the approach to use iam:PassRole as shown in the above. Tested in sprinkler with that additional statement and the following:

"backup:StartBackupJob"

and I have been able to create ad-hoc backups for efs, ec2 and rds.

I will create a new PR for Monday morning.

[mikereiddigital]

Deployed via PR - #9006.

Will contact Dominic and ask him to test it.

[mikereiddigital]

An issue occured with the approach taken to identify the current account id (using aws_caller_identity) whereby it when applied via the production bootstrap workflow it would pick up the mod platform account id. As a result an alternative was sought. Reusing the local environment_management would result in a low-level terraform exception that is unhandled by the existing plan workflow

Error: -20T15:41:56.544Z [ERROR] AttachSchemaTransformer: No provider config schema available for provider["terraform.io/builtin/terraform"]

https://github.com/ministryofjustice/modernisation-platform/actions/runs/12871455952/job/35884786849?pr=9008#step:7:155

Though when run locally the plan would work and the local correctly referencing the correct accound id.

The solution I've found is the create a new local calling the same secret data resource. This works without error. See https://github.com/ministryofjustice/modernisation-platform/actions/runs/12883276724/job/35917195021?pr=9016#step:7:89

[mikereiddigital]

PR with the new approach. #9027

The error was resolved by removing the existing statement first. Not clear what the underlying issue was though.

[mikereiddigital]

Successfully tested in both cooker & example.

[mikereiddigital]

Posted message on the Update channel. https://mojdt.slack.com/archives/D057KCLN11U/p1737461331343439

[mikereiddigital]

Dominic Robinson has tested and confirmed working.

[SimonPPledger]

As this is a member request and Dominic has confirmed it works then moving to done