checkpoint adapter

Environment Variables

Name	Default	Description
CHECKPOINT_TIMEOUT	600	Timeout for long running checkpoint operations such as PolicyInstall and RunScript

Usage example

This example shows how to deploy 2 checkpoint hosts and drop any packet using port 443 from host 1 to host 2.

import checkpoint

credentials = checkpoint::Credentials(
    host="6.6.6.6",
    username_env_var="MY_USER_ENV_VAR",
    password_env_var="MY_PASS_ENV_VAR",
)

host1 = checkpoint::Host(
    ip_address="1.1.1.1",
    name="test_host1",
    security_groups=[],
    credentials=credentials,
)

host2 = checkpoint::Host(
    ip_address="2.2.2.2",
    name="test_host2",
    security_groups=[],
    credentials=credentials,
)

service = checkpoint::TCPService(
    name="https",
    port=443,
    credentials=credentials,
)

rule = checkpoint::Rule(
    name="test_rule",
    layer="vsx-gw-1_p Network",
    position="top",
    position_reference_object="inmanta",
    source=[host1],
    destination=[host2],
    action = "Drop",
    services=[service],
    credentials=credentials,
    purged=false,
)

checkpoint::PolicyInstall(
    policy_package = "vsx-gw-1_p",
    targets = ["vsx-gw-1"],
    credentials=credentials,
    overwrite = true,
)

Design limitations

PolicyInstallV2

The model contain an entity named PolicyInstall. This one is responsible to applying a new policy install to the checkpoint every time any of its dependency deploys anything to the checkpoint.

Condition If overwrite attribute is not set to true (false by default), the policy install will only occur if one policy with a matching name was already present on the target. This is to ensure that we do not overwrite any policy installation.

Dependencies A policy install has different resources as dependencies, their actions dictate its behavior. Those dependencies are passed to the requires attribute of the PolicyInstall entity.

Authentication When using authentication on the orchestrator this version of PolicyInstall can not be used out of the box. Because is uses in its handler a client requiring api permissions, which would require an authentication token to communicate with the orchestrator. You will then need to create a configuration for the client used by the handler. You can start from the example below, replacing the values that need replacing, and put this in a config file where the server can reach it (for example /etc/inmanta/inmanta.d/policy_install.cfg)

[policy_install_rest_transport]
host=localhost
port=8888
token=<your-token>

To generate the token, you can go to the settings of your environment and at the bottom of the page, check the box api and click on the Generate button.

Normal behavior Here is the behavior of the entity under normal circumstances:

1. One resource (dependency of policy install) is created: after its deployment finishes, a new policy install is done.

2. One resource (dependency of policy install) is updated: after its deployment finishes, a new policy install is done.

3. One resource (dependency of policy install) is removed: after its deployment finishes, a new policy install is done.

Corner cases Here is the behavior of the entity in some corner cases:

1. The policy has never been installed: it will be installed, regardless the fact it might not have dependencies.

2. The last policy installation occurred further in time that the server can remember: it will be installed, regardless the fact it might not have dependencies.

PolicyInstall

The model contain an entity named PolicyInstallRobust. This one is responsible to applying a nex policy install to the checkpoint every time a new version is deployed to the orchestrator if the policy install has dependencies.

Condition If overwrite attribute is not set to true (false by default), the policy install will only occur if one policy with a matching name was already present on the target. This is to ensure that we do not overwrite any policy installation.

Dependencies A policy install has different resources as dependencies, their actions dictate its behavior. Those dependencies are passed to the requires attribute of the PolicyInstallRobust entity.

Normal behavior Here is the behavior of the entity under normal circumstances:

1. A new version of the model is created, with dependencies for the policy install, the policy install is done.

2. A new version of the model is created, with no dependencies for the policy install, the policy install is not done.

Lazy start and stop

With the addition of the lazy_start and lazy_stop attributes to CheckpointClient, we are able to cache our current session and only login or logout when we need to. With lazy_start enabled, we only actually login when we get the connection and there is no _session_uid that was previously assigned. With lazy_stop enabled, we only logout when we delete the session from the cache or close a dirty/edited session.

• Module checkpoint
• Changelog