Terraform Aws Documentdb Cluster Versions Save

what

Amazon has announced IO-optimized storage type for DocumentDB. Support for it has been added since HashiCorp AWS provider version 5.29.0

why

Keep standard as default but also add ability to create IO-optimized DocumentDB clusters.

references

https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-documentdb-i-o-optimized/ https://registry.terraform.io/providers/hashicorp/aws/5.29.0/docs/resources/docdb_cluster#storage_type

what

Hey folks 👋

First of all thanks for the work 💪

Here the goal is to allow the user of the module to attach security groups which are managed outside of the module

why

This is pretty useful, when you have some design where security groups are centrally managed and so outside of the scope of the module

references

Note: If you have any questions don't hesitate to ping me 😉

Cheers ☀️

what

In this PR, we can use the Cloud Posse ssm parameter store module to store the documentdb master_password information.

why

The objective behind this PR is to ensure the secure distribution of the docdb cluster's master password within the AWS infrastructure. We can centrally manage and protect sensitive information, increasing operational efficiency.

references

No issue relates to the current improvement.

I have run these required commands. make init make readme

Kindly review this PR for documentdb module improvements. Thank you, Cloud Posse Team!

what

We need to have the possibility to select the certificate we need to use, or directly the default amazon one.

why

Because https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL-certificate-rotation.html

references

Please read the link -> https://docs.aws.amazon.com/es_es/documentdb/latest/developerguide/ca_cert_rotation.html

what

• Reverse the sense of the enabled variable when deciding the count for the random_password resource.

why

• The sense of the variable was backwards - setting enabled to false meant that the count was always set to 1. A minimal configuration to reproduce this is:

module "disabled_docdb" {
  source = "../../work/terraform-aws-documentdb-cluster"
  enabled = false
  vpc_id = ""
  subnet_ids = []
}

what

• Added 4 new variables egress_source_port, egress_dest_port, egress_protocol, and allowed_egress_cidr_blocks for the "aws_security_group_rule" "egress" resource.
• By default, the egress rule 0.0.0.0/0 will be created. If user is expected to restrict outbound traffic, they can specify the required values.

why

• We propose this PR because there are scenarios where users may want to restrict outbound traffic from their DocDB instances.
• if the DocDB cluster is only used internally and do not need to communicate with wide systems or network, users may want to customize the egress rule for 0.0.0.0/0. By providing the option to customize the egress rule, we are giving users a control over their security posture (compliance). For example, our docdb may only connected with internal applications inside the aws eks cluster, or users may integrate their cloud resources with a third party, such as Prisma Cloud or maybe use tfsec as their security scanner, which prompts users to kindly avoid 0.0.0.0/0 for security best practices.

references

• This PR will help to cover the minimum egress exposure of the security group, including: #34

Thank you

what

Support AWS Provider V5 Linter fixes

why

Maintenance

references

https://github.com/hashicorp/terraform-provider-aws/releases/tag/v5.0.0

what

• adds variable allow_ingress_from_self which configures the security group to allow traffic within itself on DB port

why

• This is useful in architectures where the db security group will be used to control db access - i.e. it will also be applied to applications.

references

https://github.com/cloudposse/terraform-aws-rds-cluster/pull/145

what

• Add a master_password output for the generated password.

why

• The generated password needs to be stored somewhere so that it's possible to use it to connect to the cluster.
• This can for example be done by storing it in an aws_secretsmanager_secret_version as part of the terraform configuration that creates the cluster.
• Exposing the password as a module output makes it available to other parts of the configuration so that the password can be passed to the resource that stores it.

references

• closes #43

Rebuild github dir from the template

Sync github workflows with the template

propagated preferred_maintenance_window to the docdb cluster instances resources

what

• The maintenance window given as a variable is given to the Terraform Resource aws_docdb_cluster_instance.default such that the cluster and its instances have the same value given by the user
• Closes #55

why

• Without that the cluster instances were having "random" windows that don't match the expectations of "potential" down time
• Users want to be in control of when their databases can go under maintenance not just at any "random" time

references

• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/docdb_cluster_instance#preferred_maintenance_window