Hello everyone and thank you for joining. My name is Vive. Koda and I work at Aryaka Networks. I have spent my career working on secure and scalable identity systems for enterprises operating across Globe. Today I would like to explore with you how we could scale identity for Secure Access, service Edge, or SE using Key Lock and the model known as Regional Hub deployment. If you have ever waited several seconds for a login page to load. You know how frustrating at agency can be at a global scale. Those seconds might apply into our self loss productivity. So let's explore how we could design identity infrastructure to avoid that problem. Here is how we could structure this discussion. First, let's talk about the challenges SE presence when it comes to identity. Then we could look at regional hub model, how it might work, and why it could solve some of these challenges. From there, I will show how Kilo could be used as an identity solution in this architecture. Finally, we will walk through how we could think about automation operations, and the challenges we expect along the way. By the end, you will hopefully have a clear idea of what steps you could take in your own magnet. Traditionally, security looked like a calendar model. If you were inside the network, you were trusted. That model doesn't really work anymore. With the remote workforce applications spread across the cloud and edge and regulation tightening across regions, the perimeter has effectively disappeared. So instead of thinking about securing networks, we could shift our thinking to securing identities. Identity could be the new parameter, the factor that it remains, who gets access under what conditions, and from which device. SE brings networking and security together into cloud delivery service. Think of it like building a network of airports. Instead of routing all travelers through one central hub, we could have local airports where passengers check in, pass through security, and head to their destinations more quickly. At the center of SASE is a zero trust model, always redify our trust. And identity could act as the passport in the system, the thing that makes or breaks access. By consolidating policy and access decisions around identity, we could ensure consistency across users, devices, and locations. By scaling identity in a global SAS E environment could introduce challenges. Latency could be a big one. A Singapore user authenticating against US based identity provider could face 200 to 300 milliseconds of delay per request. Availability could be at risk. If a centralized system goes down, you users across worldwide are locked out. Data sovereignty could complicate things. The regulations like GDPR or CCPA could require local processing and storage of identity data. The scale itself could become a bottleneck. A centralized identity and access management systems might not be designed for the throughput demands of global traffic. So the centralization might look neat on paper and practice. It could introduce serious friction. One option could be to distribute identity using regional hub model. In this model, we could deploy autonomous key cloud clusters in major regions. For example, one each in EDAs, EMEA and apac. Each hub could authenticate local users independently reducing reliance on a central system. The same time the hubs could coordinate with each other to synchronize policies and use of data globally. It's like opening a branch office for identity. Each office could handle its own local users while still staying in alignment with the overall organization. By moving to regional hubs, we could see several benefits. First, latency could be reduced since users authenticate closer to where they are. Second, availability could improve because the regional outage wouldn't necessarily impact users in other parts of the world. And third, we could optimize cost by handling authentication locally, reducing close and traffic and cloud ingress chargers. So overall, the user experience could improve while the operations remain more resilient and cost effective. Now, why Key clock? Key clock could be a strong fit for this model? Because it's open source and Kubernetes native, which makes it flexible to deploy anywhere. It support multi-tenancy through rounds, which could be for separating business units or customers. It's standard compliant supporting OIDC, both to SAML and web authentication, so it could, it easily integrate with modern applications and it is extensible. There are special requirements, custom extensions could be deployed through SPS or even listeners. So as we evaluate identity platforms. Key Cloud could provide the flexibility needed for a distributed hub based model. Let's imagine what a regional hub could look like at the center. There could be a key cloud cluster handling authentication and single sign-on behind it. A database could store user information and configuration. A load balancer could distribute incoming traffic across key clock nodes for scalability. We could have direct desynchronization to keep our user accounts aligned with corporates users. And finally, an observability layer could give us insights into performance and security events. Each hub could follow the same standardized pattern, but still adapt to local compliance requirements. How could we decide where to place the hubs? We could start by analyzing traffic patterns. Where are the users? We could align hubs with existing SSE point of presence to minimize the hubs. We could consider regulatory zones grouping res with similar compliance needs. We could look at cloud provider capabilities, choosing regions with strong service and resilience, and we could validate all this with latency test from real user locations. A practical starting point could be three or four hubs across major business regions. Expanding as usage and metrices group synchronization would be key. We could synchronize usage and policies through shared directory services like A DRL app or even through database replication. Policies could be kept consistent using ops workflows for token and session management. We could enable cross cluster token validation, use distributed caches like infinite span, or allow token exchange between hubs for operational consistency. We could manage configuration through CICD centralized mattresses and stream events for auditing in this way. Each hub could operate independently, but still remain in step with global architecture. To make this manageable, automation could play a central role. We could adopt ops to treat all key cloud configurations as code, ensuring consistency across regions. We could use Keylock operator in Kubernetes to simplify deployment and scaling. We could apply Canary deployments to rollout updates safely. We could implement observability tools to track authentication flows, latency and errors across regions. With automation in place, a distributed system could remain both reliable and predictable. Of course, this model could bring challenges. Data consistency could be difficult across regions. We could mitigate this by defining. Authoritative sources and conflict resolution strategies, operational complexity could increase. We could address this with infrastructure as a code and centralized monitoring failover coordination could be tricky. We could use health aware global load balancers and automate failover testing. Cost could rise. We could manage this with autoscaling and play full placement of hubs and complaints could get complicated. We could embed compliance checks as code and automate audit trace. So while this is in without challenges, the potential benefits could outweigh the complexity. To wrap up, let's reflect on the key points we could take away from this discussion. First, identity could truly become the foundation of SSE if it thinks about zero trust, it's only works and identity is consistently verified and enforced. Without identity at the center. Zero trust is just a theory, not a practice. So strengthening identity could be the single most important step in making SASE effective. Second, we saw the regional hubs could be a practical solution to the challenges of latency, availability, compliance, and scale. By moving identity systems closer to users, we could dramatic. Reduce dependency on a single centralized provider and stay compliant with the regulations that we reach. And by reaching this distributed approach might feel more complex at first, but it could solve video problems. And finally, Kiler could be an excellent enabler for this vision. It's open source, Kubernetes native, and is already designed to integrate with modern cloud native environments. With its extensibility and standard compliance, it could give us flexibility to tailor identity to SASS e needs while keeping core central control. So the main idea here is simple. In a well architectured SASS E model usage shouldn't feel the distance between themselves and their additive provider no matter where they are. Access should feel fast, secure, and seamless. So what next steps we could take? We could start by evaluating our current identity architecture. We could map where our users are located and identify hotspots. We could pilot two region key clock deployment and validate the improvements, and we could build automation practices early to make operations smooth and repeatable. Thank you so much for your time today. I hope this session gives you some practical ideas for scaling identity. In a global SSE environments, I would like to hear your questions and then how you are approaching these challenges. Thank you all.