Demo of the Cedar Programming Language - The Open Source Language from AWS

Key Takeaways

[Music] and action a cedar tree on a bluff overlooking a large Bay a whale jumps but that's what we're talking about today we're talking about Cedar an open source policy language in SDK and I am here with Mike Hicks senior principal applied scientist with Amazon web services hey Mike hey how are you I'm well I like your T-shirt by the way thank you that's really awesome I think the cedar is one of my favorite trees so I really like the name that you gave the programming language you're going to give us a little demo of it aren't you yeah Chit Chat sounds good all right all right so uh Cedar is a language for helping you the application writer control access to your resources basically to write a permission system for your application what you might do normally is to write a bunch of code to implement your permission system but instead with cedar you can write Cedar policies and you can delegate access requests to the cedar authorization engine and there's a bunch of reasons why you might want to do that first of all the authorization engine is implemented using automated reasoning and intensive testing to make sure that it's correct Cedar policies are ergonomic easy to read and write the language designed to have deterministic low latencies and your policy set is analyzable and we provide tools to help you find bugs and of course because Cedar is really cool totally so I'm going to show you this demo of using Cedar to handle the permissions of tiny to do a task list manager so this is what tiny to-do looks like it's a little uh server written in Rust and here you can see that Cedar's authorization engine is handling when clients send their commands in figuring out whether those commands are allowed or not and it's going to look at the cedar policies to make that determination if everything's good the command goes ahead if not it's going to return back off denied so this is an arcade this is an application written in Rust it's written in Rust and so it can can you work across any programming language we have bindings for Java as well and we would love Community contributions before we get to it ourselves to make bindings for other languages okay so let me show you um what this looks like here are the cedar policies for this application so those are stated up front you can State them up front you can design them to be created on the fly if you like but in this case yes all the policies are in a separate file stated up front what's the best practice here that you're looking for there's no best practice uh I I personally like stating them up front because I like to be able to look at them once and for all and know what they all mean okay uh but you you could create them on the Fly okay great so uh the idea with uh tiny to do is to create task lists and update them but to share them with other users and let them do the same let me just show you what that looks like when we actually run it so I'm gonna um start up the the client here written in Python and I'm going to fire up the server there's a few logging messages that show that the server got started and I'm going to assume the role of the the user Andrew and Andrew's going to try to create a list so the logging messages I'm showing here are those calls to the cedar engine that we just saw on the diagram and the call is saying hey Andrew is asking to perform this action create list for tiny to do and the cedar authorization engine is saying yep that's that's fine because policy zero said it was okay what's that well that's this policy that we were just looking at and this policy says that any principle is allowed to perform either of these two actions for the application tiny to do and the action we just saw was the create list action so this request was authorized by this policy it's very simple isn't it very straightforward it's designed so that if you look at these policies they're easy to understand and read even if you've never seen the language before so let's say now that Andrew wants to add a task uh to his list so he does that and the request goes over to Cedar there's a user Andrew wants to create task and this time the resource is the list list zero that he just created and that's allowed because of policy one so let's look at policy one it says any principal can perform any action on a resource as long as they're the owner and so Andrew was the owner of the list he just created it and so he was allowed to perform that action now let's suppose that uh you're a different user Kesha and Kesha now tries to have a look at Andrew's list that request is going to be denied Andrew Kesha called get list here on list zero and we see that the answer is deny with no reasons given why is that it's because Cedar is a default deny language unless one of these four policies authorizes access then Kesha is not allowed to see the list why would you do that why would you make it a fault in I language because it's safety by default okay make sure that you only give access if you really intend to okay so um the other two policies that I'm showing here are that we can share lists with other users for example I can look at a list if I'm a member of the readers group or the editors group for the list and here I can update the list uh if I'm a member of the editors group so if I was Andrew uh once again and I did share a list with Kesha but only read only then when I change to be user Kesha and call get list again this time I allowed to so it's printing out the contents of the list and you can see that this was authorized by policy two okay so um this is basically Cedar in a nutshell there's other things that oh my gosh that cedar uh provides one of them is a schema that allows you to describe the shape of the data in your application as well as the particular actions we just saw create list get list this is this file is describing those we can make sure that our policies are correct so if I try to make a GT list action it fails because you didn't tell me about that action side of the schema if I had my policy this way and sent a request off this policy obviously wouldn't work if the the action didn't match and there are other mistakes that it can check for for example if I misspell an attribute it's going to complain about that if I do a command like this where I try to treat a group as if it's a a number that's not going to work either so this is a way that we can analyze the contents of the language and make sure that you don't make policy mistakes who wrote the language so uh Cedar was conceived just over a year ago we started to work on it actually maybe more like a year and a half ago um a couple of uh senior Folks at AWS recognized that customers need a way to manage their own resources not just AWS resources but resources like task lists in their application and they brought to Bear ideas from the identity and access management language to inform their thinking about what this new language could look like it also I am policies also have principal action resource and conditions but it's a language that's evolved over 10 years it's very specific to its use case and so they felt like a new language was needed to meet customer needs what customer needs does it help me then Cedar is customizable so all of the actions you can see here that we defined we made those up for our particular application in our use case you were able to for your needs for your application whether it's a a compute cluster or a user application or you know whatever it might be be able to Define policies and entities as to your your data model okay why did you open source it great question so Cedar started its life as the policy language for Amazon verified permissions it's a service that's now in a private preview and Amazon verified permissions takes what we just saw and makes a cloud service out of it so your application instead of linking the uh the authorization engine in your rust code instead calls out to a cloud service which then runs the cedar authorization engine on policies that are stored in that service so this is great when you have lots of applications that want to share the same policy as you want to co-locate all of your logging and auditing and so forth inside that cloud service what we realized was not everybody can use a cloud service some applications really want that authorization engine local to their application so they don't have to pay that round trip and they have use cases that are maybe lighter weight or that they want to customize for example for different data models and so we felt like well open sourcing it is going to make those customer applications possible and it's going to allow us to take in community contributions and ideas to continue to make the language better because you couldn't do that before and so those Community contributions will be core to what you're building here and you mentioned that kind of in perspective with having bindings for multiple different programming languages exactly yeah that's right there's there's a a long list of things that we think that we need for Cedar but we know that the moment in fact open sourcing it only yesterday we've already gotten a bunch of great feedback we've gotten some pull requests fixing our documentation we know that soon customers are going to be telling us things um that they want in the language and providing contributions that we didn't even think of so what types of contributions would be helpful I can think of several so one you mentioned already these extra language bindings being able to call it from go or from python I think would be a great help another thing that would be great would be to implement Cedar inside of a sidecar that's another way that you can make it accessible from many programming languages and systems being able to delegate off to a server that's running adjacent to say your kubernetes cluster to do your authorization that way shouldn't be hard to build but it's something we could use a way of interfacing with cedar the way it was evaluating the policies it needed to as you can see in the policies that we were looking at it's looking at application data in this case task lists there's a particular format we expect for that data being able to interface to existing data stores back-end databases having Integrations for that I think would also be something we could really use and so what have been the initial pull requests uh so far they have people have observed mistakes in URLs and corrections to documentation where we weren't as careful as we should have been all helpful uh actually one person uh made a suggestion for a vs code plug-in which I I've been using this is a one that we have in open source yet so that was great to hear okay great what's the interest in policy languages these days what is it that's driving this interest do you think I think there's a couple answers for that one is when people start to build permission systems in their applications they find very quickly that as the application evolves that permission system gets unwieldy and hard to maintain by having a policy language that's factored out off to the side it's easier to figure out what your policies really mean because they're not all entangled with your application code and because that language was designed for policies it's more likely that it's going to capture the evolution of your use case moving forward interesting discussion that could be had about all the different ways that this might be applied what are some of your what are some where do your thoughts go when you think about the feature of Cedar and its evolution so the most exciting thing about Cedar I see coming in the future is the ability to analyze policies to help users know that the policies that they wrote are the ones they really intended Cedar's design as a very simple language one that hopefully is you can see is quite understandable is amenable to using a technique called automated reasoning that allows you to reason about the permissions that your policies are really authorizing as your policies change over time having automated reasoning to tell you hey do you realize that you just put in a policy that made another policy a null and void you probably didn't mean to do that do you realize that this refactoring that you're trying to do actually provides more permissions rather than only the same ones by using these analysis tools we're able to help customers manage their policies and make sure their security posture is where they needed to be and I think there's a lot of potential in Cedar for going that direction I guess the last question that I have is like there's more people who are needing to learn this isn't there especially as security and s-bombs become much more important to be considering I was just having a discussion with that about the rise of kind of people who are in product security roles right or in Risk officers so this seems to be a uh a aspect of that evolution you can use cedar in many situations including I think the one that you were just describing using it to describe security postures for organizations being able to describe uh when you're going to be amenable to taking in a particular software package or using a particular system our hope is that these policies have lots of use cases and the ones you described are certainly in bounds great thank you so much Mike thank you if you like this video please give us a thumbs up and if you'd like to see more videos like this you can always subscribe to our YouTube channel we're on all the major social media platforms you can always find us at the newstack.io we hope to see you soon [Music]