Kubernetes SIG Auth, 7 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

sig-auth bi-weekly meeting for 20210407

A

And welcome to the psp breakout session for april 7th.

A

um I would like to pick up where we left off on the cap and then uh time allowing we can go back to um some of the earlier unresolved areas and uh some comments that have been raised since the last time we met.

A

Sorry, um second, pull that.

A

A

A

B

A

Last time we left off at the updates.

A

A

A

So um the question here is when.

A

Sorry, page page back in what we were talking.

A

A

uh Right so um uh this would mostly come into play if, let's say an exempt user had created a pod and then a non-exempt user edits that pod. How does the policy apply um or, alternatively, if a pod was in the already in the name space, and then the the namespace policy was updated so that the pod is now in violation of that policy?.

A

Does that mean that pod can no longer be edited until it, unless that edit makes it conformant with that policy? um So I uh I'm proposing that the answer is no, that we allow edits to um anything except the fields that are enumerated here um or sorry. Every we.

C

Nothing except for the fields yeah. Thank you, allow edits to these fields.

A

Yeah, um so there's not actually that much of the pod that is mutable and so most of the fields that we care about for the security policy um are actually immutable.

A

So the ones that I listed out here are the secomp annotations, which are going away in 122. um the app armor annotations um I listed out here, but they're actually immutable. So this is sort of irrelevant. um We would allow updates to active deadline seconds and tolerations, both of which are mutable.

A

The notable one that we will not allow is changes to container images, as that would potentially let you run arbitrary code with something that's not conforming to the policy.

D

A

Immutable, it is not actually, unfortunately,.

C

And isn't that weird that so many other things are immutable, but what code you're running totally changing yep.

D

A

uh Yeah, I can't I can't remember the history on that.

A

Yeah so uh status and node name are handled through sub-resources. um I don't think we care about anything in the status of pod status from the policy perspective, so I think it's okay to just ignore status updates.

A

D

Is configurations a tricky one? Could it be that somebody creates a pod and doesn't want with with certain security exceptions about what it can access on the host and then and but but wants that only to run on a subset of nodes that are less, you know sensitive or whatnot.

A

um The way the policy pod security standards are defined today uh they don't care about scheduling constraints, um so I definitely agree with you that there's cases where you might wanna have like a dedicated set of uh dedicated set of nodes and have separate policy around that um the way I would tell someone to to make that work with the policy we're proposing here is to say um you know this namespace runs as restricted, or maybe this namespace runs as privileged, um and only pods in this namespace are allowed to run on these uh nodes, so kind of have a separate policy applied at the namespace level and just rely on composability of this rather than enforcing it.

A

Through this one.

C

Question about that, how would you restrict these nodes are only allowed to run pods from this namespace.

A

um Yes, you would have to say: uh you'd have to have a separate policy mechanism that says um well. So, first of all, you need to taint those nodes um to prevent anything. That's not tolerating that taint from running on them. Then you would have a policy that says only these namespaces are allowed to have this toleration.

A

There's a few notable corner cases that you have to cover: one is wild card tolerations and then the other is manual scheduling. So you can't create nodes or create pods with the node name preset, um and you can't grant the binding per uh the bind permission to users.

C

A

For the record.

C

Do you know of any off-the-shelf admission controller that allows setting that sort of policy?

C

Without writing code like I can see how you could write a fairly simple admission controller yourself to do that, I can see how you would like write that in rego and and run it in gatekeeper. But like do you know of an off-the-shelf solution to that.

A

um I don't know if gatekeeper, if the gatekeeper policy, library, ships with something like that um there has been a fair amount of discussion around a built-in scheduling policy um that would limit things like node, selectors and tolerations and other things around that that policy I can. I can find the proposal and link it uh to the agenda later.

C

That would be a nice that would be a nice um companion to this. For, for somebody who wanted to do some more sophisticated policy things in their cluster, but didn't want to go to outside of the outside of the project, solutions.

