Kubernetes SIG Auth, 7 Dec 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SIG-Auth Bi-Weekly Meeting for 20221207

Description

SIG-Auth Bi-Weekly Meeting for 20221207

A

All right, hello, everyone uh welcome to the December 7th um issue of Sig off.

A

First on the uh agenda agenda's couple announcements: this will be the last seek off meeting of uh 2022, so we will see you all in the new year and um the new Sig Austria's Channel. Just maybe Mo want to talk about this.

B

Yeah I just wanted to have so like the folks that have been attending the triage meeting. We've just had like a side DM among ourselves as we discuss things and that that doesn't scale in any useful manner, especially since slack doesn't really let you expand. Membership of that and honestly had no need to be private anyway. It was just us talking about the stuff we discussed in the meeting, so I just made it an official channel.

B

So that way, um what I plan on doing is doing a bit more async uh a triage like throughout my week and then posting you know whatever I'm doing in there. So that way people can follow along if they care, um but that's just uh just you know trying to make this stuff a little bit more um in the public that, like people, know what we're doing, but the triage meeting is, you know, is still at the same time it's um on Mondays at 9 00 a.m. Pacific.

B

So you know it's open to anyone who wants to join yeah.

A

Awesome: okay and uh now, let's jump into issues of note.

A

um Does somebody want to give an intro on this one.

C

So I think this issue. uh We were triaging uh two weeks back and then uh one was a documentation, update and then I think I also added a comment about uh enforcing defaults, but uh I don't have my notes to see why I added that. But what do you remember why we added the comment about enforcing defaults for this one.

B

I think well, uh what we had wanted to ask was: um is there any thoughts or plans about having a different default behavior for PSA, so it's on, but when things are unlabeled, it's just wide open um did I think we left that as like a undefined like, probably not, but you know, we didn't think commit one way or the other um I I. Think part of the rationale for asking the question was you know this is the the Clusters config on this is opaque from the outside right?

B

It is whatever it is so like when things are unlabeled, you don't necessarily know. What's going to happen and and the cloud provider environments you don't usually have any control on this. um At least you can directly Flags um I think that was what we wanted to sort of ask. If folks had thoughts.

B

I, don't think.

A

Okay, so specifically around.

A

Defaulting sorry, this is my voice. A little bit, do you mean like a user should be able or an operator should be able to specify a cluster-wide default for new namespaces? Or do you mean that we would eventually like default this on for all clusters?

A

At the you know, um standard.

A

Enforcement level.

B

Yeah I I think it's more of like what what what you know. What is our long-term Vision on that default? Are we just happy with just leaving it as if unlabeled it means privileged, um and if we do do that, should that be observable in some way.

A

Yeah I, don't think it is clear to me that this would be um possible to ever enabled and less than more permissive as the default um I. Don't know what do you think Jordan yeah.

D

Without intervention by the cluster admin, which they can currently specify with this config or someone taking action via the API, which they can currently do by labeling a namespace or putting an admission web hook in place to label new namespaces um I I, don't think we can ever make the like default default. Be you upgraded a cluster and now unlabeled stuff is not uh privileged.

D

um Should the effective config be observable, um yeah, ideally there's a lot of things about API server config. That would be nice if they were observable. um So maybe that would be a good first step. uh I know feature Gates got exposed as metrics in 126.

D

um I. Don't know if metrics are the right thing to do for this, but uh there's like other admission config what admission plugins are even on um there's a question that people ask sometimes uh there's a lot of API server config. So if the goal is to try to understand like what is effective in the cluster um visibility, to that to someone who has sufficient permissions seems like a good thing to push on.

A

Yeah and suppose we have um that that does sound.

E

A

um Like I, imagine like a config see Handler where we expose more of the file config. We do already have the um command line exposed under the debug handlers, but um those would point to some file is that what you're kind of talking about making that file available via some Confederacy inspect the Handler um and I guess the other question I have about this is suppose a um you know. Cluster administrator does actually want to specify a namespace.

A

um A default for new namespaces What would be the mechanism for doing that today. How would they do that on a platform like eks or gke, um with Dave Wright and admission controller, that labels Natures on create.

D

Yeah, that would probably be how they would do it today um if I mean like long term, something like cell-based admission where, if you wanted a policy that says every new namespace just gets Baseline policy like, ideally that would be really easy and cheap to.

D

And you wouldn't have to run a web hook and you wouldn't have to like maintain anything out of tree. um So like long term, that would be the ideal. In my mind,.

A

