example-with-encryption -- CIDR block rework

[chrismillah]

Hey hashicorp fam,

Some of the examples are super helpful, but as noted in the comments, they are not production ready.

I am curious why some values are not variables ( containing the same open CIDR) , to make this more production ready for someone who wants to implement Consul with TLS in produciton.

[chrismillah]

Planning to contribute here, moving from these hardcoded values to variables

EXISTING examples/example-with-encryption/main.tf
allowed_ssh_cidr_blocks = ["0.0.0.0/0"]

allowed_inbound_cidr_blocks = ["0.0.0.0/0"]

__
Planned changes below
__
NEW examples/example-with-encryption/main.tf

servers_allowed_ssh_cidr_blocks = var.servers_allowed_ssh_cidr_blocks

clients_allowed_ssh_cidr_blocks = var.clients_allowed_ssh_cidr_blocks

NEW examples/example-with-encryption/variables.tf

variable "servers_allowed_ssh_cidr_blocks" {
  description = "A list of CIDR-formatted IP address ranges from which the EC2 Instances will allow connections to Consul Servers"
  type        = list(string)
  default = ["0.0.0.0/0"]
}

variable "clients_allowed_ssh_cidr_blocks" {
  description = "A list of CIDR-formatted IP address ranges from which the EC2 Instances will allow connections to Consul Clients"
  type        = list(string)
  default = ["0.0.0.0/0"]
}

[brikis98]

All the examples in the examples folder are optimized for testing and learning. The reasons we don't have examples here optimized for production are:

1. There are many pieces you need to go to production that are not part of this repo. For example, instead of using the default VPC, you'll want a custom VPC with public and private subnet tiers. You probably want Vault running in a private subnet and only reachable over VPN. The AMI you run for Consul should have a bunch of server hardening utilities, such as fail2ban, automated security updates, protection for the EC2 metadata endpoint, etc. You probably need a bunch of monitoring utilities to track metrics, do log aggregation, and configure alerts. You probably want other security and auditing features in your AWS account, such as CloudTrail, AWS Config, Amazon GuardDuty, etc. To create an example that we feel comfortable as saying is ready for production, we'd need all the above in place, and perhaps more, depending on your requirements.

2. Once you have all the above in place, trying the repo out is harder. So for learning, we need simpler examples anyway.

3. Once you have all the above in place, writing automated tests for the code is harder. The test has to fire up all that extra infrastructure, so it'll take much longer to run, and it can no longer connect over the public Internet, but instead needs to validate Vault via a VPN server, which makes the test more complicated. We require all the examples to have automated tests, otherwise, they tend to break very, very quickly.

All of the above are solvable, given enough time, but we haven't gotten there yet in this repo. Also, just to be clear: the code in the modules folder can definitely be used in production—it's only example code of how to do that in the examples folder that we haven't gotten to yet for this Vault repo. If you want access to a bunch of production-grade code for other repos, check out Gruntwork.

[chrismillah]

Fair, thanks @brikis98 for the detail