cluster changes domain validation & argocd environments

[DaMandal0rian]

PR Type

enhancement, configuration changes

---

Description

• Updated default values for AWS region, hosted zone, and GitHub SSH key across multiple files.
• Simplified hosted zone creation and updated ACM module configuration.
• Added terraform.tfvars files for EKS blue, EKS green, and network configurations.
• Disabled NS record creation and added CAA record creation in Route53.
• add argocd blue/green paths for deployments

---

Changes walkthrough 📝

	Relevant files
Configuration changes	9 files variables.tf Update default values for AWS region, hosted zone, and GitHub SSH key eks/eks-blue/variables.tf Changed default AWS region to us-east-2 Updated default hosted zone name to eks.subspace.network Updated default GitHub SSH key name Corrected GitHub organization name +4/-4      variables.tf Update default AWS region                                                                eks/eks-green/variables.tf - Changed default AWS region to `us-east-2` +1/-1      secrets.tf Update GitHub SSH key names in Secrets Manager                      eks/network/secrets.tf - Updated GitHub SSH key names in Secrets Manager +2/-2      variables.tf Update default AWS region                                                                eks/network/variables.tf - Changed default AWS region to `us-east-2` +1/-1      main.tf Update cluster endpoint to new AWS region                                eks/user_data/main.tf - Updated cluster endpoint to `us-east-2` +1/-1      variables.tf Update default hosted zone and GitHub SSH key name              templates/terraform/aws/eks/eks_cluster/variables.tf Updated default hosted zone name to eks.subspace.network Updated default GitHub SSH key name +2/-2      terraform.tfvars Add terraform.tfvars for EKS blue environment                        eks/eks-blue/terraform.tfvars Added variables for AWS region, environment name, hosted zone, and GitHub SSH key +20/-0    terraform.tfvars Add terraform.tfvars for EKS green environment                      eks/eks-green/terraform.tfvars Added variables for AWS region, environment name, hosted zone, and GitHub SSH key +20/-0    terraform.tfvars Add terraform.tfvars for network configuration                      eks/network/terraform.tfvars - Added variables for AWS region, environment name, and hosted zone +4/-0
Enhancement	2 files main.tf Simplify hosted zone and update ACM configuration                eks/network/main.tf Simplified hosted zone creation Disabled NS record creation Added CAA record creation Updated ACM module configuration +24/-19  main.tf Simplify EKS cluster domain and update Route53 zone data source templates/terraform/aws/eks/eks_cluster/main.tf Simplified EKS cluster domain configuration Updated Route53 zone data source +2/-2

---

💡 PR-Agent usage: Comment /help on the PR to get a list of all available PR-Agent tools and their descriptions

[github-actions[bot]]

PR Review 🔍

⏱️ Estimated effort to review [1-5]	4, because the PR involves multiple changes across various configuration files and Terraform modules, which requires a detailed understanding of the infrastructure and the impact of these changes on the existing setup.
🧪 Relevant tests	No
⚡ Possible issues	Possible Bug: The removal of NS record creation in `aws_route53_record` and the addition of CAA records without ensuring DNS validation might cause issues with domain validation if not properly managed.
	Configuration Concern: Changing the default AWS region and hosted zone names across multiple environments without corresponding updates to dependent resources or documentation might lead to inconsistencies or deployment failures.
🔒 Security concerns	No

Code feedback:

---

relevant file	eks/network/main.tf
suggestion	Consider adding error handling or validation checks when modifying DNS settings, especially when disabling NS record creation. This can prevent potential issues with domain resolution and certificate validation. [important]
relevant line	# Validate records for the new HostedZone (disable since ACM module will create the NS records)

---

relevant file	eks/eks-blue/variables.tf
suggestion	Ensure that the updated default values for AWS region and hosted zone are reflected in all dependent configurations and documentation to avoid deployment inconsistencies. [important]
relevant line	default = "us-east-2"

---

