Kubernetes SIG Auth, 24 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: sig-auth bi-weekly meeting for 20210324

Description

sig-auth bi-weekly meeting for 20210324

A

All right welcome everyone to possibly the final pod security policy breakout session on march 24th.

B

A

A

uh All right, can you all see my chrome tab.

C

A

um Would someone volunteer to take notes or um either in the sigoth agenda or just as comments on the cap as we talk through.

A

I'm in the cap I'm happy to write things up there if there are more freeform things, if someone wants to also drop them down in the agenda, that might be useful to capture flow of conversation. But I don't.

A

A

Any any volunteers for.

D

uh Additional units- hey- this is pushkar. I am new to the cigarette agenda template, but I'm happy to take notes. If somebody can point me where I have the doc open on my site.

A

um Thank you I'll drop, a link in the chat um you have. You may need to join sig off uh the google group in order to have editor access on that.

D

Yeah, okay, I just tried typing something I am in suggesting more. I don't know if that works. um Yeah, that's fine!.

A

D

Okay, all right good.

A

um Okay, uh where are we all right? um I think we can debate what color to paint this bike shed uh later on in the meeting, if there's time for it, um so I'm just going to actually uh before I jump through the unresolved session sections. um Is there any kind of big overarching feedback comments, concerns questions on the overall puzzle.

E

Where should we just go through the details.

A

Clayton left a comment that I don't understand, it was sort of a it was more around the crd stuff, so maybe that's more detailed. We can get to that, but uh any details. I I have a similar concern.

A

Okay, um I thought there was another one just talking about conformance thinking through conformance, I'm not sure this meets the default bar today and I didn't really understand if that was like an objection to the enabled by default or.

C

I think it's a concern about whether a conformance test would require this admission plug-in to be present and require certain pieces of configuration for it. You can imagine things like uh uh default enforcement level. uh You probably wouldn't want to make that a conformance thing requiring it to be on.

B

C

Is even a little strong, I.

B

Wouldn't want to require it to be on or enforcing anything for conformance, because because, if it's kubernetes, that means that running a pod gives you root on every node like in some sense, the whole purpose of this is to intentionally and surgically break conformance, as is the case with any admission controller.

A

Test which I didn't read as saying like this was going to be required for conformance, or uh it was just saying like how are we going to test this feature? So I tend to agree that, like on by able to be on by default is a good goal. If you don't have an opinion having it on by default. I think is a good thing, but I would be fine with someone running a cluster deciding in their environment. It should be off, but we're just giving them tools so that it can be on by default.

A

Reasonably yeah. Yeah dims also had a question around conformance, and I think a reasonable goal is that you should be able to pass conformance with this sonde and maybe even with this defaulting new namespaces to baseline or possibly even restricted, and that might require adding policy.

B

A

Labels to the e to e namespaces as part of the conformance tests. um I think I captured that in a possible.

A

E

uh Yeah so yeah.

C

I mean I think, it'll be possible to do it's just something to know you don't want to yeah, don't end up broken there. Yep.

E

um All right, let's see.

A

uh Okay, this is this has to do with naming so I'm gonna, I'm gonna, skip that for now.

A

um This is also more to do with language, but I think it's worth having this discussion.

A

So I like that, allow means what it says.

A

So if I say um I would like to allow baseline policy um really, what I mean is uh I'm going to deny anything above that, but it's sort of allow baseline is a. I think, a way that a lot of people will think about that.

A

The problem is that the audit and worn labels don't quite line up with that semantically. So if I say audit baseline, what I actually mean is audit record and audit annotation uh for pods that exceed the baseline value. um Similarly with warren, so one option we had discussed was something like audit above or worn above, but those are sort of uh sort of cumbersome, especially when you have audit above version thrown in there.

B

I'm a big big fan of the enforce it is. It is a little more ambiguous, but I don't think it's necessarily that ambiguous if you were thinking of it as an admission controller, because an admission controller enforcing its will on you means rejecting you when it doesn't like you so like. I think that the extra context helps it to not be as ambiguous as it could be.

A

D

That's earlier, this level.

A

That still has the same issue that tim said. So, if you enforce baseline, then then that's the level that you are that enforcement is is holding. If you warn baseline, uh if you that's still.

