Create all required resources in the source and destination modules

[regularfry]

What is the problem this feature will solve?

Currently there are some pre-requisite resources that need to be provisioned before applying the source and destination modules.

in destination:

• kms_key for encrypting the vault

in source:

• bootstrap_kms_key_arn for encrypting the alerts SNS queue
• reports_bucket for dropping reports into

Someone correct me if I'm wrong, but I believe we can include all of those in the modules so they're created on apply, rather than have them passed in as variables. The two keys aren't ones that we want to manage manually, and we ideally want the reports_bucket to be in a predictable place to make #7 tractable.

What is the feature that you are proposing to solve the problem?

Add the above resources to the source and destination modules.

What alternatives have you considered?

It's not clear to me why it makes sense in CSMS to pass these variables in. I'm sure the reasoning is valid in that context, but I think it's worth knowing whether that logic is generally applicable or whether we can lower the barrier to entry here.

Code of Conduct

• I agree to follow this project's Code of Conduct

Sensitive Information Declaration

• I confirm that neither PII/PID nor sensitive data are included in this form

[regularfry]

@danb-csms @andy-melvin-nhs @Joe-Gadd can you shed any light on the reasoning? I may well have missed a subtlety here, especially with the vault key.

[Joe-Gadd]

it's mainly because we have a standard pattern of approaching each resource which allows us to have a standard security and cost pattern for all reusable resources so, for example with the reports bucket we have an S3 module that creates a locked down and life-cycled bucket that we pass in to this module as the bucket to use.

For the KMS key it's just down to our pattern of creating a master key in all our accounts for broad use within that account and so we share the key between things.

[Joe-Gadd]

The KMS key thing is kinda similar in that we have a standard approach such as permissions for our account set around that key in a way to secure it's use but we don't have a module for that for historical reasons and we don't reuse it in code much

[regularfry]

Ah hah, ok. I was worried that there might be something fiddly in vault restoration depending on which key gets used where for cross-account backups, depending on the service. The docs are making my eyes glaze over, I need to see it actually work.

As far as you're concerned would there be a reason not to add the reports bucket config in this repo? If the constraints you've got in your S3 bucket config are reasonably sane I can't see a reason not to extract that too.