Bug: apps without database cannot access secrets

[lorenyu]

The list of VPC endpoints that are created happens to include SSM if there's an app that has_database set to true. If has_database is set to false, there will be no connectivity to SSM. This means that the ECS Fargate's task executor in the service layer is not able to access secrets in SSM to be able to provide to the application. To fix this, we need to check if the service has any secrets configured and if so we need to add "ssm" to the list of required VPC endpoints.

Notes on development and testing

While the required change is probably small, developing and testing the change is a bit involved. In order to prevent breaking the main app, we may want to do the following:

in a feature branch of the platform-test repo:

1. create a new app environment that uses a separate network (not the dev network) and doesn't have a database:

   • update app-config setting has_database to false
   • add a new environment config e.g. test.tf and map it to a new network e.g. "test"
   • create the new test network in the network layer
   • create the new test environment in the service layer
   • verify that the app fails to start

2. now make the appropriate changes to fix this issue

   • add a variable has_secrets to modules/network
   • in infra/networks/main.tf compute has_secrets based on whether any environments of any of the applications mapped to this network have a non-empty configuration in app_config.env_config.service_config.secrets
   • pass has_secrets to the network module

3. apply the changes to the test network, verify that the app can now start

4. run terraform plan on the dev network to make sure that there are no configuration differences

[coilysiren]

My recommendation would be to always create the VPC endpoints, regardless of our various states. To the best of my knowledge, the VPC endpoints don't cost anything, and there's only benefits to using them. It seems like overcomplicating the system to check all these boolean values for whats ultimately a simple AWS construct.

[lorenyu]

They aren't free: https://repost.aws/questions/QUmfyiKedjTd225PQS7MlHQQ/vpc-nat-gateway-vs-vpc-endpoint-pricing

That said, I'm open to simplifying things. But I think it potentially gets a little muddier if we just combined everything into one list, because then a project team won't know what a VPC endpoint is being used for and it makes it harder to remove an endpoint.