B

A

You won't actually get warned about it, so I I agree that they're confusing. I had a really hard time thinking of better names if people have better names for audit and warren I'd, be super happy to hear him.

C

I guess I'll say I didn't have that much issue with uh allow or enforce and audit and warn, but I really didn't like deny. um I had difficulty.

C

Like in my head reasoning about what I would put and deny.

A

Yeah, I think, I think, enforces better than deny.

A

I would be happy to continue treating audit and worn as placeholders and then have a big naming, yak shaving party, where we just brainstormed names for like eight hours, I'm kidding- I wouldn't be happy about that, but we'll.

B

Put that as the first item on the next sig off meeting right.

A

The next six yeah um okay. Well, uh uh I just wanted to kind of call out that piece. Oh sorry, someone else trying to um I think we can kind of take this discussion offline. um If you think of any ideas, then uh by all means, please drop them in there.

A

Otherwise, let's move on um all right, so versioning there's some there's some nuance. That needs to be worked out around versioning.

C

Did you skip over validation.

A

I did uh was there, did you have a concern around validation? I.

C

Do I I am trying to work out how important we consider the validation to be given that admission plug-ins are optional, so we wouldn't actually be able to be sure the data was right like is this just a and be nice to the user and suggest for them, or do we consider this important for data integrity.

A

I uh I had two comments about that. I I like keeping it gathered in the admission plugin so that, if you don't want this active in your cluster, you can actually like completely isolate it. Disable it um if it's also in the same bucket of code as the admission stuff, I'm envisioning, that being in a location, that's referenceable by things outside kubernetes kubernetes.

A

So that would make that same logic, usable externally, maybe against an older cluster as a web hook or some custom policy as far as data integrity, because this is being added to kubernetes 120, whatever, like we already have to define what how this behaves. If there are labels, we consider malformed with these keys.

A

So I I think we already have to define that, no matter what we do, whether we put validation code in the namespace validation path or an admission.

C

Then I think we should call out very I I don't have an issue with that, but I think we should call out very clearly that this validation is best effort and in no way protects the actual data that we have do you think there are ways to to tighten that if we really wanted to, I don't look at them and see them as being worthwhile, so.

F

Yeah we scrolled off the api section, um just we touched on this last time, but I didn't see any call out here um describing the decision to use labels as the main api versus creating a new resource. And I think that that feels a little bit novel to me and at least I'd like us to kind of make sure that everybody's considered the the trade-offs and that we're happy with them.

B

Plus one that I think labels are much better than creating a new resource. I say this is one of the primary people who used to be advocating for creating a new resource, but like calling out specifically. This is why we think it's better than creating a new resource like if it only takes a couple of sentences, could help people to understand it better. When they're reading it.

D

Yeah, I'm happy to add that.

A

um Just briefly going back to admission, I see this as or sorry the um validation. I see this as more guardrails to protect users against accidentally having a typo that causes their.

E

What they think is enforcing to be ignored.

B

Super fun from a persistence perspective too, like just intentionally misspell like enforce, like or or intentionally you know, intentionally misspell something. So then somebody looks at it and sees it, and you know thinks that they're protected.

A

Yeah, especially when the default is privileged.

A

I can add that into uh the validation section as.

E

C

Yeah, I guess I would also mention when you do that that like when you turn this on, it doesn't actually do that for for clusters, and it doesn't do that if you ever turn this off and that's fine, but just making people aware yeah.

A

The the typo in a label is another reason I really don't want unwieldy label keys like worn dot above or worn dash above or worn if exceeds level like the the weirder and longer and more hyphenated dot delimited. We make these label keys the more likely they will be typoed yeah, the uh the prefix is already getting pretty long.

F

And the scheme hasn't really defined anywhere concrete.

A

um I don't know if we want to chat about the the label versus distinct object here or just take that offline and kind of circle back if there are still questions.

A

I'm happy to discuss it here. I briefly was considering whether we should consider adding fields to the namespace itself.

A

The nice thing that the labels get- you is the ability to make queries like show me all of the late all of the name, spaces that are not pinned to the latest version or show me name spaces that don't have a policy set on them. um I think you demoed both of those.

C

