Security Technical Implementation Guides (STIGs) are an excellent body of knowledge to leverage in securing your infrastructure. With the stig-rhel-7 module you can easily add inventory and remediation policy for RHEL 7 with CFEngine. Do note that as of March 2024 this module does not provide comprehensive coverage but rather an initial 10 findings are implemented.
Setup To start I installed CFEngine Enterprise on a local virtual machine, logged in and started a new Build project with the stig-rhel-7 module added and configured to enforce (as opposed to only warn).
For CFEngine we manage several public and private repositories of code in GitHub for our Open Source and Enterprise products. In order to ensure quality we run many checks on the code both with nightly builds as well as on each pull request. We use a Jenkins server for nightlies which also includes more extensive deployment tests on all of the platforms we support. Previously we had used Travis for many of these checks but that system started to show its age and limitations.
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.
In CFEngine Enterprise we collect information from each system in the infrastructure as inventory. Some inventory is available by default, and more can be added using modules or writing policy. You can use inventory information to create a Compliance Report with checks that determine if the information complies with your security requirements. In this blog post, we will use some modules from CFEngine Build which provide inventory data, and build a Compliance Report on top of those.
As a person who tries to work with as few resources as possible, whether it’s editing everything with ed(1) or using old laptops without screens for servers or turning off computers as much as possible I am happy to announce nightly packages are available for the aarch64 (ARM 64-bit) architecture.
This enables low-power, low-cost devices such as the Raspberry Pi and many others to run CFEngine Enterprise.
Why run CFEngine? It is lean on resources and rich in features!
Recently we introduced new feature where you can trigger agent runs and report collection from the Mission Portal UI.
This required our daemon cf-execd to behave a bit differently when periodic agent runs occur. Previously the daemon would create a new thread in which to run cf-agent, capture output, wait for completion and move on.
We changed the behavior so that the daemon forks itself and then fork/execs cf-agent as before, with the forked cf-execd processing agent run output.
Saint Patrick’s Day makes us think of the color green. Spring is coming. Plants are starting to sprout amongst the dead grass and leaves from Fall/Winter:
Earth Day is just around the corner on April 22nd.
This reminds us of our commitment to the environment and ecosystems that surround us. As we at Northern.tech state in our corporate social responsibilities:
We have set an ambitious company-objective to “Become a net-zero carbon business by the end of 2022”.
CFEngine is well suited for use in IoT environments due to it’s portability, size, and performance. There already exists a meta layer for including the CFEngine community client and Masterfiles Policy Framework in Yocto Project builds. This enables developing policy to:
ensure a service stays running track changes to important files monitor a value over time for normalcy Let’s walk through bringing up a qemu environment with CFEngine and ensure that a few basic things work: ensure the udev service stays running, tracking changes to important files like /etc/group and a look at monitoring capabilities.
I have a setup at home where I keep a local git server running on a Raspberry Pi 3 which contains personal/work journal, dotfiles and a personal policy repository. It was set up manually so before adding a new git repository for a family password store I set about retrofiting the configuration in CFEngine. The goal in this blog is to ensure that what I have already is managed by CFEngine and that what I want to add, /srv/git/passwords.
Several months ago I started the practice of using CFEngine Enterprise and its Mission Portal UI on a daily basis to manage the connected devices in my home. To start, I brought up an old desktop machine, cfengine-hub, to use as my hub and downloaded Enterprise, which is free for use up to 25 hosts. The next step in using best practices is to deploy policy from a version control repository.