A

Yeah um the when that proposal was raised, um we were still kind of undecided around the direction that we were going with pod security policy, um and there was some questions around. Are we just gonna push all policy out of the cl out of the cluster out of built-in um things, so that was part of the reason that that didn't go anywhere.

A

Once we have this proposal merged, it might be a good idea to revisit that.

C

Because it's explicitly setting the precedent of a minimum level of policy functionality that meets certain simplicity of use case criteria is important to have in upstream, but with the with the understanding that, beyond that simplicity, criteria is a third-party opportunity.

A

Yeah, but one thing I would caution about that is, um I think, uh setting having dedicated node pools um is not a super simple use case. I think there's actually a lot of kind of nuances to how you do that. um That means, depending on that for a security, boundary uh actually sort of um very error-prone.

C

I love that kubecon talk by the way. I love that whenever I have the chance.

A

um Trying to remember what, if that was public knowledge, uh but yeah c c, kubecon talk.

C

Link in the notes.

A

um Okay, uh so going back to the um pod updates, is there any concerns over what's written out here, or should we just consider this resolved.

C

It looks good to me.

A

A

um Moving on uh ephemeral containers, um so if anyone doesn't know ephemeral, containers is currently an alpha feature. I think they're targeting beta in 121, but that may have been pushed back in part due to the some issues that were raised around this proposal.

A

So ephemeral containers are containers, it's basically like mutable containers on the pod, so you can add ephemeral, containers to a pod.

A

That's only done through an ephemeral containers sub-resource, but one of the challenges there is that the ephemeral container sub-resource takes a different request type. It doesn't take the full pod specification. It just takes the um basically the ephemeral container that you're adding to the pod, and so what that means is that an admission controller operating or looking at those requests only gets um only gets the uh ephemeral container. It doesn't get the full context for the whole pod.

A

So if you have you know your baseline policy says you can't run um host network or something and you're adding an ephemeral container. You can't tell if it's being added to a pod with host network, um so uh one option would be to say that we only check the fields that are on the ephemeral container and ignore, say: host network checks.

A

That kind of thing um that sort of goes in against what we were just talking about in the previous section, where we don't want you to be able to update the container image on a privileged pod in an unprivileged namespace.

A

So this would be kind of if we only checked the fields on the container. This would be sort of a workaround for that.

A

So I think we probably need to get the full pods back.

A

So currently, ephemeral containers don't have um don't have security contexts, but that's also something we're planning to add um soon. I think again, I think that got slipped out of 121, so we will want to check that once it's added.

A

Yeah any questions about.

D

That, for if you did, need the full pot spec is there? Are there any race conditions in resolving that, given that it's not present in the in the sub resource request.

A

Yeah, so not for the not for the built-in admission controller. I don't think.

A

I think it should be safe with the built-in controller, since all of the fields that you'd be checking or almost all the fields you'd be checking were, are immutable. um It's possible. There could be some sort of edge case there, um but for if you're running in web hook mode, uh there would definitely be a race condition.

A

A

However, I think that we're going to change the admission um interface for that, so I think it should start getting the full pod spec once those changes go in again. This is a feature that's currently in alpha, so it's I kind of expect it to change, um and now that we have an actual proposal here, we can make sure that uh they sort of track together.

A

um But the other thing I want to call out around ephemeral containers is um so the the target use case for them is debugging, and um I think it's a common uh case where you want to run your production workloads in, like least privileged mode, but oftentimes to effectively debug. You need elevated privileges, um so the example I gave here is cast as p trace. If you wanted to p-trace that process for debugging, um I believe that requires uh the privileged profile today.

A

um Another example is cabinet raw which we would drop from the restricted profile, but if you wanted to say, do a trace route, you would need uh cap note raw on that.

A

So there's uh this is probably more of a future extensions thing to consider, um but that would be if we wanted to allow you to have elevated privileges, but only on ephemeral containers.