Labels also get you uh versus versus objects. If you only have you know a fairly small enumeration of these things and you're not going to allow any customization, you would end up having very few api objects relatively right either that or you would end up placing an api object inside of a namespace that would prevent present some sort of read.

C

Challenges not not an impossibility, but um you would have to dig down and then find the parent name, space sort of thing.

A

The the ability to do things atomically was also so the being able to do things atomically and having a singleton per namespace.

A

Those were the two reasons that I liked having it be on the namespace object, so we had talked about like having a single policy level applying to a namespace for a given action, and if you had a separate object, you would either have to make it a singleton like say, the name of the object must be default or something or you open the door to having like multiple competing objects applying or um yeah, or you have multiple competing objects applying uh which actually makes dry run.

A

Scenarios really hard to reason about, like you're, not sure which one level policy or enforced level policy is effective.

A

The atomic thing this lets you create a namespace and define the policy level for it in a single shot, instead of like create a namespace and then create an object inside the namespace and in the window in between hope that no pods get created inside it.

F

Don't you still have a race until the mission controller observes what the labels are on the name space.

A

Not the admission controller uh only allows pods that it can find the namespace for so the way my proof of concept was written up when a pod comes in. It looks for the namespace in the namespace and it's informer, and if it can't find it, it does a live get of the namespace. So it will never allow in a pod that it hasn't explicitly gotten the names for now.

B

A

The level later there's certainly a race condition there right like if I have a namespace and something's creating pods and I'm like I'm gonna, lock this down like yeah, there's a race there, but there was already a race there.

B

Yeah, that's inevitable.

F

Okay, it makes sense.

B

I do like the the um the labels versus adding fields to the namespace, um just because it makes it more clear. I think that that this admission controller is not part and parcel of the core kubernetes experience like those additional fields would be really weird in clusters, where you turned this off, because you were using gatekeeper.

E

A

Okay, can we talk about.

A

A

um So this first question is around: um what do we do if the so in the web hook implementation?

A

This wouldn't be an issue with the built-in one, but if you're running like say you decide that you know we ship this in 122 and you'd really like to run it on your 119 cluster. So you run it as a web hook or you know in the future.

A

um Maybe there's a new policy that comes out in kubernetes, 128 and you'd really like to get that policy level on your or those policy changes on your 126 cluster. So you can run it as a web hook to kind of backward that essentially.

A

A

If we do that, how do we want to handle the case where your cluster is running um 126 and you're? Asking for the 128 policy um again in the built-in version? We would just consider that as latest that's required to handle version skew and back ports or rollbacks, but in the web hook case we could say that if you ask for the 128 profile and the web hook knows what the 128 profile is, then it can actually enforce that.

A

There's one caveat that supposed the 128. You know supposing 128 we add some new field that adds on some additional restrictions on a pod and we decide this is best practice and you should enable it in the restricted profile.

A

Now the 128 restricted profile might require you to set a field that doesn't exist in the 126 api version, so it would be impossible to to meet those requirements.

A

Oh, I'm still printed.

B

On the 10. yeah, like you asked for it, you did the work of extracting the code out and running it as a web hook, like I think, if you're that sophisticated you, you understand that well,.

C

I guess I don't have an example that would immediately bite us, but I can see someone not expecting the latest behavior to choose the latest available for the web hook and not the latest with respect to the cluster.

C

I can imagine someone being surprised by that. I also don't think we require slash version to actually return the cube version in terms of conformance, so I don't know how you would discover what version a cluster is at.

C

I didn't think so because for a while in openshift we had an accident where we returned the version, as version three.

A

That's just because you love version endpoints david! That's why you have so many of them uh yeah I mean I like my first thought would be when you're running it as a web hook, you get to tell the web hook what what does latest mean, like uh I'm running my web hook on a whatever server, so latest means 117., even though I built you with the library that understands like.

D

A

One can you share a web hook across multiple clusters across multiple versions? Sure sure, um then you can't necessarily resolve unless you can identify on the incoming request. What latest means at that point right? You must a priority know. Obviously we would make the version into the path of the web hook. No, it just gets squirrelier and squirrelly yeah, but the thing that I don't like about making a web book enforce. The version is because it's surprising as a normal person, because the policy is written in namespaces on the cluster.

