Cloud Native Computing Foundation Cloud Native SecurityCon NA 2022, 28 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: OPAL: The Open Source GitOps Enabled Platform for Building Authorization- Asaf Cohen

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Lightning Talk: OPAL: The Open Source GitOps Enabled Platform for Building Authorization - Asaf Cohen, Permit.io

Broken Access Control is the top vulnerability in the OWASP Top 10 security risk list. Proper configuration and enforcement of access control are critical to modern organizations, as privacy and compliance awareness are at their peak. Yet, building authorization or permissions management is a painful process for developers, due to complex and ever-evolving requirements and lack of knowledge for avoiding common pitfalls. OPAL (Open Policy Administration Layer) is an open-source administration layer for OPA (Open-Policy Agent). OPAL detects changes to both policy and policy data in real-time and pushes live updates to policy engines, making them real-time and event-driven. OPAL uses Git as the source-of-truth for policy, enabling GitOps workflows for policy delivery and versioning. OPAL is used by thousands of engineers, from Tesla, Zapier, Cisco, Accenture and others. In his talk, Asaf Cohen, co-maintainer and author of OPAL, will explain the challenges of managing modern authorization and access control and how these challenges can be solved by using open source tools like OPAL. In the end, he will provide use cases and tips for implementing simple and scalable authorization.

A

Hello, everyone I'm Assaf from permit IO and I'm, going to talk about Oppo, the open policy Administration layer and now it can help build uh Cloud native permissions more easily.

A

Sorry about that.

A

So you just got your project to build in-house permissions, but you need to understand. Permissions are hard, okay, so um there's a lot of modern challenges like microservices infrastructure was not what it used to be 10 years ago, and now I cannot just embed permission logic into my application, because I need to enforce access across many services. Some of them are third-party services as well.

A

Modeling permissions is really difficult, while all developers almost know what role-based access control is eventually you'd want to move to more complex systems. Let's say you want to get access based on the user location.

A

You cannot do that with war base. Access Control, you probably want to move to actually with based access control or if you want to get access based on ownership, more fine-grained permissions. You probably need relationship-based access control, so this kind of challenges are are difficult because these systems are difficult to grasp and are difficult to implement. And finally, there are mounting security and compliance standards that we need to adhere to. We all like our privacy, but it comes with a pricing implementation. We need built-in auditing, we need checks and balances.

A

For example, I want to be able to say who can even change the policy inside my application so of C4 of C. This is also important, um and all of these challenges are the reason that broken access control is the top uh top issue in our top 10. So 94 percent of applications were tested for broken Access Control, and we want to avoid these pitfalls in our implementation, so the first one that we see most I'm sorry most commonly in coupling application, logic and authorization logic.

A

um You may want to start with just like admin and not admin for permissions and that's okay. But if you encode this logic in an if branch in your code, eventually you'll get this code block, and while this is a like completely fine for monolith applications when you get to microservices it completely breaks, because you'd need to duplicate that logic across all. Your services and duplication needs to drift and drift leads to um security incidents. So we don't want that. We want to put everything in one microservice in one place.

A

The second kind of thing that we see is mixing up, authentication and authorization. So with implementations, where people just take claims from OCTA and just put them in Json web tokens and just check that in code- and that is fine, but it has a few downsides so organization roles are not the same as application roles.

A

We find the head of I.T I shouldn't, have admin access to the financing app, so some translation from organization roles to application roles needs to be made, and um another thing is that jots tokens are not storage, they are limited by the HTTP header size So. Eventually, when you'll have more fine-grained access, uh you will exceed this limit.

A

And lastly, um this is not flexible if you want to change the permissions for a user mid-session, because the user has agility logs in everything's fine next time you re logs in this will be applied, but this is not flexible enough and finally, not planning ahead. So this is completely fine like starting with something simple, but let's hope you do better and the app will grow and more demands will come so demands from customers. You'll.

A

Have uh this really great deal that could be great for the company with an Enterprise customer and they need finer Grant permissions, and now you need to build that into your application really fast or you want to expose API Keys through your application. You need API Key Management.

A

All of these demands will come and you want to build the system flexible enough so that it can grow over time without being so painful to rewrite from scratch. Every time.

A

So, let's talk about the best practices, really briefly, you want to decouple policy from code. You want to be able to respond uh to events real time. Okay, you want to have the github's workflow for policy. You want back office for stakeholders and you want interfaces for customers and I will go um and I will go over them one by one. So first decoupling policy from code we already agree. This is a great idea and a really cool project that most people know right now is oppa. This is the most adopted policy agent.

A

Currently in the market and opal lets. You express policy as Rego code and data is Json, and this is great. You can just create all the policy in the organization in Rego and just manage that oppa does have one downside. It was originally made for kubernetes admission control and it cannot actually respond to events in real time so for applications. This is breaking, and that is why we made Oppo.

A

So opal is an Administration layer for Oppa. That gives you two main things. First, gitops and second, real-time updates, so I'll go over them with opal. Each Opel client manages a single Opera agent and then it can be managed by an opal server that can run in a cluster, so the oppos server's job is to track a git repo and serve that policy from there.

A

It also can push real-time updates, like Json patches to the Oppo client and from that to the policy agent and finally, Opel client can actually access data that the Oppo server cannot. You can send an instruction to Oppo client, even if they are in a separate Network, to bring data from. Let's say an in-house database that shouldn't be exposed to an outside Network um opal is extensible. It has a plugin mechanism called Fetchers, so we already have Fetchers for ldap mongodb stripe Etc and um you can use them if you want everything is open source.

A

um So oppa gives you the ability to manage policy in git. Why is this so good?

A

Yes, so with Git Ops for policy, your policy is auditable. You can see who made the changes. Were the authors. You can see all this you can use science commits and the entire history is available to you. It's immutable. Rolling back is easy, it's super easy and also it gives you the power of CI CD. You can have tests, you can have approvals with PRS for something sensitive. You can have multiple approvals and you can have quality signals so with oppa you can have policies that are not as performant as other policies.

A

There is a meaning how you write your policy, so you can just have a code signal in your CI CD. That says if the policy is too slow, it will affect my app SLA and please let me know um so all that power is available to you. If you manage all your policy agents with opal.

A

So if you want to talk more about, obviously uh please come find us at Boost. Su25, we're also available for slack and uh Oppo is available at opel.ac, it's apache2. So uh thank you very much.