As part of my app I need to spin up a separate transcoding server.
I've got it all up and running fine but I'd like to utilize a minimal Laravel install on that server to manage api requests in and out of the server. I was thinking about either using sqlite db to manage the server or maybe giving access to the main db via a temporary username/password and of course whitelisting ips.
Currently as part of my deployment process i use an ssh package to scp files from the worker server doing the provisioning to the temp server. It sometimes doesn't work though, because of a variety of reasons with ssh and host verification.
I was thinking that maybe what I could do is just allow the temp server access to an s3 bucket where it can download the .env files but I'm concerned about security that way. I'm thinking about either having the temp server have access to my main database or maybe giving it access to another database on the server that just has the relevant info.
Any ways, what way would be the most secure to deploy the env files to that temp server?
Fixing the scp issue?
Letting it download from s3 via preauthorized key or maybe a temp signed route?
Maybe allowing it to download the .envs via a signed api webhook?
Try to keep deployment process simple and isolated.
I think you must try this server as a microservice. This is: separate infrastructure, separate (and optimized) databases and sync the data using events. So this part of the application could be broken, hacked and destroyed without worried about the main app server.
About the sensitive values, you could store env vars in secrets manager and then copy into a local .env file as part of deployment process. Doing this you can skip the "variety of reasons with ssh and host verification." mentioned.
Due to pricing concerns I don't use AWS for this project so secrets manager isn't an option for me.
I do think you are right about the microservice. I need to build it out like that and am kind of doing it.
The server is represented in the main db as a model and then i use a library for interacting with it. I could break that out in to its own repo and then just work on it as a seperate project. I would like to expand this in to other verticals so it would allow me to manage that kind of easily.
I alse think you're correct that I should probably not integrate the server in to the main db further than that. I have the ability to spin up mysql for that server only either locally on the server or on the main db host. Maybe ill just create a seperate db and have it all handled there. Then I can persist data across servers and even have the main app put jobs in to the secondary database for that server to handle when its available.
The problem still remains, how to get the .env in to that server as securely as possible. I would imagine an api call to the main app could return the .env in a hashed response then could decrypt on the server with a preset key. Maybe that's better than doing it with s3. In either case, I'm going to have to get the data there somehow.