A

It's not like. Yes, I understand the web hook is the enforcement mechanism, but I edit my cluster and name spaces on site cluster to cause changes in behavior.

A

Like I don't know, I can't imagine myself wanting the 118 policy on a 117 cluster, because I don't know what that means, because I don't have a time machine that lets me go in the future or I think I guess technically I'm going the past in this mode, and I definitely can't tell you well. The point is that if you don't specify a version like you're going to get whatever the web hook, thinks latest means which depends on what version of this policy it was built against.

A

All right is it. Are there concerns around this specific to the like a web hook-ified version of this.

C

Or yeah, that's the only one get a version for, but actually thinking about it once it's built in. Why would anyone install the web book.

A

uh I kind of agree, I mean.

B

I guess because.

A

You're not allowed.

B

To alter the api server flags on your hosted, kubernetes version.

B

Medically speaking,.

A

So if you were on a hosted version that chose not to enable this, even once it was built in that's one possibility.

A

Another possibility is a custom policy that is linking against this component and then layering on some stuff of its own. So they want like mostly this behavior, but with a tweak and so and they're.

B

Willing to fork for it yeah.

A

Or or build on top of it, I mean I don't think they'd even need to fork it like you can like that.

A

The runtime class thing is a good example like if, if baseline is effectively restricted with a given runtime class, then like, I could use this and say I'm going to apply the baseline policy when I see restricted, plus function, class foo.

A

To answer moe's question also why you might want to run a 118 policy on a 117 cluster. We might, uh I can think of two possibilities. One would be. We decide that something that we didn't use to consider best practice is now best practice, so we make the restricted policy more restricted.

A

Another one is this actually came up when we were debating whether to allow patch versions in the version information is, I could imagine, having a cve come out that exploits a field that wasn't previously restricted and we decide. Okay, we weren't thinking about this in the past, but this should this field should really be restricted because it can lead to this exploit.

A

So we add that in- and we would just add that into the next version- and you might want to backport that as a cve effects.

E

Wouldn't the backboard cve fix apply to the old version and thus.

A

E

A

Old version of the policy, but within your version of the webhooks.

D

No because we wouldn't.

A

We wouldn't be able to back port if it was a breaking change like an additional restriction, we wouldn't be able to backport that to say the 117 profile we'd have to add it into the 118 profile.

A

Is there any value in supporting more than I guess not I I was thinking about, then, is, if you you're in a situation where you can't easily upgrade your cluster. I guess that webwork would be your way out. Yeah.

A

um There's another concern around kind of version sku with the web hook, which is, if I forget, to upgrade my webhook and no one's really looking at it web hooks at 116.. The cluster is now at 123.

A

and I think I'm getting the latest version of the policy on 123, but it turns out that there's a bunch that's not enforced.

A

um We could just say that's part of the operational burden as you you're on the hook.

C

To keep this thing up to date, I mean you could also say that someone wants to add a field to the admission review.

C

Like say this is the version of my cube server.

C

That would seem to be unambiguous. Is it useful for anything besides this I'm not aware of anyone requesting it, but I'm not viscerally against.

C

A

um Okay, I think we should move on I'm trying to capture some of this in the discussion. Just to like remember what we talked about yeah. Thank you.

A

Did you have a question? Can we move on okay um covered that um okay, under an older version of the policy new field, may only be set to its default value or left unset? So um let's say so. This is the case where I have my policy pinned to 122.

A

I upgrade my cluster to 123 and we add a new field to pods, so for backwards compatibility uh all the policies need to allow the unset or default value of the new field, so in other words, pods that were allowed in the previous version are still allowed without setting that field.

A

um There's kind of there's two questions around this. The first is: do we want to restrict all new fields that get added to the pod um with version skew, or should it only apply restrictions to fields that we think that we're going to have an opinion? The policy is going to have an opinion about.

A

To give a concrete example, let's suppose we add a new a new resource field, uh maybe pod overhead? We can use that as an example. um That's something that the policy controller is probably not going to have an opinion about. Would we say that you have to use the default value or upgrade to a newer policy version? That says I don't care about this field.

B