Yeah, uh that sounds pretty easy if we can put that up on GitHub someday yeah.

D

Make it happen uh time wise, we're 10 minutes in and we have a lot of discussion. Sorry I.

A

Will keep it moving um cool all right next, one, let's see a question in space who uh put this one up.

E

um This this is a cap for um Global in environment, injection and I start the KMP, because because there is a OD issue for a long time and there's, this may make them easy to inject some environment arrivals.

A

D

uh I commented on the cap. This seems more like a signal level thing um like configuration or injection or modification of PODS pods generally start with signode API Machinery might be interested if the mechanics are admission. Related and auth might be interested if there are security applications, but I would probably talk to Sig node first to see if this is a thing that has interest and seems worth building in I.

F

Think I would see questions on this like at the time that issue was written. I, don't think we had very good, viable extension mechanisms like admission web hooks, but we do now and so even I kept with the idea of an API where you can describe it or configure it it. You may get a response that says the recommended way to do. This would be to create this API and create an admission web hook to do it um rather than try to modify.

E

A

Yeah so uh I guess the recommendation here is to um get this Honda signature agenda and I go.

D

And I think David's point is a good one like it specifically explain why an admission web hook approach is not sufficient for this.

G

A

Awesome thanks. Okay, you are correct. We do have a packed agenda. um All right. First up is uh external signing.

H

Yeah so um I'm, basically Reviving an old cup. It looks like it's linked there. um It looks like it got closed and pointed at a different issue, but was recently reopened.

H

um Basically, I want to revive the cap and see what the thoughts are around it. If that's something we still want.

I

A

um I think that this is still uh valuable feature um for uh some folks, so I think um I'm still supportive of getting this implemented. Are there any changes to the ex like the to the old cap that you would introduce before beginning with the implementation.

H

Yeah there's one small change, basically around a race condition. The current cap is designed to basically say give me, give me the key and then sign with this key two-step process. If the key rotates in between there's an issue um so now the new interface would just be here's this thing sign it one step.

A

Okay, interesting.

A

um So it's a minor API change between um list public keys inside payload, I guess for some race. Is that how I'm interpreting that yeah.

H

Yeah, so the signed payload request would only have the payload and we would basically just send the payload over and get it signed.

A

um Cool so yeah.

A

All right- and it is all spelled out here so.

B

Yeah, so to to the cap as a whole, though having I don't know, spend an exorbitant amount of time on cam, sv2 now and really really learning to hate that feature with every fiber of my existence.

B

um uh I'm just gonna put it out there, so I'm, good motivation.

B

I I am generally against this entire concept of this extension, Point like using these grp3 things and shoving them at like core important parts of the API server, uh because it takes things that could never fail and turns them into things that fail in horrible ways.

B

um This one is, you know, in line to cubelet keeping pods working, uh the API has sort of described there like I know, I couldn't run in the environments that I have to support, um so I I think what I would want from such a feature is changes to the design or capability that sort of address. What cam s V2 tries to address right by making it so that signing doesn't always have to call remote things somehow.

B

So if we can come up with that, I think I would feel a lot better, because that's basically what KMS V2 does is. It tries to limit the calls to external colors as much as possible.

B

Yeah I'm gonna say something I feel like you have like a thought, but you yeah.

D

I'm I'm I was looking over the like the motivations listed in the kep and trying to match that up to like what the.

D

Other hands go and then I'll add a couple questions.

B

uh Rohit I think you were first.

I

I, just I just wanted to say, like uh I I'm, in support of having like some support for external signing from API server like right.

I

Now, we we have uh private Keys living on the control plane, nodes uh which are long-lived and uh and we Federate, for example, with AWS and like if you, if you get access to that private key, it's uh it's a big breach right, so I would want like kind of one way, something where I can have, where no one can see the private key right, like so AWS cameras or gcp, Ms and and I just send the sign operation to them.

I

Right and I am like internally, I have a patch which doesn't start this grpc server but like which, uh which adds just like AWS KMS support directly using jose.opake signer in in communities, but that kind of wouldn't be accepted here right uh so uh ah like I, would love to have something like this here right like I'm, not sure.

I

If I have great ideas on how to do this, uh which will be supported Upstream, uh if not, if not, we don't want extra like grpc server, but I I really hope that we have some way to not have long-lived private Keys which are so powerful on the front Road.

I

J

Yeah, the motivations are largely the same like as before. It's just more just updated implementation um and I think like we also have usage experience of actually using the previously proposed cabin implementation for three years or whatever four years almost um and I think like totally get to know that, like you, might not be able to run something like this, but I think there are use cases that do that. Wouldn't.

