 So we're just doing a little agenda-making while we wait for people to arrive. If you're new, please check out the meeting notes. If you're online, I'll put them in again because I don't think the chat's persistent. Add yourself into the attendee list and would love to have two volunteers as scribes. That just means you write down whatever you're here. We have two people so that, you know, if you miss something, you don't have to stress about it. And then you can feel free to talk and somebody else will write stuff down, although everyone is welcome to help out scribing. We just want to make sure that we have at least two people who can capture notes so that people can review them later. And so that we're not completely biased to people who are awake at this time because we have people in quite a few time zones across the world. So I saw that the discussion of the supply chain proposal was proposed on the agenda. Is there a person who has proposed that? I didn't check to make sure Santiago is here. I'm here. Can you hear me? Yes. Great. I don't know if you propose that, but we can chat about it. I didn't propose it, but I volunteered myself to be the voice of that here today. I think people wanted it to be discussed, but I think nobody could make it from the people that wanted it to be discussed. So is there, maybe I just ask, is there anybody who wanted it to be discussed who's on the call today? We could just move that to next week. Okay. Next week? Yes. Great. So I'll just move that to next week. Oops. I just deleted something. And I'm going to put this one actually last so that, because Michael might be here towards the end of this meeting. He had to miss the beginning, depending on how things go. So thank you, Gareth, for joining. If anybody can be second-scribed for the last 30 minutes, that would be awesome. Otherwise, we'll bring it. But let's just start with check-ins. My name is Sarah Allen. I am one of the co-chairs of Six Security. And I have been, I've been catching up on the OPA assessment and chiming in there on kind of wordsmithing like our summary and kind of trying to suggest ways it could be more concrete. And that's our number two, our second assessment that the team has done. And then in my non-SIG security life, I've been thinking about how do we do streaming video over the internet and know that it's not coming from random people on the internet. So that's kind of been fun. It's sort of security-related, but not necessarily cloud, I don't know. And we met with our TOC liaisons this morning. It was more of a kickoff. It wasn't like a big decidary meeting, but generally it was positive. And they really liked the momentum of this group and the enthusiasm, how folks are scrubbing in and adding value and having a spirit of making security something that should be for everyone and openly and freely available. And Joe made the comment that there's some vendors where security is something you pay for. You really like the idea that we were contributing to a common so that security could be something that everybody gets to have. So that's my little check-in. Sorry that went on a little long. Brandon, you're up next. Yeah, so recently I've been kind of just doing the tree edge stuff. I closed a bunch of issues. No one has screamed at me yet, so I'm assuming that it's not good. I was looking at some of the PRs around the identity categories as well. I guess if we have time to talk about that a little bit later. Besides that, outside that, we are continuing to work on the image encryption stuff. Container image encryption, which we have our PRLGTMs in container D. So hopefully we also have a KAT which we're going to present the signal next week as well. So hopefully that goes well and then at some point we can also share it with you. That'd be fabulous. Great work. And again, I've been seeing you close things and every time I'm like, oh, good thinking there. So I appreciate that. And we should have time because I think we juggled the agenda around to talk about identity and access control. Next, Gareth. Yeah, hi, everyone. It's the first time joining the call. Really just to sort of catch up with what's going on and get more involved as I get more time. So I guess potter's history. I used to work for the UK government doing a bunch of architecture and information security and automation things. I landed at Puppet for a while. I was at Docker most recently. I had a few months off, which is very nice. I've more recently just joined Sneak. So small security startup and getting back into a bunch of security things. I know like Michael's I'm catching up with him tomorrow in London and I know just in a few other people involved. It felt like a useful thing that aligned with things I like doing, but also now what I'm doing for work is all just handy. Great. Thanks for coming and joining us. And maybe we'll add if we have time, the new member proposal of like where we're working on a guide for new members and that might be a good thing to point out. Yeah, I will happily test that out. That'd be great. Roger, are you have four Wi-Fi, but can you speak? We'll see. I can speak. We'll see if you can hear. So I'm, as you know, p.m. on our Kubernetes distro at Sousa. I am here in Nuremberg, mainly conspiring about integrating and containerizing our OpenStack cloud and CEF distributions on top of our Kubernetes and figuring out how not to turn our networks into a giant swamp of crosstalk and insecurity and fun things like trying to convince people that maybe we shouldn't be running user work on the same Kubernetes that we're running the control planes. And I know I've said this before about having more time, but it looks like we're really in the home stretch of releasing stuff. So it looks like I will have more time. My next thing is going to be cube-huntering our release radically before it gets out this time instead of six months after. And as I told people at the face-to-face in Barcelona, I would love to start at the very least writing along on assessments. Great. I think chiming in on that issue is the way to volunteer the first five assessments issue. Yeah, okay. I shall. Excellent. Thanks for that check-in. And next up is Martin. Hello. Hello for me. I'm Martin and it's my first time here. Welcome. Hello. Thank you. I am working at Viewware and I'm in the open source team in the security sub-team in the open source. And so I will have to listen more currently. I have many things to read and to get familiar with. With what guys you're doing. It would be exciting time for me and hopefully I want to help you and contribute in future. Good. Thank you. Welcome. Then Christian. Hi, I'm Christian. I work on cloud security at Google. One of the things I'm interested in is this notion of how some of our customers have these platform teams and I'm still trying to work on that. I'll probably get access to some of our customers so I can actually ask them. So I will be part of customer visits so that will make it easier to answer that question. So no progress on that for me besides me, you know, trying to make progress in the long run. Thanks, Christian. Um, TK. Yeah, so I did have an opportunity to join a future network roadmap, which I reported quite a few months ago, I guess, and it's going very slow. They do have a security sync group. I mean, security group basically under them focusing on the 5G, those of you that maybe just not familiar with that. So the positive side of it is that there is a lot of, you know, it's a very large scope that they are actually trying to address the security but so it has everything literally. But that's also the negative side of it because my, from my own observation, I am a little frustrated because it's not focused well in the sense of I don't see anything tangible that would be coming out anytime soon, even though it's a long roadmap. It's a 10 year roadmap for security as well as edge automation application services, everything relates to the 5G. So the, any newcomer that will come in there, probably will get confused thinking that I'll go, this too much, you know, where do we start, where does it end, and how do we get a handle on it. So that's one of the concerns that I express. Let's see what happens. That's all I have to report. Okay. I know we sort of owe each other a conversation about edge and how it relates to cloud native and where that fits. So hopefully can follow up on that next week. Dan Shaw. Dan, fellow co-chair. I'm on mute. Sorry, I'll mute. Yes, one of the co-chairs. I've been tied up with some work obligations last few weeks. So I haven't been as active as I usually am. But, you know, in that, I've been, you know, working with our Tuesday liaisons and the other stuff that Sarah mentioned that the chairs are doing to help continue shifting everything forward. Thanks, Dan. Aaron. Likewise have not done too much in the past week on this. On some other data security stuff, but I did see the comments on the landscape and it looks like we're scheduled to discuss those a little bit later during this meeting so Brandon looking forward to that conversation. And then next up is Svi. Svi, do we have audio? Maybe. Hi, everybody. Great. All right. I'm sorry, I couldn't find the unmute button. Hi, I'm Svi from Aqua. I've been on and off in these meetings a little bit, but now it's really getting interesting as we start to talk about identity management authorization and stuff like that because that's my background. I'm really curious to see what we can contribute to that area of Kubernetes. Super. Thanks, Svi. Santiago. Hey. So, yeah, I've been missing from the meetings for a while. I thought that it was a somewhat of a conflict of interest to be here while I was being having to review for the Intota project, which it's finally done, I think. We used it on the presentation for the CNCF last week. So that that was, I think, a great milestone here. And well now I'm looking forward to like future projects. I'm very excited about this software supply chain catalog and resources have been actually taking up through papers because I think we can also add the elements of like academic literature and theoretical background and link to it too. But yeah, I think that's a discussion that we can have next week when everybody that's also excited can chime in. Thanks, Santiago. Carlos. Hey, this is Carlos and working as a researcher in some internal projects that we want to implement the Kubernetes and also on the CI CD pipeline, different testing different security tools. That's too much. The last week. Hi, I'm Ash. I work on the Open Policy Agent. I'm just reviewing any comments you guys may have on the OPA security status documentation and also looking at interesting integrations for OPA this week. Sarah, you're on mute. Thank you. So in wrapping up our check ins, I wanted to note Santiago, if you have a chance to link to the in total security assessment for the newcomers, it might be interesting for them to see that recently completed from the group. I'll link to the right away. Where's the best place in the in the notes or if you put in the chat, maybe one of the note carriers can move it over. Here are the notes. The chat doesn't seem to be preserved in history. Come in. So, so I wanted to do a quick shout out to I'll just take care of some quick items. First, the the new member page. I personally like the proposal that there's buddies for people who are new. And I forgot who said that they were new and was willing to try out our new member page. I think. I'd be happy to take a look and provide some feedback. If you could look at it, it's an issue state with like, you know, some some ideas in there. And I wanted to just see if there was anybody who's enthusiastic about trying out this buddy idea. Wait, on which side is like a someone who's been part of the project for a while or as a new person. Somebody I'm a new person so nobody knows who I am or my voice. Hello, new person. Hi. What's your. So, did you see the notes that I just put into the chat. Yeah, I have the. Did you. You're not that new. I've talked to you, Sarah. Like you were in San Francisco and then like we had a spare meeting room or something at the river hotel. I can't even remember it. Yeah. So, well, you have been to the meeting before we have some people who this is their very first meeting. So, yeah, so I think that last time we just mentioned this in passing. And I said anybody who wants in order to have a buddy program. We must have the newcomers must have people who've been here for a little while who are willing to volunteer to be buddies to be the more experienced person in a buddy set. So, I don't want to put anybody on the spot. I'll just put it out there that if you're willing to be a buddy. Add yourself to the issue and say you're volunteering to be in the first set of buddies. If we don't get any volunteers, then we will not be doing a buddy program until we have more volunteers. So, so I can volunteer myself on the experience side but I wonder if I am experienced enough. I think you're as experienced as anybody. So, you'll just try it out. And you'll have questions and then we'll figure it out. Okay. So, Santiago will be guest buddy. And you'll try out a buddy program and then if we have if we have any other. I don't want to take up too much space for this buddy matchup thing. If you are an experienced person have been here for, you know, a couple months or whatever, at least since the last, you know, cube con EU. I think we had like a big upsurge of people. So if you've been like around enough to kind of have a sense of like you've done a PR and contributed in some way and just volunteer to be a buddy. You can shout out on chat people can match up or and add yourself to the issue so that we kind of know that we have a few people willing to do this. Thanks everyone. And also like feel free to shout out. Well, like let's figure out we that we have some experienced buddies and then we'll, we'll volunteer for new people to have buddies. All right, so now I'm going to actually turn it over to Brandon are you volunteering to lead to facilitate a discussion about identity and access control categories. Yeah, sure. So I don't know if Aaron here right. Yeah, I am sure. Yeah, okay. So yeah, I think so this will space around this issue. I think I think the PR but I didn't think the issue. So Sarah you open this issue talking about called landscape identity access control categories. It seems like the main kind of part of contention here is that some people kind of see identity and access control or something a component of which every project meets and so it creates some ambiguity that so Thank you, sir. I think the wrong. Yeah, I think the wrong issue sorry. I'm trying to find the right one. Is this not the right issue. No, this isn't the right issue. I'm sorry. It's it's the one before that's a pull request. Yeah, I was just linking that. This is the. Yeah. So Aaron, Aaron proposed some changes, which I thought pretty interesting. But I think a lot of it. A lot of the discussions I feel like the open to a broader group. Aaron, do you want to talk a little bit about kind of the changes that you're proposing. Yeah. Sorry, once the thing went full screen, I lost my ability to be mute. Um, yeah, so I guess I was trying to clarify the different things that might be involved in might be identity and access specific projects that we would want to guide people about as they're sort of exploring, you know, building their own cloud native projects. And so looking at the overall CNCF landscape, which is like, I guess 900 different projects just started thinking about how to maybe categorize this section. And so I kind of approach it from the perspective of someone who has had to implement consistent identity for companies as a as a defender, where there's a whole bunch of people who built a whole bunch of services with not a lot of compliance. Not or sorry, not a lot of consistency. And just trying to break out like what are the functions that what are the functions that we want to break this category down further into and I chose to give some exemplars of specific projects or protocols or technologies. And so my effort to help sort of clarify what I meant by these things, but we don't have to include them or not. And so I specifically, because the term identity is so used I specifically added the word lifecycle. Certainly I know that's up for debate. But the idea here is that having sort of an official understanding of what a principle is a principle being a specific user or a specific service and its life cycle creation, and transition granting of entitlements removing of entitlements, granting of attributes removing of attributes that there's a specific I feel like there's a specific focus set of tools around that activity alone and that it's worth categorizing that specific set of what is an identity and what do we know about it tools as one specific subcategory of identity and access management. So I'll pause there and say you know Brandon. Does that make sense is it one category is it multiple categories like how do you want to approach that. Did we did we break it down in a sensible way here. Yeah, I think definitely the clarification so you're either giving some examples what type of identity functions and access control functions. Projects may have definitely helps. The thing that I want to kind of hear more opinion turn was for this specific roadmap document. What's what's our thoughts on including specific specific examples of projects on this. I know initially we we mentioned specifically and things like that but I wasn't sure for this specific document whether there are examples to a different document and if there's more for definitions or do we want to add the examples here as well. So I'm thinking that there is. What we model up here so so one of the things I'm seeing is there's an entity provisioning and identity consumption. What you typically call authentication is actually the consumption of identity right it gets provided by somebody, and I can clearly see that we want to have the provisioning and management of these identities to be be a separate thing. And active directory versus why DC validation step right now you know active directory is kind of the management and provisioning of identities and then the IDC validation is kind of the authentication step. So I think that would be a bit that makes sense to me. I generally agree with this, like that the separation is important. I want to just clarify that there are exist systems where author, where the, the authentication step is not a consumption of identity, where the you can. Your, your identity can be decoupled from like the credential that allows you to come back and and do not be identified by your authentication. Like particularly in government where you're worried about the privacy of the individual, you may sign up for an account using your identity right like if you're like say a veteran, and you're getting health services that the VA might. You have your identity with the Veterans Administration, and it gives you a credential that says you are a veteran and then when you go to health and human services which does not need to know who you actually are in order to give you health medical stuff, because you're a veteran, you know, like that that decoupling in some systems is important. So it's just like a, I don't know, maybe that was in the weeds. No, I don't, I don't think so I think that is actually interesting and I don't think we capture that at all. Right, because that becomes interesting if people start thinking about privacy issues. I have a few questions at some QCorn about GDPR at the time, and this this split helps you think about that and reason about that. Yeah, for me the word lifecycle I actually find very helpful here right because it's sort of like it explains that like this is whole thing about like creating an identity and like it's its own kind of set of expertise and stuff. So when it is one question I guess for Christian and that makes a lot of sense the separation of provisioning and consumption and that definitely you're right right like that those are those are definitely typically different activities and provision is particular provisioning is particularly important in larger organizations. So if you had to split those into two, and we were looking at something like an LDAP server right like a free radio radio system consumption but something like specifically an LDAP server, which is both used as a directory and an agent for provisioning, but it's often used as the place where you know attributes are consumed and even passwords verified. Like where would that fit or do we just accept that some things are, you know, some systems are multifunctional and so, you know, an LDAP server would live in both identity lifecycle provisioning and identity consumption. I think there are some so if you if you use some open standards you have an easier way of separating those two. I think especially for password verification there are options to do some of that. But I think a lot of times when you think about one of these identity problems you tend to cover both aspects right you tend to cover you know I need to provision this identity and I also need to allow people to consume them. Easily further down the road right so I think Spiffy does some of that as well. So I don't think you can ever completely separate them but if you if you follow a standard you could right you can provide a directory that vends or IDC tokens right so the validations that can be completely separate from what you do. No, I think that's that makes sense, although for the purpose of decomposing the landscape of projects is that is helpful because there are so many projects as you know it right. If I if I compare this to the CNCF landscape document and say we're trying to create a specific CNCF landscape specific CNCF security landscape that it's not just about new standards it's also about helping people trying to engage with cloud security understand what their options are. Yeah, and I think that that's that's actually exactly what what we need to do because the the idea that that every project or or even an application is going to store its own users doesn't really happen anymore. Everybody's going towards actually centralized user information where the identity is owned, usually by the person and they trust some entity to to provision aspects of that record to certain providers under the consent of the person that owns the data which is usually the individual. So the idea is that that for most projects you will need to rely on a service and there are protocols you know SAML and open ID and all those kind of things that do to do identity Federation and and I don't think that anybody in the right mind would now actually take on. Housing and protecting and and and destroying the talking about GDPR identity information that's tied into an individual. So one question I had that that this discussion sparked is like, is this consumption of identity synonymous with credentials. Like I like it we just kind of back to Aaron's question of like, are these different services or are they always coupled and then we might as well make them one category because we don't want to have everything in two categories. Yes, there is reasons to decouple them these days right so one of them is that these these identity validations are typically costly. Because they involve so it's a purely technical argument right so so you try to exchange them for something that you that can use symmetric encryption. Right and then also then serves as this secondary credential that is decoupled from your actual identity. And are we seeing I'm, I'm not as familiar with all the different things in this space like are they are we seeing an emergence of different projects that the do the different parts of it. I think we, I mean I certainly think we are right we're seeing different ways of managing the attributes that go to identity. I see different libraries and plugins for consuming different kinds of access tokens. You know, spiffy. When I look at spiffy it seems much more about the issuance of credentials, and while it provides some very loose guidelines about how to consume them. I think most of the work in the consumption space is actually be done being done by like their commercial partners so so I would say that distinction definitely resonates with me. Exactly how to communicate it clearly I'm maybe noodling on a little bit to just a question will we classify a project and the multiple categories. We basically have used as a guiding light that our landscape would be perfect if everything fell into a single category. We don't expect that to actually be reality, partly because we're in this emerging space and early offerings early projects often had to build something that now is a broken out and there's things you can use for so just kind of because of history will have projects that do a lot of things right and then therefore they would be in multiple categories, but we believe that a lens for the landscape to be useful. We want the categories to divide the products into projects into buckets right and so we were that's kind of where we've been in previous conversations. There is probably also a another aspect of the identity that is the that affects the whole security aspect that's the identity spoofing. So, and that, of course, the identity directly maps to your credentials to credentials to your authorization and all those things so even if you put them into separate categories. There is clear obvious relationship among them that affects the actual security preservation. So if someone spoofed the identity that affects the whole thing down the chain line. Right, and you have to be able to trace that back you have to be able to shut it down you have to be able to take all the precautionary access precautionary steps rather to to preserve your security. So, I like the idea of separating them, but at the same time we have to keep in mind that they're related and they're very relevant and one affects the others. That makes sense. I think actually, so the question that we have to understand is do we want to take the ownership of being the identity provider, or are there's going to be a set of services that you're going to trust. And if you get a valid token with the right encryption with the right timestamp and so on you're actually going to trust that an identity is not spoofed that it's been correctly validated. And then really all you need to do is based on the attributes that you get in an assertion, for instance, you would then authorize it for the permitted actions. Because I think that that's what's been going on, you know, over the last, you know, 15 years is that that applications aren't aren't don't want to own the entire user record don't want to worry about spoofing don't want to worry about housing passwords and the authentication and and the advanced authentication and all those mechanisms for two factor authentication and so on. So there are the those mechanisms that do all that. And then if we if we if you trust that that service is providing you an assertion with the right identity identifier then you really don't need to worry if it's spoofed or not that that service has done that. Well, it seems like I think what he was saying is that the interface between these two services of is a bit more complex than a regular integration of a service because you know you have to maintain more than just a call out you have to make sure that the correct trust is established as well as you know, maintaining certain replication this and certain information about key hierarchy as well. It's like a pretty tightly coupled integration rather than just for example like calling out the database or something like that. I was also thinking about, you know, somewhat probably in the futuristic manner, but it's more like the dynamic nature of this spoofing. And let's not underestimate that part because just because you have an identity confirmed at one event at one trigger point, and then you have an application that is triggered. Because in the process and then the identity may have been spoofed right in the middle and someone else is also having access to the same applications as such. How do you maintain that integrity. Those things need to be taught about even though they seem like a little bit far fetched right at this moment but it's not too far fetched I believe I'm struggling to figure out how that. I think you're right that we do need to reason about those things and figure out whether we have you know where we have gaps and whether there's you know tools or processes or whatever it is to address those type of vulnerabilities. The question is when it comes to the landscape where the purpose is to categorize for different projects. I'm struggling to see like how does that, that area that body like open questions apply to this, the set of categories, because there is there a different category or there might be, I guess, under consumption of identity, some category around what RSA calls like adaptive authentication or like identity intelligence, something along those lines. There might be a category there around people who are nominally threat intelligence providers but also help you, you know, help you consume logs of identities help you consume the context of and make better decisions about whether a particular particular authentication event might be fraudulent so so I think it's a reasonable thing to add I can't name other than like RSA adaptive off off the top of my head. Particular I guess cloudflare might have something in that space. I was thinking. Go ahead. Sorry, what I was thinking about a little simpler version like you still have a separate category just like everybody said there is enough justification to have those separate categorized in the landscape, but at the same time if we could create a matrix that shows the relationship between these categories and perhaps even we can identify a little more specific relationship in there. I would hate to use the word API it's not API but it's somewhat of relationship how one affects the other. So that way, if we are doing something on the management of specific category, then we are cognizant of the fact that it might have some effect on the other one. And if we can keep track of that in the landscape like a two dimensional map or even three dimensional, but I think two dimensional is good enough. Perhaps it will keep us astray at least not to forget that the implications there might be even if we did not resolve it for this very moment. That makes sense. I actually really liked that idea. And we could go a bit further as well right we could also say that the network stuff or the storage stuff should also call out to central access management or access control service. And we could get people to start thinking about making that a consumer rather than implementing it. Right and that might also actually help with this this whole cat like the whole category of identity access management kind of stemmed from like well okay well if you have storage that that needs to do access management. In the access management category and we can say like no it's not because everything like this is how they're I struggle to actually imagine how it would be visually described. But I love the idea because it's sort of this end dimensional thing in my head. When it gets to 2D I'm like, I don't know. Yeah, it gets complicated when when resources are also identities right you need. If you're a person trying to start or stop a workload and the workload is a resource however that workload is also an identity that might have access to other resources or other workloads so things to tend to play a dual role especially especially when you start to talk about machine IDs versus people IDs. Yeah, I think that we actually need to call out that there's people IDs and machine IDs. It's sort of implied with I think at identity Federation single sign on to me that implies user identities human identities I should say. Well maybe they're not humans, always. But I think that that it would be worth sketching out that there are these different kinds of identities. This is in the chat there's this discussion around the term machine identity versus service identity. Are they the same thing are they different things. Do we even have machines in the cloud. Yeah, I think we want to separate you know human entities and non human entities because human entities. They have a different path of authentication usually it's usually some kind of password or proving your identity, while non human entities usually have something that's assigned, and, and everything is sort of inherent. And also the attributes, if you're talking about attribute based access controls which is a lot of information on the chat. Also, the, you know, the non human ideas have different attributes in the human. So I find what you typically have is you have a service identity is the one that you're really interested in, and that gets established by some form of trust chain and at the bottom of the trust chain somewhere is the machine. I didn't get the service identity. There's a whole other set of people who like work at the, you know, the application layer who don't necessarily get to make decisions about service identities right. And so depending on which layer of the stack you're examining. It'll have different concerns, but I think that it's a good point. So actually have a question maybe I'm a little bit behind the discussion but if we, if we move this from the identity aspect into the resource aspect but what are, what are we authorizing access to. It, it will help us determine, you know, what, what information we would need to obtain in order to assert that access. So you're saying that this is a distinction between resources and identity. Well, certainly between authorization identity, I think is the point. I think you always authorize a request and then you can use different attributes of the request and one of them could be the resource name. Right. This policy could be determined on resource name or it's just a service right service measures typically only argue in terms of service to service authorization right or even just authorization. I just say you know service a is allowed to contact service be to do something. The space one gig is kind of a level above that where you say okay maybe service a can only access resource see in service be and not resource D. Yeah, and that level of granularity also depends on your enforcement point it can actually do that and block access. Yeah, not all policies have that level of granularity. Yeah. Right. Yeah, the verb is kind of the other one can you only read or can you read it right so so those can be different. Again, different attributes of the request, right. In rest of the APIs, it's the HTTP work that you can reason about. Well, not everything is a peer request right. Yeah, yeah, sure. Yeah, but actually so so you know the error of then did access management is definitely not not you there's a lot of established practice in that. And I think you know there are there are tools, different protocols different standards that that we can use and, and we need to find the right tools for for the job. So if, and if it's, if it's extremely generalized as in we don't know what the resources are, then it won't be one set of tools and if we are more confident in what the resources are and what the level of granularity. is really hard and maybe we can look at other subset of tools that are more good towards that particular use case. But especially in the, in the context of CNC F we have Kubernetes that gives us kind of a resource framework to think about right of course as the the arbitrary problem of, of dealing in authorization but there's also the problem of dealing in authorization the CNC F context, which is really what what what we are discussing here right so at least for the control plane, you have reasonably well established standards here. Data plane is a different question right and then that is that is something we are currently grappling with a lot, because we don't know how to, how to transfer that. There are some some APIs like in the world right don't have necessarily a resource model. But like, I don't know whether under the hood, you know, at some point resources a very general term. In any case, I find this claim that I find the edit as written to be a helpful clarification and separating, you know, rather than bundling together authentication and authorization. And some concrete examples of what would require an authorization path. So, I don't, and I actually would love input from the group here which is, we've talked a lot about this notion that like resources need to make their own decisions. But it does seem like that really is very much left up to the application teams without a lot of guidance as to how to do that. I think intuitively we all know that like to read and write are different operations. There might be major buckets of resources that you would want to authorize differently. I haven't found, you know, I can't off the top of my head think of any framework that lives outside of a given application for separating out or like what what resources would be that is, you know, robust enough to talk about API access, robust storage access at the, you know, object level and, you know, that would be robust to both kinds of like resource stuff so if there are the folks are aware of any good frameworks for like application developers to put in to help them reason about these things that those would be examples I'd love to, I'd love to include. Isn't there a, isn't there some help from the OPA, for example, the policy doesn't the policy decide as to what type of roles or if you are back or a back doesn't matter the credential based access. Yes, but it's the main reason for the OPA type of project right. It's the main reason for the type of OPA project and definitely as they build out their examples. You know, ash. You may have something to add here. That would definitely be referencing and we already we already talk about that a little bit elsewhere and so I'm just wondering if there's anything. Anything else for more traditional are back like systems that would serve as a good entry point. I would like it to include our back and a back as examples here under resource authorization authorization. I find it helpful to the edit that includes having policy engines in that section because like it sort of seats it. But yeah, I would love to hear from Ash or whoever was about to speak about. Sorry. Yeah, just a quick comment on Aaron's point so OPA is pretty general purpose like you know where you can do our back a back anything with OPA it's depends on how you author your policies is there something specific that you think OPA does not meet all we need to kind of include. I'm not understanding that point. It's not very clear to me right now. I'm not thinking of anything specifically and just if they're common patterns. You guys have some common patterns for how to do like admission control now it's it's very it's it's loose to me at the moment so I don't have a good I don't have a good. Not relying on Kubernetes right if you do a kind of a CRD style control plane for your service. Right you can you can use the services of the Kubernetes API server to do both our bag and admission control. Right, so I was just pointing out that like we we have this edit which is resource authorization and I think what I interpret the question to be. Are there things that aren't resources. Do we want to describe it in a way that doesn't use the term resource because that feels very specific. Or is you know, or maybe it's not right like we do have the Kubernetes example as Christian mentions that is like the CRD and it's a very formalized sense of what is a resource and how do you interact with it. But they're you know there are other models and maybe from the open experience you have a good way of describing like what are the things that we authorize and should is the resource term appropriate when we have a category that maybe may maybe we want to leave open for other types of framing. So if you follow kind of a if you try to simplify everything to an object oriented model, you can literally describe the whole universe in different objects right. So then you can consider that okay well resources and object. So any type of access to the resources and object access to that object. So literally, you know from that perspective I think you can probably bring everything in that model as an object type of things and then you provide the grant or not granting access to that particular object which may be just an action. So I'm actually very familiar with the resource based model and I am a big fan of calling everything resource. I also have been in API religious wars with people who are like. My thing is not a resource and so I'm in your camp, but I know that there are other people not in that camp. So in just naming the category. That's what I was like saying is that do we want to have some. I don't know examples of the non resource authentication that is hanging out if there is any. I can't think of another name was there one that they recommended other than resource. No, I mean I think we could just call it authorization. But I don't know, and maybe nobody cares and resource. I wouldn't object to the PR as is. So this is Mark, I could see us getting into a longer conversation about this but the fire standard has multiple sub standards around provenance the, the authorization layer the infrastructure for transporting authorization, the resources and the RDF triple store associated with the domain models. I think because they're dealing with HIPAA and safety that the fire standard does a better job of any of the cloud native security projects that I've seen. Now getting into that is a bit of a deep dive so that's kind of the risk of going into this territory but you know if we had the time I would think that's worth our time now. Well we did with this in the NIST big data working group was trying to do a crosswalk to some of their existing standards. I don't, it looks to me like that is not going to suit the more modest thing we have in mind for the landscape but we might want to just put a placeholder here to go back and revisit the work that's been done in that standards organization. Thanks for the, I'm going to like thanks for raising that I want to close this thing because we've got just two minutes till the end of the hour. And, and like let's put a pin in that because we did have very early on discussions of wanting to sort of gather the relevant standards right and that could also be a lens on the categories right where there are existing standards right like maybe that means something to the categories, or logging what we collectively know as standards that are out there that are in wide use, or that we recommend for whatever reasons to as a service to the community. So I'm going to pause there, I'll give Brandon and Aaron the homework of like figuring out whether we need to, whether we ought to resume this next week and finish the conversation or whether you feel like this can be taken forward. And I want to have one extra call out for volunteers for the microsite we have all we have we had selected six presentations, maybe eight, six day presentations from the last year and a half. That seemed to be helpful to the group that were a presentation format. And those have all been uploaded to YouTube and with transcripts. So we want to, like, basically they need to be like sort of, when do the when does the actual presentation start and end of the meeting, and like just sort of sweeping through the transcript to be like, do we want to clean it up when we publish it on a page will probably still keep the transcript right of the meeting but you know like if we were going to have something that goes with the presentation. You know, if you're if you're interested in listening to an old meeting, and you know maybe pulling out some a summary of it would definitely love to have a volunteer's willing to do that. All right, Brandon any last words on the identity and access control. Welcome to chatting with Aaron about this. I think that definitely like some things that we can just push in there that pull in directly and some things require to discuss a bit more. Yeah. Okay, super. Thanks everybody. See y'all on Slack till next week. Thank you.