D

I mean, I think that that makes sense. I I don't see it.

C

I don't sorry doesn't say I don't remember what the uh what the are back around ephemeral containers looks like. Is there separate? Is there separate control possible for who can create ephemeral? Containers versus like who has create pod because, like what I'm trying to think through here is, is whether we can allow this kind of breaking policy, but only for ephemeral containers without that, actually just meaning that the elevated policy is what applies to most things most of the time and like one way that I was imagining.

C

That would be in the configuration where certain users are allowed to bypass policy.

A

C

Remember if that was only hard-coded users, or if that also included hard-coded groups, but like in principle, then you could have a like.

C

You know cluster name, colon debuggers group that was allowed to bypass policy here and then without any further changes.

C

If you allowed, you know the staff who would want to debug things to have impersonate privilege onto system debuggers, then normally they couldn't bypass any of these things, but when they did coop ctl debug, if they added the appropriate dash dash as group option, then they could put an ephemeral container. That would break policy temporarily.

A

Yeah, that's interesting, um uh so yeah the um there, because ephemeral containers are only added through the ephemeral container sub resource. um Then you can control arvax separately. On that um I, like the idea of using impersonate, uh we don't. um We said that we explicitly didn't want to allow uh group exemptions, um but that doesn't actually matter for the impersonate case.

A

You could just have like um you know, ephemeral, debuggers or whatever, um and then just through our back control, who is allowed to impersonate that user and then just grant that user permission to add ephemeral, containers.

A

D

So, does that mean that that to do this correctly within a namespace, those debuggers would not be allowed to otherwise create pods, but they would be able to like could. Would there be a workaround where, because they're able to do that for ephemeral uh containers, they can also create regular pods and basically do it for everything.

A

Yeah so the way I would suggest um setting this up is uh so you say this made up username that doesn't isn't an actual username, that anyone could have. uh You know, system, colon, ephemeral, debuggers or whatever um have it as a one of the statically configured exempt users, and then only grant our back bindings to allow them to to allow that user to operate on the ephemeral container sub-resource.

A

So they wouldn't be allowed to create or update pods.

A

Just create and update ephemeral containers um and then just control, who has impersonate permission on that.

D

Okay, so when they're impersonating to that it wouldn't have any other privileges, and so they wouldn't.

A

D

To use the exemption for regular pots, yeah.

A

Yeah yeah and then, if they are not in person, so if they're impersonating them, they can only operate on ephemeral containers. If they're not impersonating them, then they are not exempt from the policy.

A

um I will update that section with that suggestion.

A

Any other comments on ephemeral containers before we move on.

C

I guess I would just ask: did that little diversion into our back and exemptions actually help to advance the discussion here around ephemeral containers, or did it only serve to make it more complicated, because I was actually hoping to have this resolved, but I'm concerned that instead, I made it worse.

A

uh I think that was very helpful.

A

It means that we don't need to build some special, like second-tier policy level for uh ephemeral containers. If this workaround seems sufficient, it is a bit of a kind of a little bit of a hacky work around, um so we might want to think about if there's a way to kind of streamline the user experience on this.

D

I was going to say, like maybe client support, to make this yeah hidden from from you would would help, and also we need to be careful about documenting how to set up the permissions properly to be able to use ephemeral containers at all, because I think this will be very common uh problem that people run into.

C

Then all of that said, I really like the idea here of just ephemeral containers being subject to the same policy restrictions, because that seems good from a principle of least surprise standpoint like if you just turn this on then ephemeral containers are not in any way uh a side door through your policy yeah and then, if that limitation, which is beautiful in its simplicity, but is a big limitation.

C

If that limitation is a problem, for you then, like here is here, is a documented way that you can, you know, put a doggy door on your policy but control who can open that doggie door so huzzah. I will step out of the way, let's scroll down the document.

A