Yeah, you gotta completely ignore every pod field that didn't exist at the time that that policy was written, because you have no idea what that field could be. You have no idea what it could mean.

A

I think I agree on ignoring fields that we don't care about, but suppose that we added a new type of privileged. um So maybe we uh decided to have a privileged email field right, yeah, superb, run.

E

This pod, as a.

A

Uncontained host process.

B

It's cruise control for cool yeah.

A

Yeah, so that's a case where I would definitely expect that field to not be allowed under the baseline and restricted policies.

B

Under the versioned baseline and restricted policies for previous versions that didn't have that feel.

A

Yeah because then it was impossible to set that field in 110. like you, you could not set super privileged true in 110.

A

And so new fields that the policy has an opinion about can be enforced as long as uh they're allowed to either be unset or have their default value. I think.

D

Like same thing,.

A

If the thought experiment is um every every pod that was allowed in that old version by that policy must continue to be allowed. I think that's the guarantee.

A

um And so then, if there are new fields we can decide like? Is this a field that we have an opinion about like pod overhead? No, we don't have an opinion about it, so, like whatever, if you want to quote it, knock yourself out, but we don't care. If it's a field, we have an opinion about like super privileged or host process.

A

If it's new, as long as like it being unset or the default value for the baseline policy, is permitted like every old client will be kept whole like we're not going to start breaking an old client that was successfully creating this pod.

C

Are we trying to provide this guarantee, assuming that we have updated our admission, plug-in and you're running the updated one, or are we gonna try to find a way to do this without having updated that web book? You could imagine some things like I'm given a schema. That seems quite difficult.

B

This is like a reason not to run an older web hook on a newer cluster, because it's built in it.

C

Is but I I think we do that by accident.

A

I think this this question mostly applies to the built-in version. I think we just need to say that if you're running the web hook, best practice is to upgrade the web hook before you upgrade.

C

Your cluster, okay, just just want to make sure I've understood the constraints on it, because then we can actually at least say like yeah. We know this new field came in and we care oh yeah. It.

A

Does mean that if you're not running an up-to-date web hook, the behavior of a pinned version could be slightly different, but I'm not sure that there's much we can do about that.

B

Talk about web hook. Are we actually talking about making a web hook, or is this in a hypothetical case where somebody makes a web hook by importing the go packages.

A

So the proposal is to um to have an officially supported, implement webhook implementation. So basically we would implement the. We would implement the core logic as a library in a separate repel, and we would also have a.

A

You know a containerized web hook, implementation of that that you can run um and then we would also import that library into kubernetes for the core admission controller.

A

Logic, that's open for debate, but that's.

B

A

We think that's.

B

Valuable enough to take on that maintenance, overhead forever.

C

I think the maintenance overhead is fairly minimal, given that this particular one isn't one that would need to provide uh it wouldn't need to identify whoever calls to it. uh So it would be very similar to the sample that we provide already with uh with for our ede tests, uh and I can see value for cases like you mentioned, where it's not there in somebody wishes to add it as a web book when they aren't cluster admin or they aren't able to administer the actual qapi server.

A

I think the biggest maintenance burden would be building and shipping the container release every version yeah I mean we ship sample extension, api server images that we use in ede tests that are kept up to date. This seems like it would be a similar level of difficulty.

A

I I think if we are wanting these, um we talked about the tests for these being written in a way that they could be run against this reference implementation or against.

A

uh Another implementation, and we'd also talked about like this reference implementation being able to be used as a building block in someone's custom policy, and so both of those aspects make locating the code in a place where it can be consumed very attractive.

A

The the actual web hook server shim over that, where you decode a thing and then evaluate it against this policy, like I don't think that would be the majority of the of the code we'd be supporting and that.

B

It's not a heap of go yeah.

A

C

A

Are like a couple files like one for the inputs and one for the admission review decoding code cycle, but then the bulk of it is going to be the actual policy and the actual tests.

A

It might be a heap of boilerplate um david thinking back to your question about detecting I. I think it would actually be easy to detect when a server that knows about pod fields that we don't know about is sending us an admission review.

A

I could see an option to say if we, if we get sent pod fields, we don't understand like don't, allow it.

C

I can see that I don't think you'd be able to interpret default values.

B

