IAM Policy

Identity and Access Management (IAM) Policy is a way to describe who and what can access resources within an Organisation.

For example, a policy might describe a number of Users as a Group, and that Group may only be permitted to access certain servers or other resources within the Organisation.

Resources in an Organisation are scoped to:

• Endpoints
• Tags
• Users
• Groups

Human JSON

A policy document is written using "Human JSON", which allows comments to help explain the rules in the policy.

The rules in a policy are additive. When a rule for an attempted connection does not exist, the connection is refused.

Groups

Users may be grouped together in a policy document to simplify access rules.

Groups

{
    "acls": [...],
    "groups": {
        "devops": [
            "[email protected]",
            "[email protected]",
        ],
        "employees": [
            "[email protected]",
            "[email protected]",
            "[email protected]",
        ]
    }
}

ACLs may now use these Groups to ensure that only authorised Users can access certain resources, instead of having to specify individual User IDs repeatedly.

Tags

Endpoints may be grouped together using Tags. As with Groups, this helps simplify access rules in a policy. Tags are defined separately to the IAM Policy.

Access Control Lists

Access Control Lists (ACL) within the policy describe the permitted connections between Endpoints. Each ACL must contain an Action (action), a Source (src), and a Destination (dst).

The only supported Action is accept and allows a connection matching the ACL.

Additional Actions

Additional Actions may be added in future versions.

A Source or Destination is an array of resources. The different types of resource are described later in this article.

The most basic policy, with no ACLs specified, means that no connections will be permitted:

Basic Policy

{
    "acls": []
}

The default policy applied to a new Organisation permits all connections within the Organisation:

Default Policy

{
    "acls": [
        // Everything can talk to everything else
        {
            "action": "accept",
            "src": ["*"],
            "dst": ["*"]
        }
    ]
}

The diagram below is an example of the default policy - all Endpoints can communicate:

Resources

The Source and Destination fields are arrays of resources. Supported resources are:

• user: a single User
• group: a Group of Users
• endpoint: an Endpoint in Connect
• tag: an Endpoint Tag
• *: a wildcard, matching "all"

Additional Resources

Additional resources may be added in future versions.

ACL Examples

The examples here expand on the most basic policies shown above.

Multiple ACLs may be specified in the policy. The example below shows two ACLs.

Multiple ACLs may be specified

{
    "acls": [
        // [email protected] can access everything on Endpoint bob-desktop
        {
            "action": "accept",
            "src": ["user:[email protected]"],
            "dst": ["endpoint:bob-desktop"]
        },
        // Users in Group ops can access everything on Endpoint ops-server
        {
            "action": "accept",
            "src": ["group:ops"],
            "dst": ["endpoint:ops-server"]
        }
    ]
}

Tags may be used to simplify the rules. The example below allows connections between all machines tagged with lab.

Specify Endpoints by Tag

// All lab Endpoints can talk to each other, but nothing else.
{
    "action": "accept",
    "src": ["tag:lab"],
    "dst": ["tag:lab"],
}

Combining Groups and Tags is a good way to control who and what can access other resources. The example below shows a specific User and a Group that are permitted to access all machines tagged with lab.

A mix of Users and Groups can access Tagged Endpoints

// Both [email protected] and the devops Group can access lab Endpoints.
{
    "action": "accept",
    "src": ["user:[email protected]", "group:devops"],
    "dst": ["tag:lab"],
}

Identity Providers

Groups may be defined in the policy document or by an external Identity Provider (IDP) such as Microsoft Entra ID.

See Use Microsoft Entra ID for IAM for how to configure your Organisation for use with Entra.

Once an IDP tenant has been created in an Organisation, Groups may reference them with the following syntax:

IDP Groups

// Users in Entra ID Group ops can access everything on Endpoint ops-server
{
    "action": "accept",
    "src": ["group:ops@tenant_name"],
    "dst": ["endpoint:ops-server"]
}

Where "tenant_name" is the name of a previously created IDP tenant.

A combination of IDP and policy-defined Groups is possible.

Further scenarios

Hub and spoke

A common scenario is the "hub and spoke" pattern, where Endpoints can communicate with a server, but not with each other.

In the example below, Endpoints which have been tagged with sales are permitted to communicate with the Endpoint named sales-server.

Hub and spoke pattern

{
    "acls": [
        // All endpoints tagged with sales can access the sales server
        {
            "action": "accept",
            "src": ["tag:sales"],
            "dst": ["endpoint:sales-server"],
        }
    ]
}

Separate environments with common admin

It is possible to isolate sets of Endpoints into separate environments, and yet retain administrative access from a common location.

Consider the example below. The sales Group can access the sales server, the lab machines can all communicate, and the admin Group can access the sales server and lab machines.

Separate environments with common admin

{
    "acls": [
        // All endpoints tagged with sales can access the sales server
        {
            "action": "accept",
            "src": ["tag:sales"],
            "dst": ["endpoint:sales-server"],
        },
        // Lab machines can communicate with each other
        {
            "action": "accept",
            "src": ["tag:lab"],
            "dst": ["tag:lab"],
        },
        // Admin Group members can access the sales server and the lab
        {
            "action": "accept",
            "src": ["group:admin"],
            "dst": ["endpoint:sales-server", "tag:lab"],
        }
    ]
    "groups": {
        "admin": [
            "[email protected]",
        ]
    }
}

---

See Also

• Manage IAM Policy
• Manage Tags
• Working with Entra
• Use Microsoft Entra ID for IAM