Standing terraform driven EKS deployments for each SSB space

[jbrown-xentity]

User Story

In order to bypass delays related to the SSB deployment process, data.gov admins will deploy a single EKS instance per space using terraform and github actions and bind the credentials to ssb-solrcloud using a user-provided service.

Acceptance Criteria

[ACs should be clearly demoable/verifiable whenever possible. Try specifying them using BDD.]

• WHEN I look at the environment of the SSB SolrCloud
  THEN I see user-provided-service with credentials for a kubernetes cluster
• WHEN I look at the github actions for datagov-ssb
  THEN I see a workflow that is deploying an EKS cluster in each AWS account
  AND the workflow is created a user-provided-service ssb-solrcloud-k8s in each space

Background

[Any helpful contextual notes or links to artifacts/evidence, if needed]

Security Considerations (required)

None compared to broker approach, same POAM's apply

Sketch

[Notes or a checklist reflecting our understanding of the selected approach]
(In datagov-ssb)

• Remove cloudfoundry_service_instance.solrcloud_broker_k8s_cluster resource from application-boundary.tf
• Declare brokerpak-eks-terraform-provision module
  • Source is https://github.com/GSA/datagov-brokerpak-eks/tree/main/terraform/provision
  • Amend terraform.${ENV_NAME}.tfvars with new parameters (instance_name, subdomain, size, ...)
  • Specify those parameters when declaring module
• Declare brokerpak-eks-terraform-bind module
  • Source is https://github.com/GSA/datagov-brokerpak-eks/tree/main/terraform/bind
  • Specify the instance_name when declaring module (same as provision)
• Declare cloudfoundary_user_provided_service resource for bind, named ssb-solrcloud-k8s
  • Reference: https://registry.terraform.io/providers/cloudfoundry-community/cloudfoundry/latest/docs/resources/user_provided_service
• Update broker_solrcloud service block with the previously defined user-provided service