Feature Description
After #6631 was merged, it changed the way the frontend communicates with the backend. Now, the frontend sends both requests (assign request and json transport request) to the scaling service directly, so they can be secured with TLS. This is because the scaling service already has a valid SSL certificate provisioned by Heroku.
However, this left the communication between the scaling service and host service unprotected, because we don't have a way to use valid certificates on the host service without exposing them. Its crucial that the request is secure during the whole transaction.
The problem is that the host service can't be trusted since there is always the risk of a container escape incident where the certificate would get exposed. This would compromise the certificate that is distributed to the rest of instances and certificates are not easily rotated.
The solution would be to:
Introduce a tool like Vault, AWS Certificate Manager, or GCP Certificate Authority Service that allows us to expedite certificates on demand. This way we can provision "disposable" certificates for each instance.
Make the host service act as a client instead of a server. This way we can get TLS without needing to provision certificates to the host service. The way it would work would be to merge both requests into a single one that the frontend sends to the scaling service. After that the host service asks for the config token and returns the ports and aes key to the scaling service, which redirects the result to the frontend.
Introduce a separate server or message queue that the host service can request the JSON transport data sent by the scaling service/frontend.
Feature Description After #6631 was merged, it changed the way the frontend communicates with the backend. Now, the frontend sends both requests (assign request and json transport request) to the scaling service directly, so they can be secured with TLS. This is because the scaling service already has a valid SSL certificate provisioned by Heroku.
However, this left the communication between the scaling service and host service unprotected, because we don't have a way to use valid certificates on the host service without exposing them. Its crucial that the request is secure during the whole transaction.
The problem is that the host service can't be trusted since there is always the risk of a container escape incident where the certificate would get exposed. This would compromise the certificate that is distributed to the rest of instances and certificates are not easily rotated.
The solution would be to: