Skip to main content
Star us on GitHub Star

Policies

Ziti policies control which identities can access or host which services via which edge routers. There are three kinds of policies, and we'll walk through what kind of access each policy type grants, as well as walk through some use cases.

Each policy type relates two of the following entity types: identities, services and edge routers.

image

Service Policies​

Service policies are entities within the controller which provide identities authorization to services.

image

There are two kinds of service policies:

  • Dial policies, which control who can use a service
  • Bind policies, which control who can provide a service

They are separate because in most cases a given identity will not both use and provide any given service, so it's important to be able to distinguish between the two privileges.

Service policies are how access to application can be segmented. Each service (and corresponding application) can be accessed only by the identities which are given access to it. An identity can have access to any number of services, and it is straightforward to add or remove identities from service policies. With roles and role attributes (described below), it's easy to group entities and minimize manual maintenance of groups.

Having at least one Service Policy is vital because without any service policies the Ziti network will have no identities authorized to send traffic over the Ziti network.

Edge Router Policies​

Edge router policies are entities within the controller which provide identities access to edge routers. In order to access or provide a service the identity must first access the Ziti network fabric. Edge routers are the points through which SDK based applications can get that access.

image

Not every identity should necessarily be allowed to use every edge router. Identities or groups of identities may have dedicated edge routers for a number of reasons.

  • For resource isolation due to SLAs
  • For resource isolation because they are hosting a service
  • Edge routers may be colocated with a set of identities
  • A group of identities may need to use a particular version of an edge router

Having at least one edge router policy is necessary because without at least one, no identities will be able to send traffic over the Ziti network because traffic must enter the network via an edge router.

Service Edge Router Policies​

Service edge router policies are entities within the controller which provide services access to edge routers. They are similar to edge router policies except they determine via which edge routers a service can be used or provided.

image

There are a few reasons you might want to have pools of edge routers dedicated particular services or service groups.

  • Resource isolation due to SLAs
  • Geographic/political boundaries. Some services may need to be accessible only from specific areas to comply with local laws

Having at least one Service edge router policy is vital because without at least one, no services will be able to accept traffic over the Ziti network because traffic must enter the network via an edge router.

Roles and Role Attributes​