um Are there any se linux experts on the call.

A

Are there any se, linux experts other than uh dan walsh.

C

I could call myself an se linux journeyman. I ran it on kubernetes.

A

A couple of times um do you have any thoughts on what a sensible se linux policy would be to set for the baseline.

A

So peter hunt suggested that um uh there might be um sort of specific values that could be banned or allowed explicitly, but there's kind of a question that I don't think they ever responded to around.

A

Whether those values were specific to red hat linux distributions or.

A

Widely used across all linux distributions.

C

So I am not familiar with the out of the box use of se linux on any distributions that aren't red hat distributions, um and I am of the impression that se, linux labels are completely site, specific modulo. The fact that you inherit a ton of your site, specific labeling from your os installer and so like sbc spc underscore t or container underscore t like literally speaking, are just strings, but they are special on red hat type. Linux distributions because they are, you know, hard-coded into what your file system looks like when you install the appropriate.

B

C

um Are there any linux distros that aren't red hat linux distros that do ship with se, linux turned on and enforcing.

A

I guess independent of whether there's kind of public widely used distros, there's always the possibility that a specific that someone's running their own custom linux flavor and have explicitly enabled se linux.

C

Yeah I mean yeah on any kernel that you've compiled se linux into you, can label all your files and turn it on like that's. You.

E

C

Nothing, stopping you and so at.

E

That point then, at that point, then that's not really what you're aiming to support in this cap. I don't think.

A

Right I, the goal here, is to.

A

um Be able to enforce something on it enforce that kind of baseline level of security on se linux um in a at least relatively universal way, trying not to be opinionated about the specific implementation or layout of it.

A

um That's why I liked the approach of just saying that you can't you can't customize it, but jordan raised the concern that it's common on se linux systems, aka openshift, to have mutating and mission controllers that set custom labels for shared volumes.

C

I mean I'm trying I'm kind of looking at the ab armor answer here and wondering whether there's anything that we can do to to kind of copy from that and, like, I think, part of why it works for app armor is that within app armor unconfined is like app, armor is opinionated and unconfined has a meaning.

A

C

If there was the equivalent.

A

Of unconfined for se linux, then we could just deny that and say anything else goes actually. Another reason that app armor is different is with app armor, there's validation in the cubelet. That says you can only run with a policy. That's been defined and loaded into the kernel, and only the system administrator can define and load policies.

C

Whereas again your your sc linux label is literally speaking, just a string.

B

Yeah and it only.

C

Has meaning relative to all the rest of your se, linux config.

A

C

I don't think we can do anything with this unless we can get some interesting input from some of the openshift people about like. Are there.

C

Are there meaningful de facto standard labels that are worthy of banning in the way that the unconfined app armor profile is banned?

C

And if so, maybe we can ban those, but otherwise it seems that we can't really have an opinion about se linux without breaking people's reasonable se. Linux use cases because there's no way for this policy engine to know whether a particular label is actually restricting you or opening up your permissions.

A

Yeah that makes sense um so yeah, I guess short of figuring out something um it's probably best to just say that uh this field is that the se linux fields are unenforced and if you're running an se linux enabled system, then it's just kind of on you to use a third-party controller to set that up.

C

I I think that makes sense in light of our targeted use cases and the fact that running selinux as a compensating control inside your kubernetes cluster, that isn't open openshift is actually incredibly difficult and like. If you can do that, you can also certainly run an external policy controller. Exactly.

A

um For the sake of completeness, maybe I'll enumerate three possible options here, um one being that you um basically saying the policy enforces that you can't set this so it's you're just forced to use the container defaults.

A

But that kind of breaks the shared volume use case, the other one is to say that we, this policy has no opinion over the selinux fields and that you're on your own, then there's kind of a third option which goes against what we're trying to do here, but basically to introduce some sort of configuration knob for se linux. It says here's the allow listed set of labels that you can use.

A