C

Necessarily want.

J

Ease not to sign if, like the H, you know, HSN isn't available or something um they don't want. Explorable fees.

B

Right no I mean it comes down to if the feature exists, I'm going to have to implement it right, so I'm, I, I'm, sort of stuck right, uh so I I need the API to be expressive enough for me to be able to actually reasonably implement it and feel comfortable right. That I won't cause complete havoc, um I I. Think I I do still need a bit more crispness on, like I think there was some stuff about like rotation and stuff and like around API server restarts I, don't think does are like significant motivating factor.

B

So they're designed like this, like I I, think the core one is I. Don't want the keys on the host right. I! Think that's my understanding. Please correct me. If I'm misunderstanding them.

J

It it's both um like restarting an API server is in a big cluster. Is a disruptive.

B

H

Mean I'm I'm saying if that.

B

Was a big deal we could just. We can just reload the file like it's it like. We can just fix the API, so okay, yeah I.

J

B

It's both it's both yeah, so I mean I. I have no issue with reloading any API server config that can be reasonably reloaded. um So if we wanted to, you know prevent that issue. We can. We can just do that um uh so I I think I'm, just trying to understand motivations that cannot be sort of built on the existing entry point right and I think the core one there is well I. Just don't want the private Keys sitting beside my API server.

K

B

um In in sort of trying to think of ideas around this space, um for whatever reason the Jose spec includes certificate support, so you can technically technically you can build chains. So you could. You could have some kind of hierarchy where you have short-lived intermediates or something that that is sort of the Vegas uh statement. I have at this exact moment, but.

B

I

B

I want to see something that can be built that doesn't involve a one-to-one correlation between every signing operation and a remote call to some KMS or.

J

Yeah, so what if I want that.

B

Yeah I I said, can be built. Okay, I'm, not saying a mandate like KMS V2 does not mandate that the reference implementation will have the capability of doing that. But you get to pick you you can have every single operation go call out to your key Vault. If you want that's, that's totally all right. It's more of I need the choice not to have that.

K

Isn't that trivial, with this grpc model, though, like your grpc implementation, could just hold some key in memory or on disk, or that would.

B

Probably it's not so easy when you can't throw away keys, it's not so easy right and they all have to be synchronized across API servers. It's not like KMS, where the grpc API makes it super trivial to have distinct key sets and then use the remote KMS to sort of break. Any inconsistencies can't do that here, because it's if I present it present a signed service account token from API server. One API server 2 obviously has to be able to verify.

B

The thing has to be able to verify the thing for his entire lifetime effectively, unless you know ignoring hard rotation of credentials.

K

No sure but I mean, like we handled that today, right when you just hand, we give keyberry saver like two files right, I, guess: I'm not seeing.

K

That seems like a solved problem, but I'm not sure, maybe I'm missing something like yes. If you're operating a a three control plane, node cluster you'll have to be careful about the order in which you introduce new keys and.

J

Phase up right, exactly there's two separate flags on the get server: here's what the sign with and here's what to verify with so how's that different.

B

Yeah so I think the difference here is I would want a sort of, uh in the same way that I've asked for kmsv2 I would want a generic reference implementation that would work across any provider that you can just drop in right so like assuming, you can put it on disk beside the API server have a UDS running like if you can show me such an implementation that would be open source and under one of our staging repos I could I could I could buy that?

B

J

So with so, basically an open source version of the two flags from the API server. Let's just use in the API.

B

Yeah that could have distinct, signing keys or or some maybe not distinct, signing keys, but um something like a key hierarchy that doesn't require remote KMS calls unless I want that. So.

J

If we can have that sure, yeah I think that's that's definitely doable.

F

D

C

D

Had a couple questions I um I couldn't tell if this was, it was similar to what uh Mo was talking about, like um jobs can have like lots of different algorithms and even some sort of crazy things in their uh signature stances. Is this proposing something that could be uh so flexible that it would start putting like really really unusual or obscure things in the signing stanza and are we? Can it well I'll? Stop there uh I couldn't I couldn't tell.

J

I think I think the motivation for this is is mostly just to get signed. The biggest motivation is really to get signing out of the API server. Okay,.

L

You do that it's.

J

Basically, sending okay, here's the payload, yeah and I want these bits signed. So the signer then would need to come up with the header and the signature right. And could you introduce something crazy that does you know uh some weird algorithm? Yes, but the API server would just transparently pass that back. Yeah.

D

Okay and then and.

J

Then, similarly, like for verification, the API server would Plumb that back through to the side, to the over this API to say: is this verifiable or not.

B

Yeah, so I I think I would not be okay with anything that didn't have the API server controlling the payload so like the response from the signing operation should be the header and the signature and the API server, glues it together and makes the jot, and if that doesn't work, because you track the flex for the payload, it just doesn't work.

A

Well, that this is that would be part of the signing header, not the payload right.

B

Yeah, no I, don't care about yeah, so I don't really care about how you sign it. As long as you sign the bits that I sent you, you don't get to change the bits yeah.

A

I should feel less strongly about that. I think that it is as I think there is potential for um flexposure, actually um I think what we should.

C

A

uh We should create a PR that proposes these API changes. uh We should do the uh production, Readiness review um and uh discuss um offline and then in a follow-up meeting, um because we have a lot more on the agenda. So does that sound good? Everyone?

A

D

You Mike yep Renaissance.

A

Okay, we got an update from uh the policy working group. Would you like to would somebody like to present, um or would you like me to just open up the platform.

M

Sure I can share. My screen uh might be easier for.

B

A

A major Coast.

M

Yeah, so this came up um I guess you know, one of the touch points was from some kubecon conversations and the segment and greet I think um you know we haven't been I. Guess we haven't presented in a while or given an update on some of the projects, so I'm not gonna go through. Obviously this whole deck, but it's linked, but um this was a kubecon presentation myself and I have Robert and Jaya are also on the call today.

M

So we'll cover some of this, but really what we wanted to just summarize right now is some of the completed projects or things which are fairly.

M

You know uh or publish to some extent, for the paper and for this second item I'll talk about where we are and what we you know need might want to do as next steps um and then we'll talk about some of the future activities where planning or proposing or being discussed so about a year or so ago. Now we published the paper uh on kubernetes policy management talked about admission controllers, it's something we will. You know.

M

One of the interesting points is, but now with cell admission seems like it would be a good time to revisit, and you know kind of give some guidance on that versus admission controllers um and how the to work together or where you know folks would use one or the other, um and you know so, that's out there and you know, there's a link, uh I guess here also in the next slide.

M

uh So if there's any feedback any thoughts on what a we do would look like would certainly welcome those um and then the next item here is the policy report, crd so just very quickly. The intent here was to standardize on a custom resource that various policy tools, uh whether they're, you know admission controllers or their.

M

I

M

Of different sorts could leverage and we have created I'll. You know show some of the adapters we have done, and then uh you know where this has been used and there's some challenges, of course, that come up with managing things like policy reports as a CR, but uh various projects have solved them in you know different ways and then there's also mapping from the policy report to both. um You know those uh to oscow for compliance and there's a tool. I'll just jump to this slide.

M

There's a policy report tool which also can run in cluster, which is part of the caverno project, uh which can provide a view right so just very quickly. I have this running on my local minicube cluster. It's showing me all of the policy reports in this case from caverno, but could be from any of these engines right, it could be from group. Bench could be from Falco.

M

um You know, KUB armor is also another adapter, um and then you know we're in discussions and open to kind of uh creating more adapters if needed. Let me pause there and see if there's any thoughts, questions on these two items. uh We have a question on what we do next with the crd, because it's it's sitting in the work, Group, Policy, repo and I know back when we got approvals for that git repo. We had discussed that the intent was to prototype it uh and then figure out where it goes from there.

M

There is no controller tied to this. It's purely just an API uh definition for how different engines can you know standardize on a policy report which, of course uh is seems like a good benefit for operators and admins.

M

So any thoughts feedback on either of these.

A

Before- and you said this uh from from that table on slide seven this- that actually is the these are the tools that have adopted the crd. Is that what that means.

M

Correct to various degrees, some of these were you know, prototypes that you know we uh initiated from within the work group. Others have Incorporated like Falco and caverno. Natively use these uh Coupe bench, there's an adapter, so different tools have taken different mechanisms to generating policy reports um and then there's tools which consume the policy reports. The last two are consume. The policy report.

M

There's also I should say you know, there's you know on the commercial side of things giant, correct me if I'm wrong, but I think uh there's modules in openshift that use the policy report and uh you know, there's nermata and a few other companies are also using the policy report for dashboards, and um you know other higher level functions.

A

N

Hat has a product offering called that it had Advanced cluster management for kubernetes that uses it at the Hub.

L

I could say a couple: other GRC tools are either working on it or are using it today.

B

So Jordan I guess like an API review style question for you like. Would this? Would this be something that someone would write it kept for to basically state that I would want to make this like an official API of some sort.

D

um I I assume it's using like a X6 or xkates IO uh style. Endpoint um I mean if, if it's working and people have integrated with it like migrating that to be a case, API would mean everyone would have to change their migration Integrations, uh which is unpleasant.

D

um Yeah I mean I, don't know that it needs to change. If it's useful, the way it is, um and it's been able and useful I think that's fine. If it was going to start getting um like bundled with kubernetes, um then we'd probably want to shift it. Although the more uh the more Integrations it gets, the more painful it is to shift so, but.

A

I guess right now we are still in the working group repo for this yeah. If we want to, uh you know, have a better process for making an API uh changes or if there are issues with democratization of like all the different. You know, people that are interested. It might be good to move it to its own Standalone Republic, CRI API and you know, adopt like the kept process for proposing updates.

A

um If you feel like that is where you're at this looks like it has, you know pretty substantial adoption, so um that's that would make sense to me.

M

Okay, that sounds great. That's the guidance we wanted and if there's some precedence on this, that's fantastic right, because this is purely an API there's, no controller or anything we want to publish and um okay. uh That sounds good.

B

uh I guess a quick question for the group. uh Would would we even if we didn't ever move it into like a Kate's IO API? Would we still want to move the definition from like the working group repo into like an official yeah.

A

M

We have received that feedback right because our our repo says prototypes the whole uh that's somewhat of a deterrent for folks to build additional things on it. Although you know there has been some adoption.

D

The uh the secret CSI driver comes to mind as an API that a lot of things integrated with uh and ended up in its own repo that had other things associated with it. But um there was some good discussion around there about testing like how do you test a thing where you have an API and then you have a bunch of different Integrations with sort of externally controlled things, um but so so there's a little bit of prior art there. Maybe um in terms of an approach.

M

All right, yeah, we'll we'll dig into that, and then you know it seems like then the next step would be to propose a cap uh that sounds good that'll, be great to have this graduate to at least a separate repo, and we can of course, continue maintaining it and receive feedback on that all right. So those were the two projects we had. You know uh more or less completed I'll. You know let Robert and Jaya talked about some of the new projects uh we're discussing.

L

Yeah, just at a high level and I know you guys have a packed agenda, so we can keep this super short, but uh you know higher level. We we seem to attract a lot of folks in the community interested in that more GRC perspective on policy. So you know some. Some members have studied to use the nomenclature, big p policy for kind of that human, understandable uh compliance policy, security policy and then Little P policy.

L

You know things that everyone here is familiar with, and configuring and uh kubernetes cluster, and so a lot of the a lot of the members are trying to bridge that cap. So we spend a significant amount of time on you know, conceptualizing and trying to build a vocabulary around. How do you do that?

L

And what would that look like and then how do you manage both those big p policies and Little P config policies over time um and Jay I mean if you want to jump in and some of the uh things that you've seen in the field, maybe that we could enrich that discussion, but um that's kind of how we do we cut across several of the sigs. In that respect, that you know you can have configuration Little, P policy uh in a number of places, of course, in a cluster.

L

So not everything is just going to be admission, controller policy or you know, security policy.

N

Yeah I think I think, for what we are trying to do here is um there are so many different personas involved right in terms of uh taking making sure that various controls for security, resiliency Etc are operating the best practices so, and some of them are more smes on the technology itself, whereas others are more SMS on the compliance aspects right. The compliance standards like PCI stock, 2 Etc. So how do we Bridge the two gaps right and then bring them together? So that is what we are trying to do here.

N

So what we did last year. Is we authored this policy management white paper? Now? What we are saying is: okay, why do customers do policy management? It's a means to an end, and typically one of the end goals is Regulatory Compliance. So then, how do we Bridge what we did to standards such as oscal, that is defined for compliance right? So so that is kind of what this item number two is and uh and again you know we want to apply the github's methodology there as well and then.

N

The first item focuses more on governance, which is another business goal, and, and governance could be for operational governance. It could be for uh Financial governance as well as compliance related aspects. So so what we want to do is to kind of articulate how policy management can be used as a building block to achieve governance, goals and best practices for that. So that's, basically a white paper that we are authoring. So those are the two next set of goals we have for the group foreign.

A

Yeah looking forward to seeing the paper that sounds awesome.

N

A

uh um All right yeah, thank you. So much for the update um I will re take over the screen.

A

A

