To set the stage, let’s talk briefly about different generations of automation solutions:
1st generation automation solutions (Ansible, Puppet and in general, script-based automation) where operations are more atomic, fire-and-forget such as deploy the OS on a server, set a VLAN on a switch port, create a LUN on a storage.
2nd generation automation solutions (MetalSoft, VMware and in general, platform-based automation) there is a state database, and operations are typically part of a bigger, more coordinated, and built-in workflow (AKA “orchestration”). e.g., deploying three new servers for a particular application.
One somewhat boring aspect that is often neglected, but which is a key difference between the generations of automations is the cleanup part. To enable true cloud-like behavior on-prem, you need to enable hardware reuse. In software systems, you don’t typically care that much, and instead you just create a new user.
In contrast, servers will have traces of their previous owner’s data on the hard drives, BMC users, firmware, and the switches will have configurations connecting the server to the previous owner’s database and SAN networks. In this instance, LUNs will still allow the previous owner’s IQN to login to the target server.
Very few DevOps teams will spend the time necessary to build cleanup procedures into their scripts. They’re often under pressure to deliver, and the deletion part is a distant concern, but one that comes back to bite the organization down the road when the server needs to be reused, while there is an increased risk of data leakage. The more things like this happen, the more the risk of security holes, IP conflicts, and forgotten configurations increases. These errors are often used by hackers to achieve “lateral movement” between tenants or environments.
MetalSoft takes this boring part very seriously and we perform very complex operations when users hit the “delete” button to ensure the security of our clients:
We use self-encrypting drives Secure Erase capability to cryptographically erase the data on the drives. This is faster and safer than writing zeros on the drives.
If the drives don’t have Secure Erase capabilities, we write zeros on the drives. This can take many hours, but it must be done. A quick “format” will not suffice as that just deletes the file system table not the actual data stored on the drives.
We remove all users from the BMC (ILO, IDRAC) and create a new service user as some users might have added extra users on the BMC that could be used as a back door.
We remove all switch configurations from the switch ports towards the servers to ensure the servers that are not in use cannot be leveraged to access the previous tenant’s other networks.
We delete LUNs (if present), unconfigure the initiator-LUN mapping and delete virtual ports (if any).
We release IP space and other switch resources, such as port-channel IDs, that were allocated to their respective pools.
Finally, we reconfigure RAID to the default configuration.
This re-allocation process ensures that the server is completely ready to be inserted into another infrastructure without leaking data or leaving a trail of misconfigured ports along the way.
So there you have it, MetalSoft takes care of all the boring and time-consuming stuff, so you don’t have to. And this is just one way we do that.
Talk to our technical sales team to learn more and see what MetalSoft can do for you!