Either statically defined or somewhere else.

A

I don't really like any of those options.

A

um Okay, moving on, um let's see I'm just skipping ahead to the unresolved sections, but if anyone wants to talk about anything, I'm skipping over, like the testing plan, um just speak up.

A

um Okay monitoring! uh This was just like a few ideas that I threw out there. um I think it would be good to have some some monitoring on the policy to make sure that things are working as expected.

A

So some ideas I had were per profile mode, denials just a counter, so how many times has it denied? um Has it actually rejected a pod? How many times has the warning been triggered and how many times has the audit mode been triggered, maybe per profile version, so you could say.

A

Denied restricted pod this many times.

C

A

C

Those metrics, what about those metrics on a per namespace basis, see like.

E

C

In this namespace.

A

Yeah, that would certainly be useful. um We're constrained uh by our metrics implementation, prometheus in the cardinality of metrics, and so anything that's user. Definable is sort of a no-go for metrics.

C

um That's unfortunate yeah blow up the metrics cardinality by making n 000 name spaces.

A

Yeah exactly um it's captured in the audit logs, um so you can always implement your own metrics. On top of your audit.

C

Pipeline uh you look like you've got something.

D

I was just gonna ask so these counters they're gonna be they're gonna scope to the actual pod. What, if you have you know you have a replica set, it's trying to create the pods trying to create the pod it keeps getting denied. Is that just gonna run up these counters.

A

um Yeah and that's that was sort of the idea that I had in mind um was like you know, you changed something and suddenly your um your rate of denials goes through the roof and triggers some alert based on that, and so someone can go investigate that.

D

um Maybe it sounds like a single. Basically, a single bad deployment could cause that to happen. Is that how do you tune your thresholds or whatever would be interesting to alert on based on that, and since we don't have labels saying which pod this was or which anything? This was it's kind of hard to really tease that apart afterwards,.

C

It tells you to go: read your api server logs, but like any time that number of denials spikes it's either a security incident or an operational incident, because somebody tried to do something and they were prevented from being able to do it, and so I mean like how you would tune them in terms of do you want to get somebody up at night. Questions like that.

C

I feel like are site specific, but like any time you have an unusually large number of rejections, something bad is going on and just from the count you don't have any idea. What that bad thing is, but, like somebody is unhappy, and if it's your enemy, that's unhappy, that's great, and if it's your friend that's unhappy, you need to help them.

A

Yeah, I think that's true mostly around how metrics are used and that it kind of gives you some very high level overview of the system and can be used for alerting or drawing attention to an issue. um But when it comes to actually debugging that issue, it's expected that you go to the logs and just.

E

Investigate, but I would imagine imagining the installation that cares about security like this they're, probably centralizing those audit logs and doing some amount of processing on those, so I'd get that data from there. Personally, if it was me.

A

E

C

I keep trying to increase the cardinality of the metrics, so if we did want to do metrics and like increase the cardinality of the metrics, what about for like rejection, metrics breaking them out, according to which pod feature caused that met, caused that rejection to happen?

C

I don't know if the the implementation of that would be too complicated to be worth it, but like throwing out thoughts here.

A

um I don't think that would be too hard to implement. That's an interesting idea.

A

uh I'll I'll add it into the kep um uh or if you could take a note on that.

B

A

Yeah, I would want some input from. um I think we have like a metrics review team explicitly that needs to review all metrics changes, so I can get their input on that another one that occurred to me is if we wanted to separate out, create and update requests.

A

I'm not sure anyone cares about that, but um could potentially be interesting.

D

For example, oh.

C

Sorry go ahead; okay because, for example, your replica set controller doesn't update pods.

A

Yeah yeah, if you have update, rejections, that's probably someone trying to do some ignition.

D

Do we need anything about counting exemptions and seeing how those are being utilized.

A

That's a good idea.

A

Yeah, we should definitely add uh exemption counters.

C