In order for policies to work they need a way to specify which entities to include in the policy. All Ziti policies work the same way.

  • The entities included in policies (identities, serviced and edge routers) can all be assigned role attributes
    • For example: an identity could be given the attributes sales, eu if that identity belongs to a sales person from the European Union
  • Each policy has two list of roles, one for each entity type that the policy is relating
    • Service policies have identityRoles and serviceRoles
    • Edge router policies have identityRoles and edgeRouterRoles
    • Service edge router policies have edgeRouterRoles and serviceRoles
  • Each list can contain role attributes, which are prefixed by hash tags, and ids, which are prefixed with at-symbols.
    • For example: a service policy might have
      • identityRoles = [#sales, #north-america, @81cc68d0-700a-491f-8e98-4b43a0b30a9f]
      • serviceRoles = [#office, @738006f2-e33e-4964-945f-7431000d229f]
    • Note that external tools such as the CLI and the ZAC will likely use names instead of IDs. So the roles might instead look like
      • identityRoles = [#sales, #north-america, @jsmith-laptop]
      • serviceRoles = [#office, @crm-suite]
  • Each policy also has a semantic. The semantic dictates how multiple role attributes will be interpreted. [#sales, #eu] could mean every identity which has #sales and #eu, or it could mean every identity which has #sales or #eu
    • The allOf semantic will include only entities have all the listed role attributes
    • The anyOf semantic will include all entities that have any of the listed role attributes
  • No matter the semantic, any entities which are listed by @id will be included in the policy
  • There is a special role attribute #all which will include all entities of a given type. This is useful for simpler setups which may not be segmenting edge routers, as well as for development and testing.

Policy Interaction​

Important Note: When an identity is using a service, the identity and service must have at least one on-line edge router in common in order for a connection to be made.

When an identity is trying to establish an API Session to use or host a service, the Ziti controller will verify that they access via service policy. Once the API Session is established, the controller will return a list of edge routers that the identity can use to connect to that service. The list will be all edge routers which both the identity and service have access to. It is possible that an identity may have access to a service and access to edge routers, but none of those edge routers can be used to access that particular service.

Policy Advisor​

To help diagnose issues there is a policy advisor API which the CLI has a wrapper for.

$ ziti edge policy-advisor services -q
OKAY : simple-client (1) -> simple (1) Common Routers: (1/1) Dial: Y Bind: N 

OKAY : simple-server (1) -> simple (1) Common Routers: (1/1) Dial: N Bind: Y

$ ziti edge policy-advisor services ssh simple-client -q
ERROR: simple-client (1) -> ssh (1) Common Routers: (1/1) Dial: N Bind: N 
  - No access to service. Adjust service policies.

The policy advisor can look at all services or identities, or a specific service and identity, and see if there are any common problems, such as:

  • Does an identity not have access to any services?
  • Does a service have no one who can access it?
  • Do a service and identity have no edge routers in common?
  • Do a service and identity have edge routers in common, but they are all off-line?

Managing Policies​

Creating a Service Policy​

  1. On the left side nav bar, click "Ziti Policies"
  2. On the top nav bar, click "Service Policies"
  3. In the top right corner of the screen click the "plus" image to add a new Service Policy
  4. Choose a name for the Service Policy, such as "My Service Policy"
  5. Select "Dial" or "Bind" in the Type dropdown
    1. Dial policies allow identities to use or connect to the service
    2. Bind policies allow identities to host or provide the service
  6. Enter the services you want to include in the policy
    1. Specific services can be referenced by ID or name using @. For example, a service called ssh can be referenced using @ssh.
    2. Services can be referenced by role attribute using #. For example, any service which has the sales role attribute will be included if #sales is included in the service roles list.
  7. Enter the identities you want to include in the policy
    1. Specific identities can be referenced by ID or name using @. For example, as identity called jsmith-desktop can be referenced using @jsmith-desktop.
    2. Identities can be referenced by role attribute using #. For example, any identity which has the sales role attribute will be included if #sales is included in the identities roles list.
  8. Specify the role semantic
    1. If you select Has Any Role then if you specify multiple roles then all entities which include any of the roles will be included.
    2. If you select Must Have All Roles, then if you specify multiple roles then only entities which include all of the given roles will be included
  9. Click save

Creating an Edge Router Policy​

  1. On the left side nav bar, click "Ziti Policies"
  2. It should already be selected, but if not, on the top nav bar, click "Edge Router Policies"
  3. In the top right corner of the screen click the "plus" image to add a new edge router policy
  4. Choose a name for the edge router policy, such as "My edge router policy"
  5. Enter the edge routers you want to include in the policy
    1. Specific edge routers can be referenced by ID or name using @. For example, an edge router called us-east-4 can be referenced using @us-east-4.
    2. Edge routers can be referenced by role attribute using #. For example, any edge router which has the us-seast role attribute will be included if #us-east is included in the edge routers roles list.
  6. Enter the identities you want to include in the policy
    1. Specific identities can be referenced by ID or name using @. For example, as identity called jsmith-desktop can be referenced using @jsmith-desktop.
    2. Identities can be referenced by role attribute using #. For example, any identity which has the sales role attribute will be included if #sales is included in the identities roles list.
  7. Specify the role semantic
    1. If you select Has Any Role then if you specify multiple roles then all entities which include any of the roles will be included.
    2. If you select Must Have All Roles, then if you specify multiple roles then only entities which include all of the given roles will be included
  8. Click save

Creating a Service Edge Router Policy​

  1. On the left side nav bar, click "Ziti Policies"
  2. On the top nav bar, click "Service edge router policies"
  3. In the top right corner of the screen click the "plus" image to add a new Service edge router policy
  4. Choose a name for the Service edge router policy, such as "My Service edge router policy"
  5. Enter the services you want to include in the policy
    1. Specific services can be referenced by ID or name using @. For example, a service called ssh can be referenced using @ssh.
    2. Services can be referenced by role attribute using #. For example, any service which has the sales role attribute will be included if #sales is included in the service roles list.
  6. Enter the services you want to include in the policy
    1. Specific services can be referenced by ID or name using @. For example, a service called ssh can be referenced using @ssh.
    2. Services can be referenced by role attribute using #. For example, any service which has the sales role attribute will be included if #sales is included in the service roles list.
  7. Specify the role semantic
    1. If you select Has Any Role then if you specify multiple roles then all entities which include any of the roles will be included.
    2. If you select Must Have All Roles, then if you specify multiple roles then only entities which include all of the given roles will be included
  8. Click save