Extend ECS Exec support for a secure production jump host

[rocketnova]

594 adds the AWS plumbing for enabling ECS Exec. It also supports enabling ECS Exec for application containers. This is useful for debugging in lower environments, but very risky in production (it may also be risky in lower environments if people put real PII or real money in lower environments).

A more secure approach would be to set up a separate ECS container specifically for connecting to other resources, such as an application database.

See:

• https://github.com/navapbc/template-infra/pull/594#discussion_r1586877386
• https://github.com/navapbc/template-infra/pull/594#discussion_r1586878705

[rocketnova]

@tevert @coilysiren It sounds like what would be most useful would be something more isolated than the current implementation in #594. I think this would require these new resources/config (separate from the application):

• ECS resources (cluster, service, task, task definition)
• access logs
• application logs
• database access

What IAM resources would we need for this? Especially for per-user audit trail?

[rocketnova]

Also, are there any other resources, besides the database, that are currently included with the platform infrastructure template that you would want to use the jump host to access?

[coilysiren]

Also, are there any other resources, besides the database, that are currently included with the platform infrastructure template that you would want to use the jump host to access?

No, but, I would be using ecs exec to try and debug networking issues with other aspects of our project. For example, we have a peering connection to another team's production database, and this functionality would have been useful to help debug that.