But per the user configurability thing they can't be per user they're just number of times exemptions were utilized.

C

Would we want to log something about that like when a pod is allowed because of an exemption that otherwise would have been denied? Do we want to have some kind of special star put on that log entry.

A

Yeah, it should definitely go in the audit logs. um I'm not sure if I called that out explicitly here.

A

Now I'll add swing on that, but yeah it should add an audit annotation if it was exempted.

A

On the cardinality of exemptions, we could separate out user, namespace and runtime class based exemptions. That might be useful.

C

Yeah that actually sounds really useful, because I kind of don't care that there's a bunch of of admissions happening in namespaces that I've exempted like that's, why I've exempted them, but but when I'm granting user exemptions, that may be more interesting. Unless I'm granting that user exemption to a controller that create you know is basically a fork of the replica set controller. But if, if I'm that fancy- I'm probably not using this.

A

I've lost my window, however, I guess: um okay, any other suggestions on metrics.

A

Is it useful to split out.

A

Let's see, okay, I don't think we can include profile version um for cardinality reasons.

A

We probably want to separate out profile modes.

A

Do we care about separating? Do we care about warning and audit metrics as well, or do we only care about enforcing mode.

E

From the troubleshooting and like the ciu's case we talked about, the warning would be handy. Sorry, which use case was that so the um the use case of doing testing policies on uh well again, okay, nevermind you're, not gonna, be testing these policies um never mind. I think something else.

A

um Yeah, this is just for the like kind of global counter for, like you know, does anyone care about getting paged when suddenly, the number of warnings goes through the roof.

C

I would say if it's easy and cheap yes, because, like off the cuff, I don't think I would want to wake somebody up if the number of warnings goes through the roof. But if I am, if I have a cluster and I'm trying to ratchet down the permissions in it, then I could apply a more restricted policy as a warning config on some namespaces and without the metric, I would go to the cardinality of audit log events that show that warning yeah.

A

C

Metric there, it could save me from having to configure that in my you know in my logging pipeline or in the case that I have metrics aggregation but not log aggregation, I would at least then be able to line up the timing like I made the change at this time, and then it went up a lot, so it seems like it could potentially be handy.

A

Okay, um yeah I'll add that as a nice to have um and consult with some sig instrumentation folks.

D

For the you mentioned, you labeling by policy version was was dangerous for cardinality reasons. Is that true? Even if we validate that it's a valid version.

A

A

We could maybe validate that it was a valid version less than or equal to the current version um and just kind of lump everything else into like a future kind of generic future version.

A

So then, you would have latest v 1.0 through v 1.21 and.

A

C

um That could be interesting if you didn't think that you were using any pinned versions and then suddenly you saw some metrics on the previous pinned versions. It could uh could be a sign that something weird was happening.

A

Yeah, um I do worry a little about the cardinality of, like um I, I guess, hopefully, no one's running actually 21 different versions uh in their cluster, um but at the upper end you have 21 times three times three for the three profile levels and the three uh enforcing the warning and audit modes.

C

That's why I kind of like the past present and future bucketing, because in that hypothetical use case, you still get that, but also you know it's never going to be more than three yeah. This might be a go to the logs.

D

Kind of a thing.

A

D

A

um Okay, yeah I'll see if I can uh get some more input from instrumentation folks on.

A

That, um let's see most of the production readiness I ignored, um since it's more for going to beta or ga um we've already talked a bit about version, skew monitoring requirements, dependencies should be pretty minimal.

A

I don't think there will be any scalability implications.

A

Troubleshooting uh we've talked about um audit annotations.

A

Optional feature extensions, maybe it's worth going through this quickly. I know that we're getting close to time here. um uh Just um I don't want to talk through the details of these, but if anyone feels like this should be a part of the main cap and not a part of optional future extensions, let me know so. The first one is a way to roll out baseline by default.

A

We already have a lot of tools in place to let someone do this on their own cluster.