You wouldn't care, there would just be a field on a pod that you didn't like and you'd tell it to go pound sand.

C

I could see rejecting that, but then it would be inconsistent with the behavior of the built-in admission plugin.

B

I imagine you'd do it like as a command line option on your web hook, that you would have to turn on if you wanted to be like super weird, strict, I'm running something in an anachronistic way mode. I.

C

Wouldn't go as far as as super weird, like we've had cases in the past right we've had innit containers, they came in we're. Looking at adding the debug ephemeral containers right. There was a discussion of attempting to do post hooks, there's a discussion of additional fields for windows. Right. I see, I see cases where we are talking about adding fields that matter I'm. I can see a reason to allow fields with default values.

C

Many of those defaults will be filled in right. Api defaulting fills them in before you call this webhook.

A

Right, so what I'm saying is if we want to ensure that the web hook is updated prior to the server so that it understands all the fields the server does, then the presence of those defaulted fields means that the server is newer than we are, and so you could tell the web reject pods sent to you by a server that have fields that you don't understand you couldn't. I don't know if we want to.

C

C

Right but we could not say allow default values for fields right, because I don't know.

A

I'm just trying to think of ways to help people avoid foot guns and help and try to decide which foot gun is worse, like forget to upgrade your web hook first and then not be able to create pods or forget to upgrade your web hook first and then be able to create super privileged pods.

C

A

I think we shouldn't optimize too much for the webhook case. I think that there's value in it in shipping it, but in terms of kind of making the really streamlined process, I think we should focus on the built-in one um for time's sake. I'm gonna propose we move on.

A

um There was one other open question around um uh new fields.

A

uh Should we restrict it to only the default, slash, unset value, or do we want to go so far as to say if there are strictly more privileged options?

A

Those are allowed as well, less yeah, so allow privilege escalation as an example um prior to what uh what is it like one, seven, um you uh like a restricted. There is no concept of allow privilege escalation. So all pods have it implicitly, so the restricted policy doesn't have an opinion about it.

A

So if you're pinned to 1-7, then come 1-8, we would say: okay, you're allowed you're allowed to set the default value, which is true on the restricted, the one seven restricted profile uh level.

A

Do we also allow you, on the one, seven restricted profile, to set the non-default value of allow privilege escalation equals.

B

False this basically comes down to if we conceptualize every new pod field that is relevant to the admission controller as defaulting to safe or defaulting to unsafe, then the ones where the, where the new one defaults to unsafe, do we allow adding the safer non-default value yeah.

E

I think we can just allow it, it seems good, I think, that's the superior experience.

A

There could be cases where it's a little like it's a little more ambiguous and I think, if there's any ambiguity, then we just deny it.

B

So like that would be for an example of if we had a release of this before runtime class was added, and then we add runtime class, where changing runtime class clearly has a security impact, but that security impact is unclear. It's like a side grid.

A

Yeah that's a good example. um Adding a new volume type might be another example.

C

So are we maybe some of this comes down to how you were planning to determine whether a pod that you got had a field? You didn't recognize that was defaulted or whether it had a field. You don't recognize that was set.

A

Well, that's for the webhook.

E

Case well for both right.

A

uh I mean the field you don't recognize is easy like round trip it through your typed v1 pod, and if it's not, if there's any diff, then there's a field, you don't recognize, I don't think we should. I don't think web hooks should get in the business of trying to figure out defaults like yeah.

C

If you want to do something.

A

It's just like fail.

C

On unrecognized fields like that, I was just imagining this as something we would try to write once per release and never touch it again, uh and so we would try to do something like clear the fields we don't know and run it through the defaulting chain a second time, and we have all the code to do that. We can just call set defaults on pod and if you get a diff- and it is not the same that came in to you- you know that it was not a default value.

C

That's what I was expecting, so he never had to touch it. If that makes sense,.

A

um I was not expecting this to have access to the defaulting code.

A

um In terms of like philosophy for new fields, I think we just talked through examples that make sense, and I think we agree like uh you- should allow things that previously were allowed, so it allow absence of a field. You should allow the default value, at least for the baseline case.

A

You should allow them to opt into a more restricted version, like all of those things make sense, I think writing up those like litmus tests um to help us evaluate new fields would be really useful. Yeah we'll do um all right, I'm gonna say: let's move on.

