Understanding Policies and Granular Access Control in OpenZiti

Hello,

I'm trying to better understand how policies work in OpenZiti. Specifically, I'm looking for documentation or explanations on service access and granular permissions.

I noticed that using @all @all seems to grant access to everything, but I'm not entirely sure why this is necessary. My understanding is that access is granted to services through specific ports, so I’m struggling to grasp why we need to explicitly define such broad permissions.

Could someone clarify the reasoning behind this approach? Additionally, how can we implement more granular access control effectively?

Thanks in advance for your help!

Hi @Dejan60,

There is no one #all/#all policy. Instead, OpenZiti requires you to:

  • Authorize identities to connect to routers
  • Authorize services to use routers as onload or offload routers
  • Authorize identities to use services

So -- to grant "everything" access you would need to:

  • make an edge-rotuer-policy that grants #all identities access to #all routers
  • make a service-edge-rotuer-policy that grants #all services the privilage to use #all routers as onboard or offload locations
  • make a 'service-policy' that grants #all identities access to #all services

You would have had to do all these things. You can conversely, remove all these policies and use very fine-grained access if you like.

So, one all/all policy won't grant you access to everything, you need to make three of these policies. Practically, if you don't have all three, you'll still have access to nothing.

It's often easiest when starting out to make two blanket all/all policies: edge-router-policy and service-edge-router-policy and then use service-policies to control access to resources/services.

that help?

Overview of Policies | OpenZiti you might find helpful

There are different types of policies that bind different elements. I visualize it as a triangle. Service policies bind identities to services. This is by far the most common type that is done specifically and granularly. Edge router policies bind identities and edge routers, affecting what identities can utilize which edge routers to attach to the edge, and service edge router policies, which bind services and edge routers, which edge routers can act as an ingress for which services.

The last two are almost always all/all. There are very uncommon situations they might be used, but not generally. The first types, service policies, are where the granular access is applied. Identities can either dial (access) or bind (host) services, per the service policy. So you may have a web application that you want to secure. Alice's endpoint, but direct (@) or indirect (#) is associated with the service in the policy. Bob's endpoint is not. Alice can access the service, and Bob cannot.

Ports are part of intercepts defined in the configurations, so one can define a service configuration that only allows access to a single port, say 443, or a group, including all (1-65535) . This way, you could grant Alice access to the web front end as a user, and Bob access to the SSH port on the same system, one for usage, and one for administration, for example. To do this, you would create two different services, and using the policy as above, associate the endpoints to the respective services.

For people starting to understand, I suggest the Minecraft Blog It walks you through step by step, and can really help you get a handle on it.

Thank you for your answers, it helps to understand better. One more question but in relation to ZAC some things are in RED and others in BLUE really sorry if this has already been mentioned
I remember a documentation page talking about @ and # but I can't find it anymore

I don't know what you mean. Maybe a screen shot? Also -- probably should be a different topic

sorry for the late answer

image

in policy have there are settings in red and others displayed in blue. I think if I'm not mistaken that in blue it's traffic?

The red pills are direct references to singular identities/routers/services using an @ symbol. The blue pills are attribute references, so identities/routers/services with that attribute on them using the # symbol.

1 Like