Traditionally, CFEngine policy sets are managed as a whole. When upgrading the Masterfiles Policy Framework (MPF)1 users must download the new version of the policy framework and integrate it into the existing policy set, carefully diffing the vendored policy files against their currently integrated policy. Updates to policy authored by others must be sought out and similarly integrated.
Having a list of software that is allowed to be installed on a host is a strategy to prevent and fix security gaps and maintain compliance with operational guidelines. This zero-trust methodology ensures that only explicitly permitted applications are allowed to be present on a host unlike package block-listing which enumerates an explicit list of software that is not allowed to be present. In fact, with a software allow-list, you are essentially block-listing everything except the software you allow.
Opening and reading files may cause your program to block indefinitely, which is a major problem for configuration management tools like CFEngine. What if we make a program that can check if these file operations would block indefinitely, before using them? Unfortunately our good friend Alan Turing proved that such programs are not theoretically possible.
Using CFEngine there are many ways to group and classify your hosts. In order to group their hosts, our users use a combination of JSON files, CFEngine policy language (with variables, classes, and class expressions), host specific data and host filters in Mission Portal. With these features you can choose which hosts to show in reports, and you can make decisions on what changes to make on which hosts.
I have stopped using my Linux distro’s package manager, and you should, too. Maybe I should clarify that. I don’t install software with my distro’s package manager any more. I still upgrade my system. I became influenced by a few different factors. Top among these is something required in certain industries called a change advisory board or committee.
It’s that time of year again where we reflect & recap all things new with CFEngine from this year. You may recall from the 2021 retrospective that our focus for 2022 would be on collaboration, ease of use, and community engagement. I’m proud to summarize our progress below in these key areas for 2022’s Retrospective and give you a sneak peek at what’s to come in 2023.
Thank you for following along with our security themed holiday calendar. Today, we summarize the last half of the calendar, in case you missed some days.
Today, we are pleased to announce the release of CFEngine 3.21.0! The focus of this new version has been unification. Across our websites and UI, you should see that it’s a much more modern and unified experience, whether you’re reading this blog post on cfengine.com, browsing the new documentation site, looking for modules on the CFEngine Build website, or adding input to modules within Build in Mission Portal.
Throughout the security holiday calendar, we’ve looked at modules for enforcing security requirements. Writing the policy to achieve these security hardening goals is easy. By learning how, you can write policy (or modules) for any requirements, including those specific to your organization. In this blog post, we’ll take a look at five beginner-level examples to get you started, focusing on the most common resources to manage with CFEngine; files and packages.
When something goes wrong or looks fishy for a particular host in your infrastructure how do you know who to ask about it? In an infrastructure managed by many and used by many it is also helpful to know what each hosts’ purpose is. In this article we show how to add maintainer and purpose information to individual hosts in your infrastructure via the CMDB feature of Mission Portal. We will also add a Build Module to add this information to the /etc/motd file for each associated host.
