Patching has become particularly challenging in the new cloud and hybrid-cloud environments— especially across Windows and Linux—despite the many methods and technologies for this. What are the differences between patching in Windows and Linux, and how does this all fit into the modern cloud infrastructure? Do these new environment paradigms facilitate or complicate patch management?
There has been a major shift of company infrastructure to cloud services in recent years due to its numerous advantages. It has taken the management burden off of in-house IT units by shifting some of that responsibility to the cloud. Nonetheless, these different environments present new challenges, such as how to patch properly across a spanned environment or one that is entirely within the cloud.
Windows vs. Linux Patching
Windows patching has traditionally been managed via Windows Server Update Services (WSUS). It has been extended in several ways, such as with Systems Center Configuration Manager (SCCM) and with other third-party solutions that plug into WSUS. Moreover, in a managed environment, Group Policy can be used to further control and optimize how patches are applied and delivered to potentially thousands of clients.
Linux, on the other hand, is vastly different. Most patching is done via the command-line and can be managed with solutions such as Ansible, Puppet, or Chef that script running the commands necessary to update a given environment. For a more managed environment, there are vendor-specific solutions like RedHat Satellite or Ubuntu Landscape, or if in a given cloud infrastructure such as Azure or AWS, each has its own patching solution that can be used to manage which patches are applied and when.
Cloud vs. On-Premise
On-premise patching is usually done within Linux via the command-line, whereas Windows has generally used a combination of WSUS and Group Policy. With the new modern cloud infrastructure, most providers—such as Azure or AWS—offer some level of automated patching. Azure offers Azure Update Management, which helps to manage compliance, policies, and determining what exactly is patched. AWS, on the other hand, offers AWS Systems Manager Patch Manager, which has very similar capabilities.
Most on-premise patching requires managing your own virtual environment or physical server. With the managed services offered by most cloud providers, there’s no need to worry about any of these issues, since the provider handles this low-level infrastructure for you.
All of these different operating systems and combinations of environments present a number of challenges. But what can be done to mitigate these problems? Are there specific solutions that make sense for hybrid-cloud environments, and how different are these from on-premise solutions? Can these be extended to both environments?
Best Practices Challenges
First let’s explore common best practices when dealing with patches, whether multi-OS or hybrid-cloud. These include reporting on the patch status of your systems, controlling what patches are released to the systems, and ultimately being able to roll-out in stages and roll-back if there are any issues.
Staged roll-outs are one of the most crucial abilities. Should problems arise–which is not uncommon in the world of patches—their impact must be limited in order to avoid having to take down all of your systems at once. Following are general guidelines on how to group systems:
- Evaluation systems: New patches or pre-release versions require a group of computers that can be used as canary systems to evaluate any issues.
- Random population: It doesn’t do any good to hand-pick evaluation systems that might not matter if they go down. While there may be important systems you do wish to exclude, most important is that there be a solid representative population to test against.
- Staging groups: Last, it is important to set up a series of staging groups following a predefined interval (e.g., by day or week) to determine when patching for the next group of computers will be.
Challenges
Large Environments
The larger the environment, the more challenging it can be to monitor, stage, and control updates effectively. First, the updates must be properly staged to various systems, as discussed in best practices. For example, if you have a thousand systems, you might choose to deploy the updates to a random hundred the first week and to add more to the deployment groups with each subsequent week. Not only does this allow you to gauge the effectiveness of a patch, this also allows you to limit the impact should any issues arise.
For geographically remote systems, it often takes longer for the patches to filter out. Bandwidth limitations in areas with limited access can also make it more difficult to get patches out quickly. Such groups and their systems, therefore, need to be taken into account during the planning process. In a large environment—one that may be geographically dispersed—having random populations of evaluation systems and staged groups in place will ensure that your patches are widely distributed to help identify issues early on.
Multi-OS Patching
Windows and Linux are vastly different operating systems when it comes to patching. Functionally, both operating systems do the same thing, which is to replace system libraries or software with newer versions. However, they each employ different mechanisms. Moreover, each of Linux’s many versions offers its own take on patching. For example, Ubuntu uses APT, while CentOS uses YUM. Though both offer the same general utility, the commands are different. There are also many subtle differences between the two when it comes to approach and execution.
Properly supporting a multi-OS system requires either running a different native patch management system or using cloud systems capable of patching both on-premise and cloud environments. Azure Update Management or AWS Systems Manager Patch Management enables support for both sets of systems.
Evaluation systems play a crucial role in patch coverage for multiple OS environments. Populating your evaluation groups with systems of varying operating systems will guarantee a diverse environment is represented.
Containers
Containerization and patching are another important element here. Generally speaking, patches are not applied to containers. In fact, patching is almost the antithesis of the container philosophy. Most containers are intended to be short-lived and idempotent. Usually, new containers are simply spun up instead of patching existing ones. So you might patch the root image the container is derived from, but ultimately it would just be destroyed and a new, updated container would be recreated as opposed to patching each one individually.
Successfully Managing Patches in the Cloud
Despite the challenges the modern cloud environment—whether hybrid or not—poses when it comes to patch management at scale, cloud providers now offer numerous tools and capabilities to mitigate these difficulties in both the Windows and Linux environments. Maintaining an up-to-date and patched infrastructure is crucial to securing your assets.
Implementing standardized processes in line with industry best practices will enable you to respond quickly and adapt to any emerging threats. Armed with this knowledge and the software available to assist, your organization will be well-positioned to control the patching environment.