A

um I think I'll I'll update these with what we've discussed, um but there's probably still some nuances that are a little unresolved, which we can follow.

E

A

um I'm going to punch on this one, it's a detail: we can work out offline. um This should be a quick question.

A

um Should we when a new namespace is created, um I suppose this is this would make it a mutating controller um so there's that issue, but should we set the default policy mode labels on the namespace, so, for instance, if my, if I've configured my cluster to say no label equals baseline, if I create a new namespace, would you expect it to be to get the baseline label added.

B

I think I would expect that if, instead of setting no label equals baseline, if you set new namespace equals baseline.

A

Yeah, I think, in the interest of avoiding mutation completely I'd like to just leave this off.

A

I I really like clean separations between user data and non-user data when possible and being able to look at a namespace and tell the difference between, like a user or, I guess, an admin who is managing this namespace had an opinion about the policy for this namespace versus, like it just got created like during the month when this was the default.

A

I like not mutating it, so we can tell the difference between those two.

E

I agree: okay, let's call that one resolved.

B

That also makes it so that changing the unlabeled setting on your cluster does what you think if you mutated it, then changing the unlabeled setting on your cluster wouldn't actually affect any policy change, and that seems weird.

A

Yeah, the uh I think in the demo I showed you can you can find namespaces that haven't explicitly expressed and like if we stomp the labels on them, we've lost data there not being able to tell the difference.

A

um Okay, hopefully another quick one. um Should we default the cube system or the cube system name space to being exempt or for kind of when we auto-create it? Should we automatically add the privilege label to it.

B

I feel like this should be punted to distributions.

B

But I would love to hear what y'all think about the idea of punting. Something like this to.

B

A

I like not treating cube systems, especially, I think in the early days of cube. We like really really didn't, treat it especially now. There are a few concessions like you can't delete it because it deletes the kubernetes service and that can be impossible to recover from, um but not every cluster has to run privileged things inside keep system. If you're, not self-hosting stuff, you don't.

B

My clusters don't run anything in cube system right.

A

If you don't yeah, so the fact that it's entirely possible to run a cluster that doesn't run privileged things inside cube system to me says we shouldn't make that a default or force that choice on.

D

A

Cluster operator, okay, sounds good.

A

um Okay, we're coming to the time limit. I would like to talk about updates, um but before we do that, um do folks want to have another one of these discussions in two weeks or should we take everything offline on.

E

That cap at this point.

D

Well, on that one, I'm actually curious about whether we got any good feedback from the survey you.

A

D

Out and whether that's worth discussing for a future meeting.

A

um I uh I can think about sharing an anonymized version of that feedback. um I there were some comments on there. I felt like they were mostly comments that we had discussed in the past.

A

There wasn't anything that I particularly felt the need to discuss in this meeting here, um but I can look.

E

Into sharing some of that.

D

Okay sounds good.

B

I would lean towards let's schedule another one in two weeks within the idea of having a check-in like part way and if things seem to be rolling along asynchronously such that the meeting doesn't seem necessary. Then we cancel it but like in in the history of this project having deadline driven development has actually seemed to help things roll along, and so therefore I wouldn't want to give that up like at least until the cap is merged.

A

Okay, I'm happy with that.

A

I was just gonna do this was pretty high bandwidth. I I appreciate you bounce back and forth quickly. Yeah and uh all these everything we've talked about is going to go through the cap anyway, so anyone who's not able to make the meeting we'll be able to follow. You.

C

Imagine there's going to be at least a couple more sorry. I do imagine there's a couple more points that are going to benefit from a fast back and forth conversation.

A

Okay, um one said we don't get to talk about updates, but uh I think we should probably call it so everyone can get to the next meetings so yeah. Thank you. This was useful.

A

We don't need to wait until the next meeting in two weeks to follow up on some of these unresolved issues. So um if you have time before then to uh to leave additional comments or uh weigh in on some of the unresolved sections or existing common threads, please do and I'll make an effort to update um push and update with uh what we talked about today, probably won't get to that. For a few days.

B

I want to say thank you all so much for for having this thing continue to roll along we're doing so good.

A

Yeah, thank you.

D