Terraform-provider-aws: RDS - storage_encrypted = true does not work

[hashibot]

_This issue was originally opened by @victorkabdebon as hashicorp/terraform#16894. It was migrated here as a result of the provider split. The original body of the issue is below._

---

Hi Terraform team,

Please see below an issue that I found on the latest version of Terraform over the weekend.

Terraform Version

$ terraform --version
Terraform v0.11.1
+ provider.aws v1.1.0

Expected Behavior

I would have expected the database to be encrypted & setup. Instead, encryption was false.

Actual Behavior

In the output generated the flag was clearly set to storage_encrypted = true, but after it was created both in the admin and the tfstate the encryption was set to false.

Even worse, terraform would get stuck in a loop where at each "apply" it would want to recreate my database every time (probably because the program saw the encryption set to false in the state).

Steps to Reproduce

Truncated terraform configuration

resource "aws_db_instance" "default" {
  engine = "postgres"
  engine_version = "9.6.3"

  multi_az = false 
  backup_retention_period = 10
  auto_minor_version_upgrade = true

  storage_encrypted = true
}

As far as I can tell, turning storage_encrypted to true is enough, then running terraform apply.

[victorkabdebon]

By the way, it seems that setting up automatic backup is also broken.

[atsushi-ishibashi]

docs says

StorageEncrypted

Specifies whether the DB instance is encrypted.

Amazon Aurora

Not applicable. The encryption for DB instances is managed by the DB cluster. For more information, see CreateDBCluster.

[aleksandersumowski]

@atsushi-ishibashi: setting the storage_encrypted at aurora cluster level doesn't seem to work for me as well. I'll create a separate issue for that ...

[victorkabdebon]

It basically boils down to the fact that if an option is not "consistent" (as in it would not be possible to create an instance with these parameters from the interface), Amazon will create something without the right parameters (my guess is the parameters are ignored). It feels like an incorrect design choice for something that sensitive as it gives you a false feeling of success.

Anyway, the way to "fix" that is to go through the interface and see what options will work together and tweak your terraform configuration

[kdubmartins]

I'm having the same issue, but in my case the RDS instance is being created from an existing non-encrypted snapshot. Also, I'm informing the kms_key_id with the ARN for the master key I want to use on the encryption.

The result is a working RDS Instance without encryption, and any new terraform plan will inform the need of a new instance as the existing one is not encrypted.

[zdevi]

Up, problem is still here. storage_encrypted = true doesn't do anything.

[kdubmartins]

Note: my case is solved. It takes an encrypted snapshot to restore a encrypted RDS instance. If you try to restore an unencrypted snapshot to a new instance, does not matter if you enable encryption or not, it will be unencrypted as well.

But for brand new instances (@victorkabdebon 's case) it should enable encryption just fine, which is not happening.

[artkrz]

Wow, reported back in 2017 and still not resolved :(

[mhumeSF]

Agreed. I feel there could be a check of the snapshot is encrypted and error if not when storage_encrypted = true and restoring from snapshot.

[mhumeSF]

Dropping here for ref; but I think a check could be added to snapshot_identifier in these files

aws/resource_aws_docdb_cluster.go
aws/resource_aws_neptune_cluster.go
aws/resource_aws_rds_cluster.go
aws/resource_aws_db_instance.go
aws/resource_aws_redshift_cluster.go

[mhumeSF]

Would also be cool if kms_key_id were specified to verify snapshot restore is encrypted with same kms_key_id and error if not

[rios0rios0]

+1 up

[HannesBBR]

The same issue seems to be present when restoring a DocumentDB cluster from an unencrypted snapshot. Even though storage_encrypted=true is specified, the end-result after terraform apply is a cluster without encryption-at-rest enabled. This then causes subsequent plans to want to recreate the cluster.