Hi all. At OSSYS we’re working with Styra and Open Policy Agent (OPA).
Are there plans for integration with OPA? If not, how are policy definitions handled? Thanks.
Hi @andrewzah, welcome to the community!
Right now, I don’t know of any plans for OPA integration. It has definitely been something that has come up in the past and discussed, but I don’t think we’ve had enough reason/motivation/rationale to integrate with it. I’d be interested to know if there is something you’d use OPA for with OpenZiti, or if you’re just wondering “in general”?
I think @andrew.martinez is probably the best person to provide additional details if there are any to share. Thanks again for the question and welcome.
Full disclosure - I’m an OPA/policy engine newbie.
From my understanding, OPA/Rego lang give us sophisticated control over user authorization, via policy decoupling. A typical example is managing access to REST apis.
For us, right now we’re connecting OPA to Trino to manage what schemas authenticated users can query, but we plan on using OPA for much more across our cluster.
Been tracking OPA for quite a while, and while it is interesting, there are a few technical hurdles that call into question how such a thing would be accomplished. I haven’t revisited this topic in the better part of a year - so I will try my best to recall what the previous version of me thought. I am also not on top of the most recent OPA developments. Please correct me where possible.
That said, it seems unlikely at this point. However, that is a weakly held position. If you want more in-depth reasoning about this topic, see below.
There are a few ways that OPA could be integrated into OpenZiti
- Internal Integration - Embed OPA into OpenZiti (via their GoLang library)
- External Integration - Allow an OPA instance to be referenced for policy
Internal Integration
This is the least likely path to move forward as it would require replacing all of the internals off OpenZiti’s policy system. This would only happen on a major version change, and it would raise questions on about migrating up versions. It is also the least in line with OPA’s goals - having a central location for policy management. Putting OPA directly in OpenZiti makes little sense as any OPA-powered shop would already have an OPA instance. A second one would provide some benefit from having similar tooling, but not as the intended single source of truth.
External Integration
There remains a core desire to make OpenZiti as small as possible to startup. OpenZiti only requires itself, no databases or external services. Having OPA as an external requirement goes against that ethos. However, it being optional is much more in the wheelhouse.
Making it optional means that OpenZIti must support a pluggable interface that allows different policy decisions. Unfortunately, OpenZiti wasn’t designed with this in mind. As such, this would be a new effort to introduce the policy API and rework the current system to work with it. It also raises some additional questions.
How does OpenZiti report policy information out, if at all? Different policy systems will have different APIs, and as such, it is easier to punt and decide that the “policy system decides the policy API.” This means that policy configuration between OpenZiti instances would be “policy plugin dependent.” This is not untenable. It does increase the scope of supported modes of operation and would fragment our CLI tooling partially or require yet-another-plugin system for that.
How does OpenZiti deal with complex policy model decisions? OPA supports two modes of policy resolution full and partial. Full policy resolution requires that OPA have all the data models required to make decisions. This means a near-full export and data synchronization - which is not enticing. Partial processing means that OPA returns unanswered questions, and it is up to OpenZiti to figure out the rest of the details. Neither solution is elegant, simple, or easy.
OPA also isn’t great at supporting CRUD API operations that filter on the model. Data goes into OPA, and it is used to make decisions. Querying it is not a strength nor its intended purpose. The best article I’ve seen on how this would work is how OPA prescribes integrating with SQL services. It did not invoke feelings of simplicity. OpenZiti also does not use SQL, it uses an internal key-value data store. So there would be work to generate an adaption layer for that.
Other DevOps systems that OPA works with out of the box reduce the complexity of what OPA does to more straightforward yes/no answers without data replication or supporting rich data APIs. Most of the tools OPA is aimed at do not rely on OPA in that manner. Tools like Kubernetes are aimed at back-office administrative management where the end-users of those tools request resources and are given yes/no answers. OPA developed its plugin for the Kubernetes Admission Controller plugin API. My current understanding of that body of work is it simply acts as a guard for resource requests.
1 Like
Hello Andrew!
Reading your thorough response you make some great points, particularly regarding the Full Policy vs Partial Policy. OPA is designed so that all decision making is localized in order to minimize any potential latency and so that policy decisions can be provided in milliseconds.
I’m brand new to OpenZiti but as I learn more to incorporate the project into our environment I will keep these points in mind and contribute back any information I find that may be of use!
Thank you for your thorough and quick response on this!
@ccravens and @andrewzah, welcome to the OpenZiti community.
OPA is a fairly robust policy engine - the types of policies it can implement vary greatly. Are you just exploring it, or are there specific policy types you are interested in? Similar question on the OpenZiti side - any example use case or specific policy type enforcement you are interested in?
I ask because there may be cases in which both OPA and OpenZiti policies would make sense - essentially solving different problems - and other cases in which there might be overlap, contention or duplication.
Hello!
From my perspective it’s more about just understanding the various integrations that are available with Ziti. For example some other things I’m looking at is integration with our Vault PKI and SPIFFE identities as well.
I’m brand new to Ziti, so as I learn more about how it deploys, the architecture and how it integrates integrates I may have a better idea of what types of policies may be a good fit?
Thank you! 
1 Like
These videos may be interesting to you then if you haven’t seen them yet:
2 Likes
I would note that one of the OpenZiti developers is planning up a piece of work to demonstrate OpenZiti integrated with Vault PKI and another open source edge/IoT product.
As well as @gnz links, this blog should be useful too - Integrate OpenZiti with JWTs, PKIs for seamless service authentication