Wow - looks impressive. Like the direction it's going. Doing things where access policies can be set as code is the way to go IMHO.
One issue I've heard from ZTA early adopters is the lack of interoperability between the various ZTNA solutions. Not a big problem unless you have two organizations that have different solutions that now have to work together (merger, partnership, etc.). Ironically, I have overheard people complain enough that they would pay for a FOSS solution...
Thank you. Actually one of the very hardest things for me working on Octelium is basically how to describe it concisely and clearly and I still can't say that I have an answer, that's why I prefer to describe it as a "unified secure/zero trust access" platform. It's a ZTNA platform but not in the typical sense, it's also a remote-access VPN but actually works via identity-aware proxies to control access at L-7 instead of at L-3 like in VPNs. It's BeyondCorp but actually supports client-less access for both humans via their browsers and SSO but it also supports client-less access for workloads via OAuth2 client credential flows and standard bearer authentication which makes it relevant for any workload written in any language to access all your HTTP-based Services via a single bearer access token without being aware of the Cluster's existence at all. And it's also a deployment platform that enables you to deploy and scale any containerized application, HTTP-based or not, and instantly provide secure client-based/client-less access to it via your policies or even completely expose it to anonymous access like it's a hosting platform if you wish.
Thats why I think there will be an open source standard that other companies build their ZTNA on (i.e., similar to flavours of Linux), which supports federation, so that companies A, B, and C each have their own ZTNA, but can interoperate based on shared/agreed rules and policies. We haven't built that yet for the FOSS solution I work on (OpenZiti - https://openziti.io/), but we have heard the demand, and have it on the roadmap.
Wow - looks impressive. Like the direction it's going. Doing things where access policies can be set as code is the way to go IMHO.
One issue I've heard from ZTA early adopters is the lack of interoperability between the various ZTNA solutions. Not a big problem unless you have two organizations that have different solutions that now have to work together (merger, partnership, etc.). Ironically, I have overheard people complain enough that they would pay for a FOSS solution...
Thank you. Actually one of the very hardest things for me working on Octelium is basically how to describe it concisely and clearly and I still can't say that I have an answer, that's why I prefer to describe it as a "unified secure/zero trust access" platform. It's a ZTNA platform but not in the typical sense, it's also a remote-access VPN but actually works via identity-aware proxies to control access at L-7 instead of at L-3 like in VPNs. It's BeyondCorp but actually supports client-less access for both humans via their browsers and SSO but it also supports client-less access for workloads via OAuth2 client credential flows and standard bearer authentication which makes it relevant for any workload written in any language to access all your HTTP-based Services via a single bearer access token without being aware of the Cluster's existence at all. And it's also a deployment platform that enables you to deploy and scale any containerized application, HTTP-based or not, and instantly provide secure client-based/client-less access to it via your policies or even completely expose it to anonymous access like it's a hosting platform if you wish.
Thats why I think there will be an open source standard that other companies build their ZTNA on (i.e., similar to flavours of Linux), which supports federation, so that companies A, B, and C each have their own ZTNA, but can interoperate based on shared/agreed rules and policies. We haven't built that yet for the FOSS solution I work on (OpenZiti - https://openziti.io/), but we have heard the demand, and have it on the roadmap.