relevant file	eks/network/main.tf
suggestion	When changing the domain name for the ACM module, ensure that all SANs (Subject Alternative Names) are correctly updated to prevent SSL/TLS certificate errors. [important]
relevant line	domain_name = local.hosted_zone_name

---

relevant file	eks/network/secrets.tf
suggestion	Verify that the new secret names for SSH keys are updated across all scripts and CI/CD pipelines to prevent issues with access to private repositories. [important]
relevant line	name = "github-eks-subspace-ssh-key"

---

[github-actions[bot]]

PR Code Suggestions ✨

Category	Suggestion	Score
Best practice	Add a validation check for the hosted zone name to ensure it meets DNS naming standards ___ **Consider adding a validation check for local.hosted_zone_name to ensure it conforms to DNS naming conventions before using it in resource definitions. This can prevent runtime errors due to invalid domain names.** [eks/network/main.tf [51]](https://github.com/subspace/infra/pull/315/files#diff-9a53583c0fb470e0caf937b2459bf9506a6737031a32d9ae07e3d9c22ea615a6R51-R51) ```diff -name = local.hosted_zone_name +name = can(regex("^[a-zA-Z0-9-]{1,63}\\.[a-zA-Z0-9-.]{1,253}$", local.hosted_zone_name)) ? local.hosted_zone_name : "default.example.com" ``` Suggestion importance[1-10]: 9 Why: Adding a validation check for the hosted zone name is a best practice that can prevent runtime errors due to invalid domain names, which is crucial for maintaining the stability and reliability of the infrastructure.	9
	Make the ACM validation wait conditional based on the environment ___ **It's recommended to handle the wait_for_validation flag dynamically based on the environment (e.g., true for production). Hardcoding it to false might skip necessary validation steps that can catch misconfigurations.** [eks/network/main.tf [82]](https://github.com/subspace/infra/pull/315/files#diff-9a53583c0fb470e0caf937b2459bf9506a6737031a32d9ae07e3d9c22ea615a6R82-R82) ```diff -wait_for_validation = false +wait_for_validation = var.environment == "production" ? true : false ``` Suggestion importance[1-10]: 8 Why: Dynamically handling the `wait_for_validation` flag based on the environment ensures that necessary validation steps are not skipped in production, enhancing the reliability and correctness of the deployment process.	8
	Enhance tagging for ACM resources for improved management and tracking ___ **The tags for the ACM module only include the Name tag. It's a good practice to include more descriptive tags such as Environment, ManagedBy, etc., for better resource management and cost tracking.** [eks/network/main.tf [86]](https://github.com/subspace/infra/pull/315/files#diff-9a53583c0fb470e0caf937b2459bf9506a6737031a32d9ae07e3d9c22ea615a6R86-R86) ```diff tags = { - Name = "${local.hosted_zone_name}" + Name = "${local.hosted_zone_name}", + Environment = var.environment_name, + ManagedBy = "Terraform" } ``` Suggestion importance[1-10]: 6 Why: Adding more descriptive tags such as `Environment` and `ManagedBy` improves resource management and cost tracking, which is beneficial for maintaining organized and well-documented infrastructure.	6
Maintainability	Parameterize CAA records to increase flexibility and manageability ___ **The hardcoded CAA records limit the issuance of certificates to "amazon.com". If other CAs are needed in the future, this might restrict operations. Consider parameterizing the CAA records or managing them through a different configuration layer.** [eks/network/main.tf [68]](https://github.com/subspace/infra/pull/315/files#diff-9a53583c0fb470e0caf937b2459bf9506a6737031a32d9ae07e3d9c22ea615a6R68-R68) ```diff -records = ["0 issue \"amazon.com\"", "0 issuewild \"amazon.com\""] +records = var.caa_records ``` Suggestion importance[1-10]: 7 Why: Parameterizing CAA records allows for greater flexibility and future-proofing, making it easier to adapt to changes in certificate authorities without modifying the code.	7