Okay, all right is that it perfect: okay, so um Mo all right. You have the floor.

B

So I think earlier this week we were going over what we wanted to update in the KMS V2 cap for like beta requirements, since we're nominally trying to Target uh 1.27 for beta, and so we were trying to write out like basically unit integration test requirements, um so we don't necessarily have to dig in too deep here, um but just you know at a high level, what do folks think should be covered um under those tests, so we're working on getting the reference implementation written now.

B

um The hope is to use that reference implementation in like integration tests- and you know, work- you know, make sure it all sort of works together.

B

um I've I also want to like see if we could build like a um not like a required test Suite, but an optional one that actually configures like a real API server with everything running and an actual KMS plug-in built using the reference, implementation and just does stuff and make sure it doesn't horribly fall over.

B

um Does anybody have specific thoughts on things they really want covered.

A

Yeah I would like to have um all of that run under written under tested integration tests um with the reference implementation into an sctd I think that'd be useful, uh I guess there are specifics here.

A

um These all sound good, and um we should add this to the cap under kind of graduation or test requirements, I think um and track them there um and We can brainstorm a little bit more when we merge that um kept change, but yeah these.

C

A

Reasonable and in general I trust you all to make good decisions.

D

Were you mostly wanting to exercise the logic inside the API server, or were you wanting to exercise the reference implementation, slash other implementations of the KMS endpoint.

B

So my my desire is that if you, if you have sort of like a a goofy, remote KMS implementation, that's basically just a local key, but you artificially introduce like a small sleep to simulate a network call. If you have such an implementation, that's using cam, sv2, I I would like you to basically be able to encrypt like a large cluster, and it just kind of works. Just fine right, because that's kind of the whole point of KMS V2 is that the outer edges that cam sv1 doesn't work so well on.

B

Those are the things that need to work better here, right like so um like well, like storage, migration and stuff I. Think we'll be able to test pretty well in, like a integration test that you know. Once we have all the apis set up, we can I think we could probably reasonably test them out working correctly, um but, like the scale version of this is a little bit harder, but it's I. Okay,.

D

That makes sense, maybe I would suggest making it clear that the point of the E to e test is testing scale um and behavior, with sort of the lag that you would get from a KMS um yeah. With that clarification. I like this a lot uh I was gonna suggest using integration tests as much as possible for all the functional aspects.

B

Yeah yeah totally it they. They just don't tell me if, like the core checkbox, so I can run this in my broad cluster by default is actually checked. Yep.

A

Cool sounds good um thanks. Moe yeah uh send us a update, I think uh that would be The Next Step, all right. um Daniel. uh You have the floor.

O

Did I hear my name yep so I'm, so sorry that I uh didn't uh show up last time. I almost missed this time too, because I was double booked, um but David bring me in time. uh Okay, you're, gonna, open up the cap. That's great um I'm, trying to remember the state when I last talked about this cap in this forum, I think it has changed rather substantially. Since then, um let's see uh I'll say the latest thing I did to it is um I removed.

O

So the the basic idea is: there's this uh stuff, we're going to add to the schema and the the stuff that we're adding to the schema describes how you can specify a special permission verb for a given field in the schema, and it is somewhat hierarchical. So you could give like a particular permission verb to mean everything inside metadata and another permission verb to mean everything inside metadata.labels and another permission verb to mean a specific label. Within metadata.labels uh all right. So that's that's like the the stuff that we would add to the schema.

O

Does that and there's uh another aspect, which is whether a specific permission is covered by enclosing permissions or not? uh And you need this if you want to be able to uh add a field which people don't get right permission by default um and I went ahead and and expanded the definition of what what things are uncovered uh to satisfy David's criteria.

O

So now, if you wanted to, for example, have a specific label that only people with a specific permission could modify, uh you want to mark that specific permission string is uncovered and then, when API server is evaluating, whether the change can go through it sees that this is modifying a field which has a permission, that's uncovered, and it has to check to see if that person has that permission, um let's see, uh did that make any sense at all. Given what people recall from last time, we had this discussion.

O

uh Basically this this. This satisfies the criteria that Jordan and David were asking for. As far as I can tell, um and oh, and so the important thing is that this, this notion of what is uncovered and what is covered has moved out of the schema and into some sort of object in the cluster which cluster administrators can configure.

O

So the important thing is that this can be chosen per cluster right, because uh we can't just unilaterally move things and like make things into uncovered permission, even though we would like to because it would break unknown amounts of users, and we don't necessarily know how to uh make at a corresponding permission to the uh with, like whatever authen system. Every cluster is using right. So instead we at least give the cluster administrator the ability to do that right.

