Assimilation Versus Orchestration Tools Like Chef or Puppet?

orchestration tools deployment tools

A question I get asked fairly often is “How is the Assimilation Suite different from orchestration tools like Chef, PuppetAnsible, or SaltStack?” The short answer is that we have a different and complementary mission. The rest of this article goes over how we complement them in more detail.

What are Orchestration Tools?

Collectively these tools and others like them are called orchestration tools or deployment management tools. They are key components of configuration management. In it’s simplest form, configuration management consists of three phases:

  1. Specification of configuration
  2. Construction according to configuration specification
  3. Validation of constructed configuration

Where orchestration tools really shine is in step 2. In most cases, they also provide a method of creating an initial configuration from the existing state of the universe in order to get started. This covers step 1.

The primary goal of all of these tools is the Construction step – which is where they put most of their effort. Since getting systems configured and updating their configuration consistently is painful, that’s a great thing to concentrate on. They perform tasks like “Install Tomcat” very well. This is a great high level view, but unfortunately the devil is often in the details. Details like “Tomcat needs Java” and “Java needs 125 other packages” can be ignored – because “Install Tomcat” implies these steps. If any of the other 126 packages has a security update, you may not know which systems need updating, because these dependencies are maintained by the vendor’s packaging system.

As a result, these orchestration tools have an incomplete picture. An incomplete picture is more than good enough to correctly deploy the software. By contrast, the Assimilation Suite’s purpose in life is to discover and continually keep this kind of detailed data like all the packages installed up to date in our database. As a result, our information is as complete as you could want and always up to date.

There are also things orchestration tools can’t control – like hardware configuration or network connectivity, which are important to know, but outside their mission. These kinds of things are well within the scope of the Assimilation Suite.

Occasionally, administrators bypass the orchestration tools. Maybe they were solving an urgent problem, maybe the tool has a limitation, maybe they don’t know the tool well enough. But it’s a commonly reported situation that orchestration tools occasionally get bypassed. When that happens, the recorded configuration is incomplete or incorrect.

What About Security in Orchestration?

Unrecorded configuration changes might have been made for a good reason, or they might have been made by an attacker. It’s worth noting that none of these steps in configuration management intentionally covers security in any way. With the Assimilation suite, managing security is one of our primary goals.

In addition, the orchestration tools can’t easily answer questions like “What services are active on this machine?” or “What port is Apache listening on?”, or “What does the attack surface of machine X look like?” or “What services is this machine using?”. They simply don’t have that kind of information readily available – if at all. This extends to the effects of malware. If malware is listening on a port, or communicating, they are invisible to orchestration tools but show up in our database.

And, of course, there’s the biggest weakness of orchestration tools – they can only manage systems they’re told about. Many organizations don’t have a good inventory of their systems. The result of this is that 30% of all break-ins from the outside come through systems that aren’t on the books. If you have a good inventory, then you can reduce your chances of getting hacked significantly. The Assimilation System knows all the IP and MAC addresses in your network – and keeps that inventory up to date continually. If an IP address is active for even a few seconds, it will appear in our database.

Validating Orchestration Configuration

Part of security is to ensure that systems are following certain configuration rules. They say things like “Make sure stack execution is disabled”, and dozens or even hundreds of other similar rules. These are difficult to validate at best when starting from an orchestration tool’s configuration.

The way to understand the difficulty of this task is that these systems in most cases follow the mantra of infrastructure as code quite literally. How you then have to validate that you’re following these rules is to validate that all the pieces of code that construct all these system and application configuration files all do what you intended. This is a classic complex (NP-hard) task. It’s much easier just to query a database to see how things are configured. Of course, that doesn’t even count that your security team might think you didn’t configure it correctly at all. Given the number and complexity of security rules from places like the IT Best Practices site, regulatory requirements, and internal policies, it’s not surprising that everyone doesn’t know all the rules.

Assimilation Just Cares About What Is

The Assimilation system doesn’t know or care how things got how they are, it simply looks at what is, and that’s what we put into the Assimilation database. It validates that your actual running system configurations match what you and your security team intended.

There are other things that security is interested in that orchestration tools are unaware of – things like checksums of binaries for system integrity. If an attacker replaces ssh with a hacked version, that’s visible to the Assimilation software. So if you notice that 99 copies of /usr/bin/sshd are identical and one is different, maybe that’s something worth looking into ;-). Unfortunately, orchestration tools are of no help for this.


The differences between orchestration tools and what the Assimilation Suite does flow out of different missions.

  • Orchestration tools don’t primarily aim at covering security
  • Orchestration tools can’t validate configuration against external rules
  • Orchestration tools rely on having a correct and complete inventory
  • Orchestration tools have a less complete and sometimes incorrect view of the world
  • Orchestration tools are optimized for creating configuration, not querying it

As a bonus, the Assimilation suite also monitors servers and services for correct operation, replacing tools like Nagios.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

You have to agree to the comment policy.

This site uses Akismet to reduce spam. Learn how your comment data is processed.