New server deployment on VPS encryption idea

New server deployment on VPS encryption idea

Just got done deploying csgoisfail.com via do droplet, replete with nginx, mysql, php, drupal 8, and drush from scratch, and - since scripting this sort of basic deployment has been on my mind for over three to five years now... long before the convenience of digitalocean droplets - basically tried to standardize this sort of deployment via script. I didn't have time to follow through with that (at least, not entirely), especially since digitalocean.com's dashboard incentivizes me to be lazy via allowing me to simply snapshot deployments.

Generally, I use DO snapshots inthe following use cases:

1: Before implementing major or experimental configuration alterations in productions, I'll (usually, if there's any chance that an important site could be borked, remember to) take the extra 10-60 minutes to poweroff the site and use the digitalocean dashboard to take a snapshot of the (then currently working) configuration. This is great because I don't have to create a whole backup set (with mysql dumps, files, and the associated myriad of config files and all, all of which I invariably forget some important nut or widget which makes restoring from such backups a pain in the ass, plus it requires entire redeployment time overhead of the entire server environment etc. etc.; with a snapshot, I get a one-click-redeployable image of everything on that server AT THAT MOMENT).

2: For backups - NOT A BEST PRACTICE, I KNOW, I KNOW, but what I lose from not having proper backups, redundancy, and walk-through-able-ness, I gain in *MAYBEY* (when the excrement hits the AC) at least having a snapshot to fall back on. I run (and have run) *TONS* of servers; not just for myself, but as managed servers for others, etc.; there's simply no way that I can provide legit backup services for EVERYTHING (though, for some servers, I do my damndest) that's under my purview (and of course, I advise clients of this as well, clearly and up-front... backups are a motherfucker to manage if you're not the sysadmin/engineer directly in charge of the infrastructure necessary, blah blah blah)... so yes: I use DO snapshots for backups (always cognizant of the possible losses should DO itself disappear tomorrow/other catastrophic problems to not having 3 copies of everything at all times). So there's the backups use case.

3: For Templatizing Server Deployments: This is by far my favorite (and DO's intended) use case for DO snapshots: I can spin up a server from a template snapshot, iterate all the fuck over it like a grafitti artist, filling it with whatever crazy madness or garbage I wish (be it intentionally experimental with the intent to deploy some iteration of said madness in production at a later date, or be it purely for throw-away "what shit sticks" purposes), keep notes on what I've done, what worked, what didnt', then either save that new iteration (if it meets my goals) to a new snapshot, or scrap it and roll it back to the previous snapshot. Having this capability is so far beyond my wildest imaginings in terms of being a sysadmin back when I started with servers (pre-2010) that it blows my mind.

4: For Templatizing Deployment Configurations (For PRODUCTION DEPLOYMENTS): There is nothing I love more than when someone else's needs and my skillset meet... EXCEPT (!!!): for when they do so *AND* I have already gone through the trouble of templatizing said solution. The whole idea of computer science is doing the hard stuff once (hopefully with ample comments and a workbook if necessary, but still: do it once, then never again); I subscribe to this ideal wholeheartedly in ideology - if not in actual implementation. So, any time I start noticing majorly useful design patterns (progrommatically, or from a systems administrator's perspective), I try to formalize those solutions into one standardized solution. To be honest, there really isn't way I can stay in the game otherwise; it makes managing on going commitments much easier and better for all, allows me to focus on the solutions (to read: necesary tweaks to accomplish the objectives at hand) and makes me faster overall (which is always good).

So, to that end, I've recently begun spending a lot of time thinking about the best ways to protect account credentials for all of those standard sysadmin services, hoping to standardize them across my snapshotted images. I haven't fully investigated/researched what I'd like to do (outlined below) but will be making this a project next week (once my current workload is less demanding).

Ideally, what I'd like to do is have a tiny partition of my VPS drive chunked out and encrypted, containing (as a reference to me, for when redeploying a snapshot of said image, either for myself or for a client) a set of boilerplate credentials for that snapshot.... This sounds stupid, but it would go a long way:

1. It would make me totaLLY less reticent to create credentials specifically for that service by virtue of removing the fear that I may forget/lose my creds as generated through any number of best-practices-recommended packages: If I could know that, on any given VPS, there was an encrypted (and therefore, presumably secure) partition, protected by either a key or (as is my preference) a great password phrase that I'm able to remember (I won't go further into my password generation methodology than that, but just know that, having spent a lot of my life cracking passwords, I know that they are actually useful when they are of a certain length AND are also memorable enough to be recalled by the admin), I could store all the user names and passwords generated for services for that server (SQL, CMS, etc. etc. etc.) in a plain basically a plaintext file.

Sure, I know that (even if possible) this isn't ENTIRELLY SECURE, but given the parameters we're talking about (VPS, etc.), it would go SUCH A LONG WAY towards mitigating against possible compromise. Ok. Back to work on csgoisfail.com.

Posted On