Read Ript rules from JSON

[auxesis]

The Ript DSL is pretty much just a nested set of method invocations:

partition "bar" do
  label "www.bar.com",    :address => "172.23.0.95"
  label "barprod-web-01", :address => "192.168.19.2"
  label "barprod-web-02", :address => "192.168.19.4"

  rewrite "bar.com public website" do
    ports 80
    dnat  "www.bar.com" => "barprod-web-01"
  end

  rewrite "bar.com public website" do
    ports 22
    dnat  "www.bar.com" => "barprod-web-02"
  end
end

We could in theory represent this as JSON:

{
  "partition": {
    "name": "bar",
    "labels": {
      "www.bar.com.au": {
        "address": "172.23.0.95"
      },
      "barprod-web-01": {
        "address": "192.168.19.2"
      },
      "barprod-web-02": {
        "address": "192.168.19.4"
      }
    },
    "rules": [
      {
        "rewrite": {
          "ports": 80,
          "dnat": {
            "www.bar.com": "barprod-web-01"
          }
        }
      },
      {
        "rewrite": {
          "ports": 22,
          "dnat": {
            "www.bar.com": "barprod-web-02"
          }
        }
      }
    ]
  }
}

This would allow other systems to generate JSON that Ript could consume, and allow for dynamic rule generation through configuration management or customer portals.

[jdub]

On 31/01/2013, at 11:09, Lindsay Holmwood notifications@github.com wrote:

We could in theory represent this as JSON:

Yyyyyyyyeeeeessssss!

[auxesis]

One other thing to consider - we could turn the existing DSL rules into JSON by implementing a .to_json method on each partition instance.

This would provide people a migration path from DSL rules to JSON rules.

[auxesis]

@ycros also suggested implementing a method to include a block of JSON within the DSL, along the lines of:

partition "bar" do
  label "www.bar.com",    :address => "172.23.0.95"
  label "barprod-web-01", :address => "192.168.19.2"
  label "barprod-web-02", :address => "192.168.19.4"

  include_json 'path/to/partition.json'
end

[auxesis]

@johnf and I were talking about this. It might make sense to:

• separate the DSL entirely from Ript
• have the DSL generate JSON
• rewrite the existing DSL parser to read JSON

This is good because:

• people can use the DSL when starting out with Ript, or for really simple cases like standalone host-based firewalls
• we don't have to support building up the data structures using two separate methods (parsing DSL + parsing JSON)
• we can cleanly support reading rules from multiple sources
• in environments where you have rules for multiple sets of firewalls in a single repository, you don't have to ship the whole repository containing all the rules (a potential source of information for attackers if one of those firewalls is owned)

Image the following orchestration use case:

• run mcollective client to compile rules for a firewall pair, which outputs JSON
• push the JSON to the target machines
• have the secondary member apply the JSON, but bail if there are errors
• have the primary member apply the JSON

This is much simpler than instructing each agent to git pull the rules and run ript rules apply

[andys]

👍