Feature Request: Enable Native TLS Support for Cloud Run Deployments

[gbhall]

Description

Currently, deploying the application to Google Cloud Run necessitates providing TLS key and certificate files as arguments during deployment. However, Cloud Run manages HTTPS termination externally, forwarding decrypted HTTP traffic to the container. This dual TLS handling results in conflicts and errors such as:

"Client sent an HTTP request to an HTTPS server."

http: TLS handshake error from <IP>: EOF

Additionally, omitting TLS arguments prevents the application from starting, as it relies on these configurations for secure operations.

Error loading public key: open : no such file or directory

Proposed Solution

Introduce a configuration option or modification within the application to conditionally handle TLS based on the deployment environment or the presence of specific environment variables. This would enable the application to:

1.	Detect Deployment Context:
•	If deployed on Cloud Run, disable internal TLS handling and serve HTTP traffic.
•	If deployed elsewhere (e.g., on-premises or another cloud platform), enable TLS as required.

2.	Configuration Flexibility:
•	Utilize environment variables to toggle TLS functionality, allowing for dynamic configuration without altering the deployment command.

3.	Enhanced Compatibility:
•	Ensure that the application aligns with Cloud Run’s architecture, leveraging its managed HTTPS termination without internal conflicts.

Current Deployment Command

gcloud run deploy tesla-proxy \
  --image=tesla/vehicle-command:latest \                                                          
  --platform=managed \
  --region=us-central1 \
  --allow-unauthenticated \
  --port=8080 \
  --set-secrets="/config/tls-key/tls-key.pem=TESLA_TLS_KEY:latest" \                                                                                     
  --set-secrets="/config/tls-cert/tls-cert.pem=TESLA_TLS_CERT:latest" \
  --set-secrets="/config/fleet-key/fleet-key.pem=TESLA_PRIVATE_KEY:latest" \
  --args="-tls-key","/config/tls-key/tls-key.pem","-cert","/config/tls-cert/tls-cert.pem","-key-file","/config/fleet-key/fleet-key.pem","-host","0.0.0.0","-port","8080","-verbose"

[sethterashima]

Our concern with similar proposals has been that if we make it easy to deploy the proxy without TLS, then people who don't know what they're doing will end up deploying it without TLS while exposed to the public Internet. We've had problems with third-party apps being misconfigured in this way in the past.

I'm open to suggestions for accomplishing what your'e after, but it needs friction. Friction is load-bearing here; it discourages an enthusiastic but non-techncial DIYer from blindly adding flags or running commands in a terminal. For example, even though TLS breaks server authentication instead of client authentication, this breakage deters most users from setting up insecure deployments because of the red flags that get raised when server authentication breaks.

One alternative: Use this repository as a package instead of using tesla-proxy directly. Tesla proxy is a thin wrapper around the proxy package, and you could write another thin wrapper that does what you want without needing to fork.