 So first of all, please a round of applause for Adam our sex player And if you pay drums or bass, please contact him would be great to get a band here Maybe next time but all right So I am Juan Antonio Sirio Robles or us. It's a little easier and Adam young again our sex player and Yeah, we're gonna talk a little bit about Oslo policy Did you a little bit about access control? How do we use it in open stack? How to write policies? These are very basic talk. We're not assuming that you know anything, but hopefully it will teach you a couple of things so Yeah, where's there you go? So why? Right, so why are we even doing this? Why is this not just a live gig of Adam? I Don't know. I don't know. No chances are everybody's deployment is different chances are the default policies are not enough for you and It's very probable that you're already changing the policy, but Are considering that it might not be enough? So we thought it would be appropriate to start teaching folks more about it Given the docs are quite extensive, but it's just nicer to have somebody teach you, right? So we'll try to keep it simple. We'll try to teach the basics So yeah Oslo Oslo as some of you might know and here we have the PTL as well. Hey Ben Is the set of libraries that are coming for open stack they try to enforce Standards and common practices and Oslo policy is just one of them. It does access control and Oh access control So who can do what right? Usually you assign roles or attributes to your users or to whoever had wants to do something in a system and You'll have rules to define Who can do what right? so these rules are enforced and we call this authorization and That's the gist of access control. You can search more in Wikipedia, but for our purposes. This is the main thing of it so let's take a very simple example just a bakery and I live in Finland, so it's all Finnish names Those are Finnish pastries I'm a bit hungry But yeah, let's say Kim is a baker. He can bake bread and it's all good. He has the his Baker certification he can manage Food and and it's all good Bill V is a cashier and she manages money and Deals with customers right given that Kim is a baker. He's not allowed to be with the He's not allowed to deal with customers to deal with money and given that bill V is not a professional baker She's not allowed to bake so This is access control in a gist right a User has a role and can execute an action on a target object. This is what is our main concern now You could have several shops, right? So Kirstie is the owner of the shop and Kim works for Kirstie, right? Eric is the owner of the Norwegian bakery the competition and all the works for Eric so even though Kim and all they are both Working for a bakery. They cannot work for the competition So this is scoping right you can you scope the work of all of it towards the Norwegian bakery so The one that authorizes All the end came to work at the specific bakeries is the owner so Yeah, one important thing to note and that usually people get confused by is that authorization is not the same as authentication authorization is Who can do what are you allowed to do it while authentication defines the identity of The user or whoever is trying to do something So access control in OpenStack. Let's talk a little bit about it. Let's take a sample request We have our rockstar here that wants to just list the servers of their OpenStack deployment and In order to do it he needs to be allowed to do it so the first thing that he's gonna talk to is Keystone Keystone is the identity service for OpenStack, which you might know and First of all, you will authenticate to it and it will give you back an access token or a bearer token With that token you can now try to do operations in your opens like installation. It could be Neutron It could be Nova. Let's say Nova. So the first thing that you're gonna do you're gonna try that curl request right there get your servers and It'll give that bearer token OpenStack itself is layered into several pieces of middleware one of them being Keystone middleware. There's also a bunch of more like Stuff for audit and whatnot but in for our case is Keystone middleware the important one and That piece of middleware is just this small piece of software that whose only role is to talk to Keystone verify that The token is valid and get user data, right? So it'll talk to Keystone give it the token. Hey is this token valid or Has it expired or I mean can I use this? It's the middle piece it's got to be in there It's got to be in the way and that's the way that we're able to enforce it You need to know that even though you're talking to Nova you're talking to a little piece of Keystone, too Yeah, so subsequently you're gonna get a response of it like yes This token is valid go forward or maybe not like this token is I don't know this or it has expired it wasn't valid so it'll give a lot of information back about the user about a rock star over there and The middle where then can decide okay, let's pass on this information towards Nova and then Nova will do whatever it needs to do now as Mentioned Keystone middleware verifies the token and gives you a lot of information All of the information that you know already from OpenStack the user ID the name Project ID domain ID is the token valid. What are the roles? Which is a very important thing. What are the roles for that user so all of this is Filled up by Keystone middleware. So now we get to Oslo policy, right? Also policy I put a lot of information there, but it's a small library that all of the OpenStack services use And it provides several things right it is a small library. So you're usually Well, it allows you to write your policies So you will write your policy in a language that is Yamal or Jason. It doesn't really make that much of a difference it's very similar in both ways and It allows you to do enforce the rules to specify the fault rules and to read the rules Right. So the fault rules are usually stored by the project in in code So you would need to know a little bit of Python to actually be able to read it nowadays It's called by the service. So the service is responsible for coding the calls to enforce policy It's not a piece of middleware. It's it's a library. Hey Oz. Is that true everywhere? It's not true. It's not true. Everybody has done policy in in in code It's something that's happening. You'll see it in a lot of the projects But not all of them and that's one of the gotchas There's a lot of gotchas here, which is I guess that's why we're here Why we're here, but uh, but yes keystone does it in code Barbican does it in code Neutron still doesn't do it in code yet There's also another gotcha when you're updating your policy Usually some services just read the policy automatically. So they will check when the policy was last modified and Automatically refresh it. So that's very nice because you only need to change these etsy nova policy that Jason are etsy Barbican policy that Jason however Not all services do this for keystone. For example, you need to refresh So it requires a lot of tribal knowledge about which project does what we are trying to standardize, but There's still a lot of gaps Where your tribe? But it's in process. We're trying So access control how do we map access control from The abstract concepts of the bakery to Oslo policy, right or well now open stack, right? So again a user has a role to execute an action on an object Kirstie is an admin. So that's the admin role and can create that's the action Users which is the object, right? So in Oslo policy, we have three main concepts, right? We have the credentials which describe the user so Credentials contain the username it contain the domain, but it also contains the roles So that's the credentials the rule is the rule name. So Get servers create or list projects and whatnot. So that's the rule and the target is Information about the object. So what type of object is it? What project does him belong to? domain information and whatnot so that's the target and Another gotcha a lot of open-stack projects define the target in non-standard ways, right? So barbecue and for example fills it up in a very different way than Nova for instance, which is also something we're trying to standardize I'm gonna go really quickly towards the language of policy But I mean it's it's a really simple language You don't need to dig too much into it and we're gonna go through examples, which is the main thing So that's hopefully how you're gonna learn it But as I mentioned, it's a very simple language. It's just a key and a value. So then the name of the rule or the target Rule target and the implementation, right? So you can have lots of different things one of them is hey always allow like this operation is very safe No problem always allow anybody to do that There is another one if you really want to Restrict users from doing certain operation. You can always deny, right? Which is this exclamation mark? as any other languages you have your and rules or or rules you have you can negate a rule You can group them with parentheses. We're gonna see them a little bit more in the examples, right? And you can also specify a default rule Let's say that somebody tried to do something that the service is not really acquainted with you can deny by default for example This is not very common nowadays, but it used to be Roll checks, let's check that for the compute get all The role of the user that tried to do that is Lister You can specify aliases in order to make your rules a bit more readable, right? Role admin or creator now you have a rule especially for that and you can do external checks. So you could also write your own check that We'll receive the data and just return the string true So this is very specific, but you can do that and also policy itself is also extendable you can do custom checks as well and In a subsequent talk Lighting talk lightning talk actually today. I I'm gonna talk about how I did an open policy agent check for Oslo policy And yeah, finally for example, you can check with a With a specific string but one important thing to note for example the last one is Project ID equals project ID that is the format of how you check a The credentials with the target, right? It's not very intuitive, but it's explained as well as in the in the documentation The left would be the project ID for the user the credentials and the right one would be the target So, yeah, that's all for the theory while there's still a bit more coming, but now is Adam's turn. Oh Come on Well, you know trying to be a little more inclusive of my language get that okay. Is this stuff like dry's toast? Board are you men's? It should be I mean this stuff really should be bread and butter And we seem to be on a bakery theme here. I think we were hungry when we made this presentation this is Obviously at the heart and soul to me. This is what open stack is all about open stack is a way of scaling your operational capacity and Your technology can scale Hugely it can scale to you know millions of nodes doesn't matter if your organization doesn't scale and that's what policy is there to do It's to make it possible for you to take what works in a small group and Duplicate it and clone it in a larger group well, what works is You have a set of roles and we talked about those before our Baker role or our admin role or our member role and then you have a scope and open stack works in this So the policy language that Oz just described. It's actually a generic rules Engine there's very little in it. That's that's open stack specific probably the only thing I would say that is Specific to open stack is the role check because a role is kind of an open stack II concept But really you could use also policy to do any sort of yes. No check you needed to and Neutron has done some stuff like that What I want to talk about now is what it means to do this within the context of open stack and This idea of the scope being separate from the role and that the two need to vary independently what the scope is is They get that right yeah, all right What's the scope the scope is a really foul tasting mouthwash that you want to go and get the green one because if you use scope is the Label that you use to say who owns or not who but what owns a resource how many people here have heard the term project How many people have here have earned the word tenant Okay, how many people know that they're actually the same thing How many people here know that I'm to blame for that? Okay, good at least somebody yeah, there's like there's a standard thing which is keystone sucks And it's all my fault and by my I mean me Yeah, so when we're talking about scoping for the primary thing that we're talking about is that project or tenant ID And project is the standard term for it by the way, and you can blame NASA for that who of course is no longer really contributing to the project Just to confuse the term so the project ID is is a label that's on every resource And I think every resource in open stack has a project ID ID on it Users do not they're the one things that are different We'll talk about those in a bit maybe some of the credentials and barbara can do not have project IDs Those are owned by individual things or owned by domains Everything else and for talking neutron networks images and glance Whatever they have in Sahara, I'm assuming some sort of wild animal they're all scoped to a project what you can do is based on the role that you have and And Yeah, as I said a couple things are not owned by projects and those are things are usually owned by users And but they're still scoped is scoped to an individual user So understanding that those two things that should vary the role that you have and the resource that you're talking to and so Let's go through what the policy looks like for a neutron network. Okay, so specifically we're gonna talk about a subnet Just to pick one Concrete object out of the bunch and so if you create a subnet you make some web call And it's gonna resolve down to making this policy call here create subnet rule admin or network owner Now you remember before where Oz said that we could have aliases. What do you use rule like that? That's basically saying look elsewhere in the file for the actual implementation of it And so this admin or network owner is really just a string at this point It's supposed to be descriptive. This is an attempt to get somewhat self-documenting in our code so Rule contact is admin or tenant ID percent network colon that's that format that Oz was just talking about before, right? So we have two distinct things The tenant ID and what's missing here. We don't really have a rule check. Do we? Okay, so let's talk about it with a little bit more proper scoping here first of all We're gonna say we have this thing rule admin and this is a fairly common pattern I don't know that I would continue this but this should be unsurprising to people who've looked at our policy files That rule is defined that either you have some magic is admin flag passed in from neutron and that does happen That's usually something that said in a config file. It exists. You should know it exists. You really shouldn't count on it Or you have the admin role And and the parentheses are important here those two are together and that whole thing is ended together with the scope check so we have two parts here now in our admin check which is the role matches or Excuse me the role matches and the project matches now network owner is this new Rule that we're adding in there. You can see that those are ordered together in our bottom level rule Rule member role, which is the same kind of rule that we saw before You know there was a roll colon member and the tenant ID matches so The thing that I've cut out of here and this shows that I really should have my slides better trouble shot Is that rule member role actually can include the admin role as well? And that's a way that you can build up more complex roles and in fact, I think we see that later on So if you look here This one right here. I have a little note here This shows bug 9 6 8 6 9 6. Okay How many people know what is bug 9 6 8 6 9 6? Okay? How many people know me? Okay, that's why nobody knows 9 6 8 if you know me you know that I know this bug by name This is the oldest bug in the bug tracker for just about every project Okay, if you go and you sort by like oldest to newest or numeric ID in Nova Nova and neutron and keys and all that you're gonna see bug 9 6 8 6 9 6 and What this bug is aside from being you know kind of alliterative and easy to say and all that Admin anywhere is admin everywhere and this is an error Propagated from the myths of time where we did not properly scope If if a policy rule checks only that the role is admin That means it doesn't matter what you've had admin assigned to you from whether it was a project or whether it was a whatever it is It will pass the policy check this means you can and We're not really too good on saying okay. This is only used for certain things this rule admin is everywhere So this is something that we need to fix so as we go through these next to this example I was working through here You can see that We want to make sure that when we check that you have the admin role that it's also on that project Or you have some other magic way of saying it's the right one and there's a mechanism that's coming for that But the important thing is just to say your role needs to be on the project and if it's the admin role And it's on the admin project or it's It's not scoped to the right project that the policy check should still fail does that make sense Okay, I hear muttering that's good. That means you're talking about it either that or you know if you're going is this guy nuts And I need to get out of here This is one of the most important concepts when you start writing your own policy files to make sure you have right Okay, that you're properly scoping your your checks Okay, so Why do we have roles so you can differentiate who can do different things you can see that we have two different checks here the The get subnet here is going to use the rule member or will share or rule reader. I don't know where shared came from Member says that you have the member role reader says that you have the reader role But what you could have let me see if I do that on the next slide now adding a reader role Okay, so You might have certain apis such as get subnet which are okay for you to do as a reader This is kind of a a non side-effect causing role basically gets when we're talking HTP Yes, if you look at our earlier example We were creating a subnet and there we're saying we want you to at least be a member or the network owner, right? You have the member rule here was saying to get the subnet just to read that That's okay to do as a reader and these are the distinction of the two different types of example Policies you need to implement in order to do a reader role. You always need to check scope. You always need to check what? What oh God you got it. Okay scope. Yeah, but you know, I'm not gonna stand up here stand my foot and say you need to remember something But remember scope. Okay Let's go back a little bit to slides go back to slides. Yes, so the the way that currently you can fix this is using this checking for the scope in the policy and That's true for most releases There is work on going to define the scope inside the policy encoded However, as we mentioned before not all projects take that into use yet So it's gonna take a while so right now. This is the way to fix it right now Checking scope in your policy. Yeah, probably worth mentioning is when you're looking at the policy files and trying to figure out How to customize them if it's doing a scope check? Leave it alone make sure that that's still done You're not gonna be able to get that more correct the part of the policy file the part of the policy rule that you should be adjusting is What role is allowed to do something and that should be what maps your organization a good example is going back to our network Things there might be a class of users that are allowed to use Networks they can create virtual machines and attach them to networks, but you don't want them messing with the networks themselves So you might take all the Nova APIs and say member can do that there You might take most of the the majority of the neutron APIs and say you have to have some special Network role in order to be able to do that and so those are the kind of customizations You do with the policy file to enforce who can or cannot do operations that that one the example right there is one that actually dream host who I have been a Customer of for many years. They they actually do it that way. That's that's not an unusual policy All right, nice. So where did we get this policy from? Okay, so If you go back in the midst of time each project had an Etsy directory on a project in this case, I'm I should say services each of the various Sub projects under OpenStack such as noven all that had an Etsy directory in their code repository And you see a policy.json file in there and at some point they disappeared a lot of people like where do these things go? Well, a lot of them went into code a lot of them are annotations on the The the the various APIs and say okay, this is what the default policy should be So if you don't have any policy.json file, there will still be something that's enforced. Okay, also policy generator with the With with the flags that you see here. So say service name in this case would be identity or compute It's not Keystone or Novitz identity compute and so forth the the good names That will show you what is the default policy file and you can generate and you can actually pass in another parameter Well, which will say do it as json or yaml and then if you want the really really verbose one that gives you Documentation I think we see that in the next slide Yeah, so here's the example with Keystone and You can see that you will get a Description of the API in there. So this one it says, you know list ports or interfaces It shows you the API's you're actually going to call it's it chops off the host name and all that kind of stuff because that hasn't been Precalculated but HTTPS colon Keystone 5000 block or in this case neutron to be able to do that And you can see the the squiggly braces in there around server ID Those are template values. So those would be the actual server IDs that you would be passed in This is the format that the internals of the Python code uses to generate the URLs And then at the bottom you see the same policy rules that we were talking about earlier At that's the final step and so there'll be a stanza of each of these within the the generated file okay, so You got a customized policy How do you make sure you've got it right? You don't want to just do this on a live server and you can spin up dev stack or spin up a server like that and Test against it and you probably should but there's an easier first step When we were doing this we quickly identified that we wanted to have the same check Performed when we made a change as was going to happen in the code without having to run a live server And so we built the the Oslo policy checker and this is a CLI tool that is inside the Oslo policy library and you use Various parameters to figure out how you're gonna run it if you just pass in the access file This is basically a snapshot of that token data you do a Keystone token get dash dash debug and you'll see what that token data really is and it's a You know a JSON blob that has your rules and all that in there So you cash that in a file and you can cash two or three or four different versions of that and you can run your policy Against those and see okay. This is what an admin token would look like this is what a member token would look like this is what an admin token would look like on project X versus project Y and so forth and You can say okay. I'm really just checking the you know create and subnet Rule let me pass in a flag that says just check this rule or if I leave that off It will check the entire Neutron API whatever is in that third flag Well, excuse me in that first like that dash dash policy It would check all the rules in there if you don't specify and then you cause who is as I'm sure is clear by now Slightly smarter than me. I was saying okay. I need to be able to check Oh, I also want to be able to vary the project ID and he's like I need to vary a lot of stuff So this is brand new the dash dash target To be able to build that target object that you're going to pass in to say hey This is what different neutron networks look like or this is what different Barbican Secrets look like thank you. I should know that better this is what the target looks like for the The resource that I am controlling and so if I wanted to switch out the project ID Well, then I could switch it in that target file And so I might have three or four different target files for a given resource to say hey This is what it looks like and I want to do it where the project IDs match and don't match and see that I get the right results and then in order to test it What I find is I do these last three steps start off with the vanilla one start off with your original one and run it and Send the output to a file and the things that I've learned is you sort it Because you want to make sure if you make any changes that you always do a diff between two things that the roles are The rules checks are the same and then you make your changes and you do the same thing and use diff And that will show you hey in the last time it passed this time it failed That's good. The last time it passed this time it passed you see no diff You should see a diff you know that you haven't gotten your rule correct and it seems simple But this little workflow right here iterated Adnazium will get you to the point that you have policy the way you want to in fact We're working on building a Something for triple O which allows us to do the same kind of thing in the in the larger larger sense Okay, I think we're up to the question slide What do we have 10 minutes for questions or one minute? No, we do have around 10 minutes. Oh awesome. Okay. Okay, hopefully I've confused you all thoroughly and you have a million questions If not, I'm going to start picking people out of the audience to ask questions But I see Sean's up. So at least we get we've got a plant In the in the audience and this is actually payback because I was the first guy to ask questions for for his talk So indeed Sean hello So when you talked about Generating the the admin token data Do you have examples of doing that in practice so that we can go back and do that on our clouds? Um, well as I said you can run Keystone excuse me open stack token fetch From the command line dash dash debug And and you can you can so the example will be in there So you you can do from that. There's a handful of examples. I believe still in Think he's done he's done middleman. There are there are example of what old tokens look like including old v2 versions of those But I think I would just generate one from an actual server and cash that and then Edited you'll see where the roles lists are in there and should be able to add additional ones in and stuff that once you've seen the Initial one you can chop out the whole service catalog, which is about 90% of the bulk of that You don't need that because we don't actually check policy on any of the service catalog things But yeah, there's a cash version. I want to see it might be in Keystone middleware still or it might be in Keystone Look under okay, so it's some part of the JSON response contains that yeah, and in fact in the The the repo that we're building the one. I'm currently hosting a page or I actually have two or three examples on there And that's you're laughing because so I'm only half kidding when I said Shawn's a plant He's a contra a consultant that works with our customers and has actually had to go through this process and Build a read-only role for a customer. And so the What he did there again the the rules look a little familiar. Yeah, they should Based on that so so there's a couple examples in that repo That will and we'll be plusing those up exactly that to have different projects And we need to now that we have the target option to to be able to build a bunch of those for those Okay, all right awesome. Thank you talk Thank you Yeah, come on up question about the versions of OpenStack this basic stuff what version of OpenStack does it require to work generally and For the stuff that Neutron hadn't implemented. What is that missing? Right? What kind of we do with that right now? Okay, so There's a couple different answers depending on which part you focus on Let me start on the latest part first the dash dash target flag Um approved and merged prior to the summit So that's that you'll have to get tip of tree But that for your your own work you could do a pip install of that or whatever that should be fine for being able to do that That's the only thing that's changed on the policy side of the rest of the enforcement is the same You just have that additional flag in there moving Back through the presentation to some of the earlier stuff policy and code has been an ongoing Effort effort I remember we were talking about it at the first Vancouver summit. So you have to go back I think Liberty and stuff like that you'll start seeing it there Keystone only got it about three or four releases ago Glance doesn't have it yet So really that's on a project by project basis Oslo policy the rules that it enforces has not changed in forever Okay, does that answer your question? So basically you can use the Oslo policy to make a read-only role for like old Versions you could do it for cactus. Okay No, you couldn't do it for cats. They weren't doing policy back then In the back the room greetings Just a quick question. You showed earlier that under slash etc slash service something there is the policy Jason Since greens all this is containerized How do I get to the policy of? Containerized service don't want to break in the container It's a configuration file and wherever you would find your configuration files. You find it there now If you're talking triple low and how do you want to generate new ones there? I think you actually need to generate them in the triple low environment format And then they will be generated into that for you and we didn't cover to that here because that's kind of triple low specific But the the short answer is wherever you would find your keystone.com right next to that You'll find your policy that Jason assuming that you generate one you may not have one if it's using policy and code And it has made no changes. There may actually be no policy and that's why those last Those last two are so important because if you want to actually document this and Deploy in such a way that somebody could modify it, then you'll want to run this and stick those in there. I believe for for triple O at least the Config directories are are bind mounted from under var Did everybody catch that? There's gonna be a quiz It's under varlib and you know look at the triple o documentation It depends on your deployment mechanism where we're where it lives, but it's basically bind mounted into the container. Okay, but assuming your Deployment engine doesn't bind mountain then yes, you have to go inside the container and modify that file There is a documentation for this. I assume Something that I can read and understand I Know what is it? Okay? Documentation for what fear change he asked for documentation or something you can read and understand about where you would find those files Yeah, and how to get them into the containers What deployment engine are you asking about? So that's trip. I mean are you talking about specifically triple? I'm using OSP 13 triple o director. Oh Yes, there is there is no documentation about it, but there is a specific format to do it Dogs I could write them though. So Sorry about that. I I do know that in At least in the OSP version, I think this is taken straight from upstream To be able to customize policy you can pass it in as environment variables And in fact usually what you'll do is you'll generate a a policy dot yaml for your whole deployment and So do you do a redeploy of the overcloud with that in there and they end up in the right places if you're working with Puppet managed files and policy is often puppet managed And you make changes don't be surprised when puppet changes them back on you. That's there's nothing I can do about that as a policy guy That's just that's just the the painful world we live in but there is documentation about how to customize policy as part of triple o and as part of of OSP, okay, thanks sure You guys just want to hear me place that spoon in and right No, that'll clear the room All right, any more question we got a hand over there. Yes. No, we got two that one right there magic Yeah, it's a little bit complicated because the target as I mentioned The target format varies depending on the service. So Neutron has its own Barricade has its own so for instance right here versus tenant colon network ID Wow, I really butchered that didn't I network colon tenant ID That's what you would expect to see in the JSON in the target So it's really gonna be dependent on which API you're calling what that's gonna look like and this this is new This is like something that we built to support ourselves So we will better document this as we we come up with examples of it but the short of it is the The doc the the targets are usually pretty flat dictionary and so you would just expect to see JSON in there, which would be project ID colon and then whatever the actual ID is so it's usually a fairly flat dictionary The best way just to read the default policy files and see the references to targets and try to Try to get the target from there Right now Yeah Yes So you remember before the the question was how fragile are they? On the roll side You're probably fine. You're supposed to modify the roll check. That's supposed to be your Your organizational specific part of it. Don't change the scope check. Don't change parts that reference Like the target or stuff like that because chances are you're gonna get it wrong That's really an engineering decision. I would actually like it so that as we split the code that stuff is stuff You couldn't override. I'd really like it so that the policy check was just overriding the the roll part But we're not there yet so the the short of it is You might have something that looks like it runs fine And then you'll just find the workflows fail because you're not providing the right roles Years ago I had this dream of something that was kind of like se Linux in permissive mode to be able to run an open Stack workflow and see what would happen and then you just say everything passes, but this would have failed We don't have that. We might build that Sunday, but we don't have that yet Okay, but in general if you're not getting stack traces at least, you know, your policies valid Syntactically and stuff like that you should be okay and then test like everything, you know Not just the the checks that I had before you should always do this in a you know a scale up Cluster and have you know have workflows that check the policy you just changed before you deploy into production Something like tempest something like tempest. Yeah One other question. Yes, I'm is there a master list of what variables are defined per service So you have the tenant ID checking network colon tenant ID. Is that is that documented anywhere? Where the which ones are defined up? It is not documented, but It is people are trying to standardize it so on some services it started to varize. So now we try to pass the Context so at some point if we manage to pull it off, it'll be the same for all services I don't really want you touching that Seriously, I mean Yeah, you you you can go in there and do unspeakable things if you want and there's there might be some good reasons for that in General if you look at the API documentation for the API that you're doing and that's one of the reasons why I showed This because you need to figure out. Hey, what is the API for the policy? I'm modifying so say you want to modify The OS attach interfaces you need to know that hey I can go to the documentation for know over here if you expand that out It will show you the the response objects and typically those targets are those response objects There are the objects coming out of the database in a format. They might be nested one level deeper in the In the in the Oslo, I mean in the documentation might have a compute at the front of it That you don't need but it's going to be in that format Okay, awesome. Yeah, okay. We're at 1421. There's another question And there's one last question Yeah, that's why I pointed this out at the bottom. That's exactly what I was doing you run it first and Cash it right you run it before you make any changes And cash it and sort it before you cash it because you're gonna want to check it sorted and then make changes and then diff That's the workflow We don't have a cash version of what it would look like because to be honest with you if you start varying up the Roles that you have and the targets that you want to do this against you're gonna far exceed what what we could provide Okay, but that's that is that should be the answer to your question. This is how you generate those Okay Any other questions any other answers go away