Magnitus: Not just if its compromised. ...Basically, to put a hard reset on all the little imperfections that permeate man-made systems....However, the automated vm is repeatable,...You don't want to be the guy who does ninja stuff by hand and then leave people scrambling in his wake trying to untangle the magic. Everybody who has to clean up after him ends up absolutely hating that guy. We aren't magicians making snowflake magical wonders whose like will never be repeated again. We're engineers making correct, precise, repeatable systems.
I think if we leave these as they are here, understanding there is more context to them, we see a fundamental flaw in the logic. The reason you have to do cleanup and things like that is becaus, well, as you said, man-made systems have imperfections. You solution is to roll them back to, well, man-made imperfections at a different layer. Perhaps it is indeed an improvement, but, at the end of the day, it's goalpost moving, rather than solving the fundamental problem: instead of the imperfections of every user, you have the imperfections of every coder who made the system. And that boils down to, "who gets to decide what default settings are the good ones?"
And it also misses the fundamental problem I have with the whole "reset" thing. You are logging into a computer to make changes and store a result. If you reset, you're not storing a result, hence my comment on "gateway."
Sure, if you have something that runs on a Windows machine, you ain't gonna debug it on a Linux server. With gpu passthrough, you might be able to debug it in a windows vm though. But yeah, you get a lot less benefit from virtualization on a desktop (I won't say none, its always nice to be able to try something radical on a full fledge os and then tear it down without having to live with the mess). Virtualization really shines in the cloud.
I'll be frank though, I haven't dabbled with Windows-specific desktop software since like 2009. Its just not something I'm very interested in anymore. The only Windows-compatible stacks that interest me at this point are the ones that are portable (web, cross platform languages and frameworks, etc).
This is part of the problem. I don't know what you're actually messing with. I'm a big fan of Linux, myself, and, outside of storing files, it does a pretty good job of returning to a default state when i am not using root. That bash variable i set in that script? It's gone before i even logout. I don't need to reinstall my OS over that.
But, as for windows, it's not that different. Most programs are pretty good at not relying on environment variables and even making user-specific configurations when you don't have a sysadmin poking around in the "default configs."
kohlrak: And if not with things like SSH, how does the GIT connect?
Magnitus: I misread that part of your post. I will try to address this part of your interrogation now.
First of all, to initially provision vms (ie, the ssh connect to a blank vm scenario), ideally, you use pre-made vm images (to have your dependencies pre-installed in a verified valid way) and then you use cloudinit (
https://cloudinit.readthedocs.io/en/latest/) to pass initial configuration logic to your vm when it is created, like so:
https://github.com/Ferlab-Ste-Justine/openstack-postgres-standalone/blob/master/main.tf#L44 https://github.com/Ferlab-Ste-Justine/openstack-postgres-standalone/blob/master/templates/cloud_config.yaml Note that in the above case, I technically install dependencies from cloudinit which is less robust (getting dependencies over a network is a source of error and is more time consuming than having them baked into the image) and is purely due to time constraints. The medium to long term strategy here will be to only pass configuration settings to cloudinit and boot the vm with an image that already has installed dependencies baked in.
To push the terraform orchestration to your cloud, you have two options:
- Create a pipeline in a terraform git orchestration repo that interacts with your cloud provider (would usually run when you merge to the master/main branch for example as master/main would be the source of truth in your system)
- Create a service directly in your system that listens to changes in the git repos (again, probably to the master/main branch) and execute them against the cloud provider
For updates, you just create a new vm, change the state of your system to use it and then scrap the old one. There is no "update" in the sense that you are mutating an existing vm. For more old-school stateful solutions like postgres, this will usually entail a bit of downtime (the state is not really made to be distributed across several running vms). For stateless or properly distributed stateful applications, you can achieve this without downtime for your end user.
For your kubernetes orchestration, you can use fluxcd that will listen to a git repo and sync changes to your k8 cluster against a given branch that will be the source of truth for the state of your cluster. Example:
https://github.com/Ferlab-Ste-Justine/cqdg-environments/tree/master/qa Here, rolling back a bad keycloak deployment looked like this:
https://github.com/Ferlab-Ste-Justine/cqdg-environments/commit/2db55e715f3f00a19a49b6fcc341bec0caf2d124 I didn't do anything by hand, I just changed the orchestration code and let fluxcd's autosync do its work.
You can make your own in-house tooling for a lot of other systems to behave the same way. For example, Airflow will automatically change its jobs based on Python code in a "DAG" folder.
If you can just pass a directory to airflow and autosync that directory against a git repo like so, you are in business:
https://github.com/Ferlab-Ste-Justine/cqdg-environments/blob/master/qa/airflow/deployments-override.yml#L15 https://github.com/Ferlab-Ste-Justine/cqdg-environments/blob/master/qa/git-autosync/configmaps.yml#L15 https://github.com/Ferlab-Ste-Justine/cqdg-dags Ok, reading this post, i'm absolutely certain i know what's going on. You're not doing resets, like you say. What you're doing is a "more reliable cleanup." The issue, here, is that we have totally different starting point models, which is why we have an issue.
In my setup, i code on the same platform where the code runs. Why? Because I only have 1 computer to work with, and it's running a pentium 4. I think that, given my economic situation, this is excusable, especially as i'm the only one with SU access. And, even then, i have disclaimers warning about where my security couldbe flawed. I'm also not a corporate entity.
Now, a corporation, on the other hand, has more resources to work with. A corporation like GOG should be able to have dedicated SQL, GIT, and other servers on separate hardware. If the only purpose of the SQL server is to handle SQL, like it should be, then the SSH creditionals should not only exist behind a gateway, but should only be given to supervisors of the SQL team: you don't need SSH to do SQL, but you might need it to do security updates when you can't get to the office and something gets found and patched (IRL, though, most can get to the office). You GIT server exists for storing code, versioning, etc, and is likely to be access by various teams, but, when possible, SSH shouldbe limited to SFTP (i'm not sure how to go about that, but certainly should be the case). If i'm testing code, I shoudl be running it on the machine i'm coding on, so i don't need to use VIM and other things on another machine. I most definitely don't need root access, unless my supervisor can't setup my account to give me access to my GIT repo.
The question i have for CDP is, why investor data was stored on the same server as the GIT repo? Because, well, that was the info stated to be compromised. Either that, or there are "universal credentials," at which point we need to ask if every game on GOG was stolen and what about customer info? We clearly had information on servers that didn't need to be on those servers, or should have had dedicated servers to the tasks. I'm on an IRC network where people are saying the monthly prices of a VPS is between 5 and 10 bucks a month, for very good performance, indicating to me that CDP running it's own hardware should be able to run it even cheaper. Realistically, CDP could have dedicated hardware for a GIT server using a raspberry pi with a multi-terabyte hard drive attatched via USB. How often are they committing code (then again, we have the usual corporate practice of the daily commit to deal with, but simple re-analysis of that could easily result in speicific commits on specific goals or dedicated hours on certain days to commit or something like that)?
SQL's a little heavier, but i think we can put the investor data on a separate SQL server from the customer data, and the best the GIT server should hold is Lorem Ipsum. I could go on, but i'm running out of space for this reply. I don't think complete resets are necessary if the holes weren't as present or lucartive in the first place.
