Application Membership Control with CloudPassage Halo

Let’s face it- nobody’s production environment is completely pristine and secure.  Ideally, we try to embrace security as a cultural component or state of mind, and we create processes to cover our asse(t)s and hope that we don’t hobble our productivity in the process. Security Automation (SA) and Software-Defined Security (SDSec) are the new hotness, but what do those buzzwords mean to the people who have to translate a broad concept into a process that makes them more effective?  To help us illustrate the practical application of these broad and somewhat abstract terms we’ll draw parallels with older and more established concepts.  Within the IT and infrastructure management disciplines there exists the concept of Network Access Control, or NAC.  One of NAC’s purposes is to validate that the connecting host complies with the company’s security policy before being admitted to the network.  Translating that concept to the cloud, we’ll introduce the concept of Application Membership Control with CloudPassage Halo by automating the admission of workloads into a tightly-controlled application environment, but only if they’re compliant with your configuration policies.

Here’s the use case:  The Company has a tiered web application that is subject to various security-focused compliance initiatives.  You don’t get much warning when the operations team needs to add more workloads to the production application pool- when they have more to add, you must ensure that they are compliant and get them into production ASAP.  To keep your workloads separated, the unverified hosts are auto-provisioned into a server group in Halo which only allows access from individuals in the security and operations groups.  Once the workloads are verified “clean”, they are moved into the production server group, where they are granted network access to other resources in the production application.

We’ll start with an environment that has a separate production and staging group for each workload role.  The staging groups are for unverified, or presumed “dirty” workloads.  The production groups should only contain verified “clean” workloads.  For the sake of this demonstration, we’ll focus on the Web Server role.  To manage these two types of workloads (dirty and clean), we’ll use two aptly-named groups: ProdWebDirty and ProdWebClean.

Environment specifics:

  • ProdWebDirty and ProdWebClean have the same configuration policies applied
  • ProdWebDirty workloads are only accessible to the engineers responsible for configuring them for production use and cannot talk to any other parts of the application environment.  This access requirement will be managed using Halo’s Workload Firewall Management module.


  • We want every workload that goes into the ProdWebClean group to pass all applicable configuration security policy checks.
  • We don’t want to manually verify and move all of those workloads to the ProdWebClean group.

Halo has an API that makes automating this sort of thing pretty straightforward. We created a python script that:

  • Builds a list of all workloads in the source group
  • Causes all workloads in the source group to run all applicable configuration policy checks
  • If the workload passes, moves it to the destination group
  • If it fails, it stays where it is

This is what Software-Defined Security is all about: automating the mundane as much as is practical so that you can focus on the stuff that only a human should do.

Continuing with the lab exercise…

  1. Log in to the CloudPassage Halo portal and create three groups, ProdWebDirty, ProdWebClean, and CriticalApplication. (Find a link to the CloudPassage Halo Quick Start Guide here)
  2. Add the text ’NewDirty’ to the Server Tag field for ProdWebDirty and apply the ‘OS Core (RPM-based Linux) v3’ policy to all three groups.   You may need to clone this from a template (Templates and Tools > Configuration Policy Templates) if you haven’t already.
  3. Create a firewall policy for the CriticalApplication group. The CriticalApplication group should specifically drop all traffic from the ProdWebDirty group, and (implicitly) allow all traffic from ProdWebClean.  No, this isn’t a production-worthy ruleset… it’s just enough to prove a point!
    Just block the dirty hosts
  4. Create three CentOS 6.5 workloads in your favorite public cloud.
  5. In the CloudPassage portal, navigate to Servers > Install Linux Daemons and follow the links to download the script for installing Halo on CentOS.
  6. Copy the script to each of your workloads.
  7. Run the script as-is on one workload, which goes into the CriticalApplication group. Place it there manually using the Halo portal.
  8. On the other two workloads, edit the last line in the script:
    sudo /etc/init.d/cphalod start –daemon-key=YOUR_DAEMON_KEY_GOES_HERE
    To be:
    sudo /etc/init.d/cphalod start –daemon-key=YOUR_DAEMON_KEY_GOES_HERE —tag=NewDirty
  9. Run the Halo daemon installation script on the remaining two workloads and notice that they’re automatically provisioning into the ProdWebDirty group.
  10. Using SSH to log into each host in the ProdWebDirty group, start a continuous ping to the workload in the CriticalApplication group. You should be getting timeouts in both sessions.
  11. Download the project from the CloudPassage GitHub Toolbox and unpack it on a system running Python 2.7. Edit the configuration file, adding your API key and secret. Kick off the program with
    python -s ProdWebDirty -d ProdWebClean
    No clean hosts detected
    Above, we see that both workloads failed to complete configuration checks without errors.
    In the image below, one failed and the other passed and was summarily moved to the destination group.
    Hint: If you have trouble making one of your workloads pass, double-check the syslog package that the policy is looking for- you may need to either disable the default check and enable one of the other checks to match the syslog package installed by default, or change the installed syslog package on the workload to match what the policy is looking for.
    One clean host detected and admitted to the application
    If things go as expected, you’ll see the one passing workload will be able to successfully ping the workload in the CriticalApplication group:
    Top is CriticalApplication, middle passed and was moved to the production group, bottom failed and cannot reach the CriticalApplication

If your workloads don’t pass the config check, they’ll not be moved. If they do pass, you’ll see output from the script to that effect, and you’ll begin to see ping replies in your SSH sessions we started earlier. If they don’t pass, have a look at the report in the portal and adjust your workloads’ configuration settings as appropriate to get a pass. Wash, rinse, repeat.  In the real world, you would probably forward an email report of the policy failure to the engineer responsible for configuring the workload or automatically generate a support ticket.

The real-world utility of this demonstration is to show that you don’t have to drop everything you’re doing if a production application needs to have hosts vetted before admission to the appropriate tier-group.  Just as NAC allows the admission of compliant machines to a network, Application Membership Control with CloudPassage Halo enables you to automate the admission of verified clean workloads into a protected application environment.

Stay up to date

Get the latest news and tips on protecting critical business assets.

Related Posts