Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Storage accounts should use infrastructure encryption #4001

Open
2 tasks
SvenAelterman opened this issue Jun 23, 2024 · 4 comments · May be fixed by #4139
Open
2 tasks

Storage accounts should use infrastructure encryption #4001

SvenAelterman opened this issue Jun 23, 2024 · 4 comments · May be fixed by #4139
Labels
breaking-change PR contains a breaking change that needs to be highlighted or documented story Stories are the smallest unit of work to be done for a project.

Comments

@SvenAelterman
Copy link
Collaborator

Description

As a TRE Administrator
I want to deploy TRE in a manner compliant with common regulatory frameworks, like NIST SP 800-171 R2 and Microsoft's built-in compliance initiatives for those frameworks
So that research takes place in a compliant environment

Acceptance criteria

  • New TRE deployments' storage accounts use infrastructure encryption
  • Existing TRE deployments are not modified

Notes

Existing storage accounts cannot be updated to support infrastructure encryption. A feature flag at the core TRE level might be required so that existing storage accounts aren't attempted to be upgraded. Perhaps this could also be accomplished with Terraform ignore statements, but I don't know those very well.

@SvenAelterman SvenAelterman added story Stories are the smallest unit of work to be done for a project. breaking-change PR contains a breaking change that needs to be highlighted or documented labels Jun 23, 2024
@jonnyry
Copy link
Contributor

jonnyry commented Nov 13, 2024

Hi @SvenAelterman @marrobi

I'm about to look at this one for our TRE instance, since we would like infrastructure encryption turned on.

Was planning to do something along the lines of:

resource "azurerm_storage_account" "stg" {

  ...

  infrastructure_encryption_enabled = true
  lifecycle { ignore_changes = [infrastructure_encryption_enabled] }
}

So essentially enabling infrastructure encryption on initial storage account creation, however if the storage account has already been created prior to the change, then it won't be enabled. (It's not possible to enable once created without destroying and recreating the storage account.)

@marrobi Would this be acceptable for a PR?

Should an additional build variable be introduced as well to control the default behaviour on initial creation? Such as ENABLE_SA_INFRASTRUCTURE_ENCRYPTION=false

Thanks

@marrobi
Copy link
Member

marrobi commented Nov 13, 2024

@yuvalyaron does this overlap with the CMLK work #4002 that you have in progress?

@jonnyry I can't think of a reason it wouldn't want to be turned on, I presume its compatible with CMK. @SvenAelterman any ideas? As long as no errors or risk of terraform recreating the storage account when it's turned on (main concern), lets always have it on, otherwise need to have the config flag with default to false.

@yuvalyaron
Copy link
Collaborator

yuvalyaron commented Nov 13, 2024

@marrobi I don't think there's an overlap, and they can coexist.
However, as mentioned here, changing this will force the creation of a new resource:
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/storage_encryption_scope#infrastructure_encryption_required-1

@jonnyry
Copy link
Contributor

jonnyry commented Nov 13, 2024

@marrobi OK thanks, I will draft something locally with the following pattern and test on an existing TRE instance that was spun up before the change:

resource "azurerm_storage_account" "stg" {

  ...

  infrastructure_encryption_enabled = true
  lifecycle { ignore_changes = [infrastructure_encryption_enabled] }
}

We could also add this as a double protection against storage account deletion, however this would be problematic for workspaces/workspace services etc since it would prevent them being deleted:

  lifecycle {
    prevent_destroy = true
  }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change PR contains a breaking change that needs to be highlighted or documented story Stories are the smallest unit of work to be done for a project.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants