Access policy

The access policy is the set of rules that decides which devices on your TxNet may connect to which. It is the main way to keep, say, laptops away from your database servers while still letting admins reach everything. Admins and owners edit it under Settings → Access policy.

How it works#

• No policy yet means everything is allowed. A new TxNet has no saved policy, so every device can reach every other device. The editor starts with a single rule that says exactly that.
• Once you save a policy, anything not allowed is blocked. Traffic only flows when a rule allows it.
• Rules are read from top to bottom. The first rule that matches the traffic decides whether it is allowed or denied. Rules further down are not checked for that traffic. If no rule matches, the traffic is denied.
• Changes apply to every device within seconds. You don’t need to restart anything.

A rule has a Source (who starts the connection), a Destination (what they connect to, with ports) and an action: accept or deny. Replies to an allowed connection always get back, so you only write rules in the direction the connection starts.

What you can put in a rule#

Destinations end with the ports after a colon: tag:server:22 for one port, tag:web:80,443 for a list, tag:app:8000-8100 for a range, and * for all ports (tag:server:*, or *:* for everything).

Edit the policy#

Open Settings → Access policy. You can switch between two views of the same policy at any time:

• Visual: forms for rules, groups, host aliases and tags. Best for most changes.
• JSON: the policy file itself, policy.json. Handy for copying a whole policy, or for bigger edits. Comments starting with // are allowed.

Add a rule

1. On the Rules tab, click Add rule.
2. Pick one or more entries for Source and Destination. The lists suggest the groups, tags, people and hosts your TxNet already has.
3. Choose accept or deny.
4. Drag the rule to the right place. Put narrow deny rules above broad accept rules, or they will never be reached.
5. Click Validate to check for mistakes, then Save.

The editor greys out a rule that can never match because a rule above it already decides the same traffic, and says which one. A policy with errors is not saved, so you can’t lock everyone out with a typo.

Groups, hosts and tags

• Groups (Add group): a name for a set of people, such as group:engineering. Members are email addresses or other groups.
• Hosts (Add host alias): a friendly name for an IP address or range, such as office-lan for 192.168.1.0/24.
• Tags (Add tag): declare a tag such as tag:server and list its Owners, the people allowed to put that tag on a device. See Tags and tag owners.

Test before you save#

Under Test this policy on the Rules tab, you can ask whether a connection would be allowed. It tests the policy as it is in the editor right now, so you can try changes before saving them.

1. Enter a Source: a person’s email, a tag, an IP address or *.
2. Enter a Destination: a host alias, an IP address or a tag.
3. Optionally enter a Port. Leave it blank for any port.
4. Click Evaluate. The answer names the rule that decided, for example “Allowed by rule 2”, or says “Denied — no matching rule (default deny)”.

Tags and tag owners#

Tags describe what a device is for, such as tag:server or tag:printer, instead of who owns it. They are the best way to write rules for shared machines.

• A tag must be declared in the policy, with owners, before anyone can use it. Owners can be email addresses, groups, or autogroup:admin (every admin and owner of the TxNet).
• Admins and owners can put any declared tag on any device. Other people can only use tags they own.
• Add a tag to a device from its page in Machines with Manage Tags, through an enrollment key that carries the tag, or when connecting from the command line:

$ sudo txhub up --advertise-tags=tag:server

Examples#

Members reach the servers, admins reach everything

Admins get full access, everyone else can reach the web and SSH ports on servers, and all other traffic is blocked:

{
  "groups": {
    "group:admins": ["ada@example.com", "bjorn@example.com"]
  },
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    // Admins can reach every device on every port
    { "action": "accept", "src": ["group:admins"], "dst": ["*:*"] },
    // Everyone can reach servers on HTTPS and SSH
    { "action": "accept", "src": ["*"], "dst": ["tag:server:443,22"] }
  ]
}

Block one network for a group

Because the first matching rule wins, a deny rule placed above a broad accept rule makes an exception:

{
  "groups": {
    "group:contractors": ["sam@partner.com"]
  },
  "hosts": {
    "finance-lan": "10.20.0.0/16"
  },
  "acls": [
    { "action": "deny", "src": ["group:contractors"], "dst": ["finance-lan:*"] },
    { "action": "accept", "src": ["*"], "dst": ["*:*"] }
  ]
}

Exit nodes, subnet routes and applications#

• Subnet routes: a route only works for people a rule allows to reach those addresses. Use the network range, or a host alias for it, as the destination, for example office-lan:*. See Subnet routes.
• Exit nodes: to send internet traffic through an exit node, a rule must allow autogroup:internet as a destination, for example autogroup:internet:*. It covers public internet addresses only, never your own devices or private ranges. See Exit nodes.
• Applications: devices on your TxNet can always reach the applications you set up under Settings → Applications, through their gateway. You don’t need a rule for that. See Applications.

A rule with *:* as its destination also covers subnet routes and exit node traffic.

Good to know#

• A rule that names a declared group or tag that no device has yet is accepted. It simply does nothing until a device matches.
• The page shows when the policy was last updated and by whom, so you can tell who made a change.
• A policy can hold up to 1,000 rules.
• The policy controls what devices can reach. It does not change who can use the dashboard. That is set by roles, see Organizations and users.