O

So if they want to make something more more secure like they can make a particular permission uncovered and also give people who currently have the main permission, the special permission in their own auth system, because they understand how to do that. um I think I've talked enough. Mo.

B

So I was going to ask just some high-level questions. So do you imagine this unconfig sorry uncovered uh permission set. Do you imagine like a default policy of these objects that we provide going forward like, as we add things and realize that or decide that those things should not be covered by default? I.

O

Believe that by default we can, we can place new fields in in this by default. I, don't see a path for how we uh kubernetes could take existing fields and put them in the system, because that would break existing workflows. uh You know, if everybody were using our back, then we could do it right. We could we could. uh We could add a our back permission at the same time. We add something to uncovered and then, like I mean you're not actually more secure, because everybody that could have done it before could still do it.

O

But at least you didn't break anybody, um but given that people might not be using our back or might be using uh some other permission system, there's no way for us to like automatically uh Grant the permission to everybody who might be impacted, yeah.

B

O

B

O

We could we could. We could uh offer security bulletins until uh cluster administrators. Look, it's a bad idea to let everybody write this field, uh here's how to here's, how to lock it down without breaking anybody.

B

Yeah I mean I I. Guess I mean maybe you if, if this is an API, you could probably go further right and provide the yaml Manifest of what you believe to be best practice, even if it right right.

O

We can we can provide the we could provide the our back version and be like hey. If you don't use our back, then you got to figure out how to do this in your in your own system, whatever that is.

B

um Okay, the other question uh in uh one of the I think it's right under the user stories. There's a there's a bit about how uh labels would purely you could only target specific keys, but in other in, like I, think finalizers. You said you could Target specific prefixes.

B

It was unclear to me why you couldn't do key prefixes on labels, since very often you give like.

G

O

uh uh That may be an error. I I may have been trying to say that you we gotta, we gotta, choose I, don't know if we can uh well I I, you know if we can write down anything. We want right, uh I, think uh uh if, if label prefixes is what people want, then um we should uh put that in the verb it does seem like prefix is, it seems like prefix is the most logical thing to put in the permission system. uh I think David was asking for a specific field.

O

uh Some I forget what I have it listed in this somehow somewhere, uh but uh it was like if, if it's safe enough to just use the prefix and take and protect everything with that prefix, that seems preferable and more useful to me. uh If we absolutely have to do like both prefixes and um uh like specific labels, then we would like right now, there's only one slot to put a permission for a specific Concept in the in the schema as as it's written in the design.

O

So if we need like two different parameterizations for a specific thing, then we have to like figure out also the more parameterizations you have. The more things API server has to check, so I would really prefer if we just had one parameterization per field.

B

And is this uncovered uncovered? Permission said: is that a classical resource.

O

That would um I was assuming it would be. A cluster scoped resource uh foreign namespace.

F

Think that it makes sense to have the description of what is uncovered the cluster scoped, but the authorization check could include the namespace for the locator of the resource being checked. So.

O

Yeah I would expect that.

F

Yeah, you would basically have one definition of these are the way types are handled in my cluster or fields or ahead of my cluster, and then this is. These: are the authorization rules inside of my namespace.

O

Yeah that makes sense to me I think it would be kind of weird to have like the the permission type system, change per namespace uh that seems like it would make it really hard to reason about who's got permission to do what, um additionally, like not all objects, have a name space. So uh the what you have to have it like a both a cluster and namespace scoped version of this and I, don't know it seems like it adds a lot of opportunity to make mistakes.

D

I know that uh fine-grained authorization checks or something that the sell admission folks were talking about um I'm curious if we could use the same sort of mapping for a particular field path or like maybe comparing what it would look like to protect, um changing a label using this and protect changing a label using a cell driven authorization anyway,.

O

um I think it is worth discussing whether these two things uh collide or are both useful um I.

O

My current suspicion is that the fine Green auth in this cap could be implemented faster than the the cell stuff can be implemented, and this is certainly simpler and has fewer moving pieces. um I. Think there's, maybe some argument to be made about. Like some things are policy, and some things are permissions, and this is a permission system and cell is a policy system where policy involves things that are hard to check in binaries.

F

O

F

This as significantly different than cell admission policy, as we described it today, right I see the cell admission policy as making choices like if you are doing this and that or I am checking the value you are setting here uh and therefore I will run and create this secondary acclcheck versus this here is: are you mutating this at all, and this also allows someone to.

J

