Today’s approach to securing IT infrastructure is passé. In a dynamic world of unpredictable and often frequent infrastructure changes, the traditional approach to security falls short. It is no longer sufficient to just scan frequently for vulnerabilities and then try to interpret this data in real time without (human) error. Additionally, despite smart analytics, this approach to illuminating security issues and remediating them is extremely time consuming. How many organizations can really claim to have identified and fixed all vulnerabilities? None! Automation has brought agility and consistency to infrastructure and other workflow services now. Security can and should expect to see similar gains. In this blog we explore some of the reasons that make organizations vulnerable and provide guidance on how they can better counter and secure their infrastructure and applications.
We’re happy to announce the maintenance release 3.10.2 LTS and the new 3.11.0 non-LTS release today! 3.10.2 LTS, being a maintenance (aka patch) release, the goal is to increase stability and reliability for CFEngine users and enable a safe upgrade-path. As such, the release primarily includes bugfixes and low-risk changes that do not impact the compatibility between previous patch releases. 3.11.0 non-LTS includes new features and is not covered under the CFEngine Enterprise support contract. Looking at the CFEngine release schedule, we can see that
With more and more services using SSL keeping track of the certificates in use across a global infrastructure can be challenging. The inventory reporting features in CFEngine Enterprise can be useful in identifying services using SSL as well as when their certificates will expire. cf-monitord provides lists of ports that are listening. We can use openssl to connect to each listening port and if successful we can extract the certificate information for inventory. We won’t be able to find ALL certificates like this. This policy only covers up-front SSL/TLS. From Serverfault:
We’re happy to announce that CFEngine 3.11.0 Beta (non-LTS) is now ready. Thanks to everyone for all of the contributions! Please test extensively and submit bug reports. 3.11.x introduces some new features and deprecates some underutilized functionality. Please note that 3.11.0 will be a non-LTS release, which means that it will be maintained only for 6 months from the release date and not supported for CFEngine Enterprise customers (but Enterprise packages will be available). Looking at the CFEngine release schedule, we can see:
We’re happy to announce maintenance releases for both supported CFEngine release branches today! Being maintenance (aka patch) releases, the goal is to increase stability and reliability for CFEngine users and enable a safe upgrade-path. As such, the releases primarily include bugfixes and low-risk changes that do not impact the compatibility between previous patch releases. Looking at the CFEngine release schedule, we can see that
3.7 LTS is maintained (and supported for Enterprise customers) until July 17th 2018 3.9 non-LTS is no longer maintained 3.10 LTS is maintained (and supported for Enterprise customers) until December 27th 2019 If you are planning to contribute features to the next feature release (thank you!), please note that we would need the pull requests ready for merging by early-April in order to have time to incorporate them into 3.11. If you are planning to contribute fixes to 3.10 LTS please note that we would need the pull requests ready for merging by early-May in order to have time to incorporate them into 3.10.2 LTS.
Last week we attended Config Management Camp in Gent Belgium.
How did automation start? In the beginning Mark split light from dark…
There were 7 talks in the CFEngine devroom. Christian Linden kicked things off with his presentation “Get set for getting work done by CFEngine”. He covered the basics of what you need to know when getting started with CFEngine as well as some tips to help in debugging policies. After Christians Kickoff I talked about “Testing CFEngine Policy”. Why you should test, currently available testing frameworks, how to get started writing tests that produce TAP and or JUnit output and finally how to expand CFEngines test coverage while contributing to examples in the documentation. Martin Simons wrapped up the first day with his talk “CFEngine Hero of IoT”. Martin brought a Raspberry Pi running Raspbian told us how he is using it to implement a motion-activated security system built with commodity hardware at home and then demonstrated how CFEngine can easily manage it and deployed a tomcat application. The main topic of conversation on Tuesday was data. How to separate it from policy, how to make use of external data, and how it can make your life easier in SURFsara. Bas van der Vlies started us off with his talk “How to use the augments file (def.json)”. He showed how he defined a host specific data file that let him easily override default values for a specific service/bundle. He discussed how this has had great benefits for non CFEngine users in his environment, allowing them to easily identify which service/bundles are activated for a host and exceptions that each host is overriding. Next Jurica Borozan talked about “Merging Technologies, ideas on using CFEngine with cloud and container technologies”. He discussed how his tag based classification system enabled host specific policies to be delivered and the varying ways that this common model could be applied to physical systems, docker containers, and cloud hosts leveraging the features available in each technology stack. He finished up by demonstrating his policy that managed maintaining a specific number of AWS instances for a given image and how a simple change in his data source (a json file) resulted in nodes being provisioned or destroyed within 5 minutes. Neil Watson gave a short remote talk “CFEngine Simplified with EFL”. He discussed the design philosophy of EFL and how you can leverage the framework to get things accomplished with CFEngine without having to know any policy. I wrapped up talks with a short presentation on “The Masterfiles policy Framework: A short history and future direction”. I presented the lineage of the current policy framework, how we got to where we are today and how data (the augments file def.json) is very much at the core of how we expect to improve usability and ease future policy framework upgrades without having to edit policy. Special thanks to Christian, Martin, Bas, and Neil for sharing your thoughts and presentations. We look forward to seeing everyone again next year!
We’re happy to announce that CFEngine 3.10.0 LTS now is released! One of the key advantages of CFEngine is its unparalleled performance, and this has received further attention in 3.10.0! A big thanks to everyone testing the 3.10.0 beta release! Being an LTS release, 3.10 will be supported until December 2019. If you are using the previous LTS, 3.7, you will also benefit from all the new features, improvements and testing of all 3.8 and 3.9 releases, which you can read more about in the CFEngine 3.8.0 and 3.9.0 release posts.
The notes from the Q4 2016 meeting can be found in the github repository.
This meeting marks 2 years for the Community Advisory Board. As a reminder the current board members include:
Bas van der Vlies Jonathan Clarke Mike Svoboda Ted Zlatanov Neil Watson Eystein Stenberg Nick Anderson The general consensus was that the meetings have been valuable and we should continue the efforts. We have decided to pilot having the next advisory board meeting in #cfengine instead of #cfengine-cab in order to increase community awareness and get additional input from other users with different perspectives.
We’re happy to announce that CFEngine 3.10.0 LTS beta is now ready for testing! The established CFEngine release schedule shows that the 3.10.0 final version is due in December 2016, so it is time to test and fix any remaining issues! Being an LTS release, 3.10 will be supported until December 2019.
New variable expansion engine A high-demand improvement included in the 3.10 beta relates to speeding up variable expansion over large data structures. This means that working with large JSON-files or nested “classic” arrays is now much more efficient. We can let the numbers speak for themselves. In this simple test, we are using a JSON file with about 2 KB of size (locations.json
Introduction The policy update procedure in the masterfiles policy framework is fairly straightforward - copy all files matching $(update_def.input_name_patterns) from hub’s $(sys.masterdir) directory to clients $(sys.inputdir) directory. Copying everything everywhere and then use some selection (or “classes”) to determine what to do is fine at beginning. My first solution to manage computers in some computer system or landscape was to use “IPv4_*” (or hostname) classes, that pretty soon became hard to maintain and very hard to change. So, I needed a new model that improves maintainability and deployment flexibility of policy. This extension of update procedure enables each computer in some landscape or system to receive and execute only those policies that are specific to it. This improves maintainability and makes systems less cluttered with unneeded information/files. This model extends the existing update procedure to fetch client specific policy files from a separate repository directory on hub (outside $(sys.masterdir)). It copies policies to “$(sys.inputdir)/services/autorun” directory on client. Thanks the “autorun” and “augments” features this approach is easy to implement.