A

The question is: if we wanted to ever change the upstream default for this, since this would first require the admission plugin to go to ga, I think we can keep it in future. Extensions.

C

I personally like the idea of leaving that up to.

C

A

Okay, I'll leave it here for now um pod security policy, migration- we've talked about a bit. um I would love to see this. um I think it makes sense to leave in future extensions for now. um Basically, that just means that we are not going to plan on working on it for alpha.

A

This could potentially be a totally separate work stream. It can be out of tree um if someone.

C

Wants kubernetes.

A

Yeah exactly if someone wants to start working on this um by all means go for it, but I don't think it needs to be a part of the core cap for now.

A

um We may want to think about doing something around the time that uh you know around like 124 or something like that. But I'll leave this here for now.

A

um Custom profiles: um this would just be an extension mechanism. If I wanted to be able to say you know, you're allowed to set deny or allow equals host network and have a custom um third-party controller that enforces the host network policy.

A

So in practice this would just be like the entry one would ignore these levels and treat them like privileged um and just expect that you've configured a third party controller to do it.

D

How's that different than just setting them to privileged it's more explicit or.

A

It's more explicit um so that when you're looking at your name spaces, you can separate out this one's actually privileged versus this one. My custom implementation isn't forcing on it.

C

This seems like a really good future one, because it makes much more sense if these labels take off and are adopted by other third-party controllers.

A

A

Custom warning messages.

A

The use case here is: if, on your warning policy, um you want to say, like you know, say um say you have your enforcing policy pinned to uh 120 and you want to update that now to 122..

A

So you set warren to.

A

The 122 version to let users know if they're, using a feature that is going to be denied in the future. You might want to set a warning message that says something like you know: here's the date that you have um when this will stop working or here's an email address to contact. If you need an exemption from this policy or whatever.

D

So it's message of the day.

D

A

Yeah, it would basically be only if a warning is triggered. Is this message shown.

A

um I'll keep it in future extensions for now.

D

It's interesting: it's like a path of communication between the security admin and the users. Are there any other analogs to something like that in kubernetes,.

A

Not that I know of, but also the warning mechanism is fairly new.

C

I know there's a gatekeeper feature that you can, that you can inject warnings.

C

I don't know who uses it, but.

B

But that's just the kubernetes warnings. It's not a custom morning message.

C

Oh, I thought you could put whatever darn text you wanted, like. I thought by writing the right rego you could put whatever darn text you wanted into the kubernetes warning.

B

Right, that's part of the rego.

C

Yeah yeah, yeah cool, and so with this, since we don't have rego, you know we can't totally set it, but but we could add a little bit to it and they just feel like similar use cases.

D

Who can is this on the is this on the name space this uh this future annotation.

A

Yeah, that's where I was picturing it um actually, since we're almost at time. um I just quickly want to touch on windows support, um so we've talked about how, like even without explicit windows, support.

A

We have the escape hatches in play or the extension points in place to say the windows runtime class is exempt and have a third party controller that does enforcement on windows runtime class pods.

A

If we wanted to do any built-in support, we would need to standardize the identifier for windows pods, I'm not sure if that exists today. um I don't know if you know rita.

B

No, I think, they're different right. um I think that's why there was a proposal around like uh like another spec for windows, pods.

A

um Yeah, so I guess we need a standardized identifier for windows pods, whether that's a kind of standardized, runtime class, name or separate pod spec, um and then the second piece is to actually write what those pod security standards for windows should be.

A

We should probably have that regardless, so you know rita. If you want to take that back to the sig windows community um as something.

B

Yeah I'll follow up.

A

A help wanted item for getting those.

A

Documented all right, um that's all we have time for today. um I think we are getting close on this proposal. um I probably have at least one more of these meetings, um thanks for everyone who is able to join today and uh have good afternoon.

A

Thank you. Bye, bye, all have a good one.