F

Modify a finalizer without getting all update Authority, for instance, and the cell validation rules do not so I.

O

C

O

That's that's a good point if you were to do if the only way to implement this with cell is to give people excessively large permissions and then trust the cell part to scope it down appropriately, um so that that's a significant difference.

A

So um I trust David on I know that we had um issues with uh that. We discussed operator lockout. That was a concern with the initial our back designs um and also I would be. um It would be nice to have some bounds on the number of subject, access reviews that were actually issuing intensely stuff explode um when people start using this feature um yeah and uh other than that I think I, trust, David and Jordan to lead the review on this.

O

um What uh yeah, what how much can you expand this like as written I, think this uh probably doubles the at least doubles the number of checks, so how many? How many multiples can you uh can you handle.

F

And to be clear, this doubles the number of checks if you have uncovered permissions on a particular type and it doubles the number of checks. If you do not have full update permissions and only have a granular permission. But in the case where you are not.

A

F

An uncovered field and you have update permissions. This is a neutral change. Current.

O

uh I think that's correct, okay, yeah! So.

I

For additional kinds.

O

Of requests that we don't currently support today, it's going to be more than double, but I expect those to be kind of rare um right.

G

O

Have if you have the general permission to modify metadata.labels and but not the specific or not the permission to update that resource type? uh It's going to be at least two uh checks to to validate you, one that you're allowed to do, use the granular permissions at all, and then one that you have that's a permission that specifically covers that um and if we set up recursive uh permissions or like uh hierarchical permissions like first we check. Do you have the general one, then do you have the metadata one then do you have metadata.labels right?

O

Like those add up, uh it should be log number of fields and not linear in the number of fields, all.

A

Right I think that's handleable. If uh we make a cap for it in some of the authorizers I know, there's room for improvement in the web. Food authorizer I I would really like to get to sergey's um item Tim.

B

Has his hand up Tim? Do you want to make a final comment? uh No, it's! Okay, I'll I, just review the cap offline and.

E

uh Leave comments there yeah.

B

Does this this kept motivate us to have like multi-subject access review, so we can just do one call and just be like here's, the 50 things I need to check. Please please check for me. I think that is.

A

Actually, potentially, maybe useful, um so we should consider that uh Sergey doesn't come to our meetings. Very often, um can you uh uh let's, let's hear that.

G

Hello, um thank you for giving me a space. I uh we've been discussing this big note uh whether we have any leftover, Panama betas, and we found this uh that did complete Services. You get a feature gate, uh so I came to ask whether there are any plans or help needed to graduate to GA.

G

um Thank you for links. You paste it below I'm a little bit surprised that the ga will require more features to be added because it's already in production, so many places. So it's like okay, it's already in production, everybody using it. uh Can we just GA with documentation and then have new features for people who need this new features or those are strictly required. So I mean, depending on the answer I'm like we may find somebody to help or may not find somebody to help. Oh, like we'll.

D

G

More assistance, I guess what do.

A

You think Jordan.

D

Yeah I stuck those links in I, um I mean the the feature works like the apis. There is obviously in use. It holds the information we needed to hold and people have successfully written uh approvers and designers against this API, so um I think for what it currently delivers like it's stable and it would be fine to Market as stable. uh It's a little bit weird to have the cubelet have a feature that has it requesting certificates and have no in Project version or recommendation of how to approve those things.

D

But that's sort of the nature of having nodes have generic ways of getting addresses like it. We're the kubernetes project is agnostic for how node determine their addresses, and so we also sort of have to be agnostic about approving that a particular node owns a particular address.

D

I would be plus one on marking the current functionality stable and saying if we want to have an entry method for validating node addresses, that's a distinct effort.

A

Yeah I think that is um yeah, that that would necessarily require another Camp.

M

A

Think we need to write a retroactive cap, even though it's basically de facto GA or.

D

um I think it's worth capturing the description of what it does and the couple open sort of unresolved things: I, don't think it has to be a long drawn out thing in the past, we've sort of copied, pasted, design, docs and described how it worked, and it didn't take long I think that's worth doing.

G

Past, like features as well so.

A

Cool okay: well, uh we can start tracking. This then, um and yeah, maybe discuss further on the bug to see um if anyone wants to volunteer to get this over the finish line.

G

Okay, this information I also will try to find some volunteers or maybe help myself awesome.

A

Thank you so much all right. uh That concludes it. For our cigar Community today see you all. In 2023 um and I will bump the agenda items we missed up to the next one all right thanks. Everyone take care.