We’re pleased to announce that today CloudPassage Halo added support for CoreOS Docker hosts. In addition to securing servers and containers, now Halo can also support CoreOS hosts running these containers. This is just as important as securing the container itself. The Halo CoreOS agent can run in a container form factor for easy deployment with maximum visibility. In addition, based on CoreOS best practices, the CSM template for verifying CoreOS configuration was also released today.
The race to create the smallest images is a theme that’s catching on with containers. Besides the obvious (which is pure size), container images also make your environment small, efficient, and yes easier to SECURE. Small images result in a reduced attack surface which increase security. CoreOS claims to redefine the operating system as a smaller, more compact Linux distribution. Traditional distros package unused software that leads to dependency conflicts and needlessly increases the attack surface. But CloudPassage is committed to adding support for your entire container echo system and CoreOS support is another step in that direction.
Installing the Halo agent for CoreOS
Users can easily install the Halo agent as a container for the CoreOS host. It’s quite similar to installing the agent for any other operating system. In the Halo portal, navigate to and select the group where you want the new server to appear. On the actions menu, click add servers. In the install agent dialog select: distribution type ands agent as the container and host server OS as CoreOS. This is shown in the screen capture below.
On the remote server, execute the script. If you want to customize the script with additional parameters, see Customize the CoreOS Installation Script. After you run the script on the server, the container agent is installed. In the Halo portal, the server is automatically assigned to the group that you navigated to in the first step. You can verify the installation by navigating to the group, clicking the server view tab, and verifying that the server appears in the servers view. If it is there, the installation was successful.
Create CSM policy based on pre-existing template
Once container agent is installed, users can choose to create a new configuration policy or clone it from the pre-existing CoreOS template. Currently CIS benchmark for CoreOS is not available and this CSM template is based on CoreOS best practices. The pre-existing CoreOS template contains around 40 rules. Like any other CSM template users can configure these rules to suit their needs. Some example rules are below:
- Check update Services (Rule 4.1.02)
There are two critical services controlling updates and reboots in CoreOS. They’re update-engine.service and locksmithd.service. Update-engine.service takes care of periodically checking for updates from the appropriate release channel specified. This rule is to make sure these two critical services are running.
- Check update reboot strategy (Rule 4.1.03)
Make sure the reboot strategy is configured to allowed values. The value of the field “reboot-strategy” determines what CoreOS will do after the update. It should be set to one of the following values: reboot, etcd-lock, or best-effort .
- Check release channel (Rule 4.3.01)
CoreOS contains release channels. One of the things a release channel does is it controls when updates occur. You must ensure that an allowed release channel is being used.
Some other notable CoreOS rules are to check the OS version (Rule 4.1.01), check user core is not in docker group (Rule 4.4.01), and check user core is not in rkt group (Rule 4.4.02).
In one of our previous blog posts we covered five key items organizations should focus on when it comes to container security. One of the most critical items is securing the hosts containers run on, and we can’t stress enough that containers are only as secure as these hosts. In addition to container image security, today’s release of CoreOS with predefined security templates will add all the more ammunition to your security defense arsenal.