Kubernetes SIG Auth, 19 Jan 2022

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

SIG-Auth Bi-Weekly Meeting for 20220119

A

All right, everyone uh welcome to january 19, 2022 meeting of sigoth. uh Let's kick it off. We have few items on our agenda.

A

Can you guys hear me okay, yep awesome, um so today we have one announcement which is 124 enhancements. Freeze is 18 pacific time, thursday february 3rd and then prr is saw freeze on thursday january 27th. So if you have a cap that you're working on, please make sure you're making progress on that and paying the folks, you need to get approval and review.

A

uh I don't see anything else, so we're going to go straight ahead to discussion topics. So, first off the there is a cap for kms observability.

A

Sorry, jordan, did you want to add something for announcement.

B

No, I was, it was something about the enhancement series making sure people uh got not only kept merged, but also things in the tracking spreadsheet.

A

Cool thank you for adding to that uh speaking of keps. So first one on our agenda is the kms observability cap, a niche open that kept. Do you want to walk folks through that and if you have any questions, please share that here. Initially, okay, go for it.

C

So a few offers have been meeting every week on things that we can enhance for the kms plugin. uh So some of the areas that we have tried to look at is uh observability uh recoverability and then performance. So we've categorized that and then we have like a living dock where we are working on it. um So the first thing that we wanted to focus on was observability and uh we wanted to keep the changes short without any breaking changes.

C

So the first thing that we're trying to do is actually add uid for requests that go from the cube api server to the kms plugin, because today, uh if you have to do any kind of correlation, the only way that we can correlate errors or requests coming in is by looking at logs in kms plugin and then correlating the api server logs based on the timestamp.

C

um So what we are trying to propose as part of this cap enhancement, is to add a uid field in the proto api, so that for every encrypt decrypt request that we make to kms plugin. We generate a unique id and then add that as part of the api request, um and then we are also planning to implement a wrapper in the api server so that any logs that is generated for these kms envelope.

C

Encryption calls have the uid and then also maybe have additional metadata around the name namespace and then the group version resource so that if I as a cluster admin want to look at logs, then I can look at the kms logs and then correlate that with my api server logs and then this uid can also be passed from the kms plugin to the external kms store, so that that can be used for auditing purposes. um So there were a couple of options that we considered.

C

One was basically using the audit ids that we can string along from user um user, originating request all the way to the kms, but uh I think we talked about it during the last call. Not all the requests that are made to kms plug-in originate from the user. uh Some of it is during the api server cache warm-up.

C

So there is no way to correlate the user request there. um So for now, we've decided to just generate a uid in the api server, for every request that it's making the kms plugin and then start the correlation between api server and kms plugin, and then in the future. We are exploring an option where we can use the audit id annotation and extend this so that we can use this uid without identification.

C

So we have a gap for it and then vita and mo have been helping review it and we would love to get more reviews on it and work on it. In this release.

A

Any comments concerns.

D

I think the main thing I have the way to this is, you know I think, what's described in there is totally fine, it's a very small change and it's, I think it's a straightforward change.

D

uh uh I I struggled to map the kubernetes like api guidelines and stuff with this grpc thing that we have on side uh you're right like as a for example.

D

Just the this api is a beta api, but then, like the encryption, configuration is like ga v1 api right, like that's already kind of weird, because you configure the thing that you configure is done apparently, and this thing over here, that is being configured is not done um so that that's weird but also like in in this particular case, um and I commented on there, which is that this change that we're proposing to make it's unclear to me how it flows through any graduation criteria or any feature gate like as described to me.

D

This thing just starts off as ga as in we're, adding a uid hope you're fine with that, like I don't really know what else we do in this case I mean uh you know I think back to the csr duration cap, and you know, because of.

D

Just basically concerns around storage of the new field and the fact that you can have external implementations. You know we had a cap that went through at least beta, and you know hopefully 124 ga.

D

And you know how to feature gate. Do we want the same semantics here? I don't know I I don't honestly have a strong opinion on if we do or not. I just want to be consistent with what we think the project should do. um So. That's really my open question. I think the actual work is straightforward.

B

Yeah, the um there are a few reasons we have like feature great progressions. One is if there's potential issues that might come up the feature gate gives us a simple way to sort of cut off the problem, and so um the service area of this proposal is pretty small, but it is like adding data to audit stuff and it is adding data to outgoing requests.

B

I could imagine a backend that didn't like new fields showing up in the grpc request like that, would be weird given how grpc and proto works, but it could happen right. So that's the sort of thing that a feature gate would let someone who didn't care about the audit id functionality like turn off um and then come to us and say hey.

B

I see there's this new field coming in like this is weird and it broke me for some reason, scale reasons or unexpected data reasons or whatever like I. I don't think the risk of those particular things is high, but that's the kind of thing that a gate lets someone turn off.

B

I agree that the grpc stuff doesn't always map well to the api conventions. Those are very clearly written around like rest apis and then secondarily, the config file apis, which sort of reuse the same machinery.

B

um So if you're trying to follow those to the letter and are having trouble, I'm not surprised uh feel free to point that out and like jump into the api review, channel or open issues or pull requests to that doc. To like add grpc, specific exemptions or notes. That's fine.

D

At a high level do folks have a particular approach. Like I mean, certainly the safe approach is to add some feature, gate and use that gate to. I guess enable if the uid is going to get passed through. um I I don't actually fully know exactly how the proto looks on the wire. I presume the field is not set the you know the binary data that is actually on the wire does not change at all.

D

It depends how.

B

You how you do it if it's a pointer field, then it can be emitted completely and nothing changes on the wire. If it's a non-pointer, then it will or it can get serialized as a zero value and but unknown duties should be ignored by the thing on the back end um yeah.

B

This probably don't need to go into that level of detail here, uh like I said the two things that this is proposing, don't seem like high-risk things, so I I don't feel strongly either way, but just remember that our ability to react quickly if we release something and there's a problem for someone.

B

It's like a one month response time and maybe is breaking if we try to roll back something that we previously released default, enabled so at least having an option. The first time we release something. If we're not 100 sure that'll be good, for everybody is helpful.

B

B

I saw you tagged clayton as the reviewer on that, since he was one of just a couple original code reviewers on the storage transformation stuff. I would suggest reaching out to him uh in slack or something to make sure he's aware of it. He might have gotten lost.

D

Yeah thanks. Thank you. There yeah he's.

B

D

He's the last person standing on the christian arrest, approvers list.

B

Yeah separately, it would probably be worth um talking with him about like it's good, that the kms discussions are happening and people are interested in improving that um it would probably be worth talking with him about getting some more redundancy there. In.

B

Or oversight of that package.

D

Yeah, I I can do that um uh other than the graduation things do folks have any thoughts around just kept.

E

I I haven't been following closely, but um maybe this has already been answered, but how is the ui uid being generated? Is that uh I mean what kind of random number generator are you using underneath it.

D

uh So we we would just use the existing uh uuid package that we use. So within the cap we reference uh or the niche references. I shouldn't use the initial of this kept. I was just present.

D

uh We use the uuid package or we will use the uuid package, for example, that is used to generate uids on admission reviews.

D

They survey vaguely similar, but not exactly the same purpose as what we're trying to do here um and that, if I remember correctly uses the goes, a crypto random number generator under the hood, which, if anyone cares that you know that does get swapped out if you have like the fips compiling stuff. So if that, if that's the concern or if there's other concerns about the rent, yeah.

E

I always you know. I was just curious because this uuid is acting as a nonce, so I just wanted to know how guaranteed it was not to repeat- and things like that.

D

Yeah, um yes, that's the function right there. That is on screen right now. um So certainly, if there's any concerns with it, uh we could use something else. If there was a need yeah.

E

Okay, I know the uh linux finally gets upgraded at guaranty, I think about a month ago, but anyway, yeah okay,.

A

Any other comment for this cap.

D

I I was going to admit so this level of detail isn't in the cap, because it's really just about implementation. um I had proposed this to a niche as a as a as a way we could implement this.

D

Basically, what the thing I wanted to guarantee was that over time it was very unlikely that we would forget to log the uid in any scenario that is important to us, so my suggestion had been just basically that we would just make a a wrapper implementation of the transformer interface whose entire purpose is to just log, the uid and otherwise, to do basically nothing else.

D

And then you know you can have tests and stuff around that, um but my thought there was that over time, as we add new transformers or otherwise tweak things or because I I know a while back I've seen someone have a kept for uh like a gzip transformer or something which seemed like a perfectly valid thing to maybe want to do for your lcd data, um just kind of making sure that it sort of exists.

D

um Anyone have any concerns with that low-level implementation for our other alternatives.

B

I'm not sure most people on the call are familiar enough with the storage transformation stuff.

D

I know it's it's like as not as far as you can get into the weeds of the api machine. I don't know, maybe maybe fine.

F

um I'd be interested in knowing what kind of code wrapper you needed around the wrapper that was already there, um but, like you know in concept, do I object to zipping? No, not really.

F

If I, if I had zipping, would I try to use it as a way to finally store crd v1 yeah, I probably would um but beyond beyond griefing jordan, uh I don't. I don't have plans.

D

Yeah, I I just uh you know at a high level right like this is just about making sure that, when things go bad, that there's enough information in the logs- and I just wanted to make sure like logs- are hard to assert over time as being useful yeah. Well, I just kind of try to have it built in a way. That's unlikely to drift.

D

A

Okay, anything else.

A

All right, if nothing else, we'll move on to inline csi and female volume, cap.

A

Who opened this up? Go ahead.

G

uh It was me uh hello, I'm jan from six storage, and this has been discussed couple of times in the previous meetings.

G

We would like to move inline, csi ephemeral volumes to ga in this release and from the previous discussions last year I understood that.

G

The fmr volumes should be used. The csi inline volume should be just used for ephemeral volumes which are safe to use and should not be used for persistent volumes.

G

So we are updating the cap correspondingly, because previously it was using security policy, and now it has a security consideration chapter somewhere uh that basically copies the stuff that is in both security. uh What security standards about inline csi volumes that they should be used for fmr volumes.

G

And risk inline csi drive drivers should use third third-party admissions and so on. So uh we definitely plan to document that we will document our. We will update our documentation for csi driver vendors to use fmr volumes for save data and not expose insecure parameters.

G

We can do that, but I am 100 sure that there will be a csl driver that will break that, because people want people really want to have in-line volumes in ports using csv drivers to access persistent storage. They do it now with nfs volumes. They will want to use it in with csi drivers too. So, whatever we document ss storage, whatever we recommend, I am pretty sure people will break it.

G

Is this something that's okay for you.

B

So I spent some time talking about uh michelle talking about this with michelle, um also from six storage, uh and I I had actually gotten confused about there being two ways to use um sort of ephemeral volumes from within a pod.

B

So we had talked about ephemeral volumes um and there actually is an ephemeral field inside a pod which drives the same workflow as creating a pvc and then getting a pv bound to it. Yes, and so.

B

I think that is what you were just referring to using ephemeral volumes for persistent storage and basically, the only difference between that and the inline volume is one drives. The pvc pv flow and the other just invokes the csi driver directly.

G

Yes, sort of the one we call generic fmr volumes that creates pvs pvcs. uh It gets you empty here, basically yeah, it gets you empty there like you, get something empty or it could be populated via snapshot or whatever, but the use case is like empty there. On steroids,.

B

Right, it's in a femoral.

B

Volume uh which could be pulled from a snapshot right yeah, so so for persistent storage, we're saying you should use pvcs for ephemeral volumes that are built on top of like persistent drivers. You could use this ephemeral, so it'll provision a pvc and then tear it down and.

C

Then, for inline.

B

Stuff that that is focused more at the like secret, providing volume or um credential, injecting.

G

B

And things like that.

G

uh Yeah, like that is the primary use case.

C

G

A problem with that is that people use entry and fs volumes in line inputs. Today they will not have that possibility with the generic fmr volumes with pvs pvcs, because they need to specify the nfs share. They need to use. They want to use the nfs mount basically and that's not possible with generic effect volumes in pvs because they create pvcs and, like you, can't tell what you want. You get something provision for you, based on the storage class.

B

It seems like this is wanting two separate things: it's wanting to give someone inside a namespace access to something which they should have to create a pv to access like they're, wanting control over cluster level storage configuration from within a pod and that that doesn't seem to match anything.

G

B

G

Sort of like the use case is that there is an organization that traditionally uses nfs. Everybody has a home directory with proper ownership. Proper access, bytes and a person in that organization runs some workloads in kubernetes. They run some workloads on their own on their machines on their desktops and all that they want to.

G

They want all that workloads to access their home directory. That has the proper access bytes and they run, of course, the ports with the right user, id and gid.

G

So it's kind of mix of mixed scenario, where you have like traditional workloads and use, run some jobs on kubernetes and those jobs need access to your data and, like you, don't you can't create previous pvcs, because that's.

B

G

B

You're describing seems like it depends on other aspects to also be configured like the you would group id stuff to be configured properly and enforced properly, and so I guess I would expect the thing that is making sure your pod is limited to your uid and group id to also be enforcing like the nfs storage stuff.

B

I guess it seems like wanting to like build in a policy around one aspect of it when really other aspects are required as well would lead people to create inline drivers that um are only partially protected.

G

Okay, but these people they will write a csv driver that and they will have this admission plugin that does the does the policy that enforces uid jd and that also controls which volumes you can mount like. They can write it. They will write it.

G

And that's that that's fine with your port security standards. It says like if the drive the risky line drivers should already use a third-party admission controller, which they will do.

G

They will need anyway, for the gids and your ids.

B

To me, it makes sense to say we should not have an opinion about this. If you're going to write a thing that is not inherently safe, then you need to put protections around it which understand the context that would make it safe. um So in that case, the best one, it's a uh good type of restriction.

G

Yeah; okay, that that makes.

B

G

So we will update our documentation that faces csr driver vendors that uh that's the css drivers that implement the smart volumes.

B

G

B

Ephemeral is maybe it's just me. Ephemeral is very confusing because it yeah it.

H

Also maps to the generic rule, which.

B

Drives the pvc vp yeah and maybe inline is the one.

G

Okay, so dangerous. We will document that if a driver implements the inline volumes, then uh it should be safe, and if they want to do something unsafe, then they should provide a third party permission. Plugin that will enforce. Then it allows users to do some policy. That'd be fine.

H

I have maybe a dumb question or don't quite understand, what's going on? Is there something that prevents csi driver nfs from using, like the service account of the pod, to do the nfs connection.

G

uh No it's up to the csi driver and okay, we can't enforce it. You know permanently.

G

Csi is very open protocol and the driver can do anything if they choose to implement a service account checking they can, but we can't enforce that.

B

Yeah, the parameters that are passed to the driver are arbitrary, like if you're using this inline volume in a pod spec, you can specify any parameter you want, and so what parameters the csi driver consumes determine how safe or unsafe it is. So you could imagine the csi driver consuming parameters that it like passes blindly into like colonel mount calls or something uh okay that could be like super disruptive or destructive or in the case of the nfs one.

B

uh One of the parameters it consumes is uh like information about which nfs volume it wants to mount and so like, depending on other things like you, would get permissions or sd linux control or like how the nfs stuff is configured on the nose depending on other stuff, that might let a pod author access arbitrary nfs data, so it's pretty specific to the driver, whether it's safe or not, and then, if it's unsafe, what other conditions need to exist to make it safe, whether it's other attributes of the pod or attributes on the namespace or configuration?

B

That's opaque. That's on the nodes that the driver is like. Oh, no, no! It's cool like we configure our nfs shares this way. So if you try to access something, you don't have access to you'll, you might get them out, but you'll be forbidden from viewing the files like.

H

B

It's opaque to the driver.

H

I guess I had never thought about kubernetes trying to control that uh it seems like if I want to write some arbitrary, unsafe software that runs with node credentials uh I'll be able to do it, no matter what mechanisms and deploy it on my nodes and I'm the cluster administrator, like it's not clear how much kubernetes can do to keep me from shooting myself well.

B

I think the proposal in the last couple meetings or last couple months was to have sort of a binary. Yes or no. This namespace may access this driver type of policy that could be built into kubernetes, um and I I I've been kind of opposed to that, like I think, there's reasonable alternatives using pvs and pvcs or using the generic primordial volumes, um and if people don't want to do that, they still want to do inline stuff, I suspect, even for the nfs example like.

B

Would it actually be acceptable to just deny use of the nfs driver to all these namespaces? I would guess not. I would guess you would still want to allow it conditional on the uid and group id aspects, and so that goes beyond what a built-in admission thing would do as soon as you start tying in some second piece of information.

F

Yeah, the the question of whether a cluster admin always knows in advance what the software he installs does is. uh uh In my experience, they are not always super aware of all the minutia and having a way to say um that you know this.

F

This use of a csi driver inline is known to be unsafe and basing whether it's allowed on a per namespace basis, based on the privileges of that namespace, combined with the knowledge of the csi driver and gives you a way to handle it in the field in a way that is not is slightly more refined than be perfect.

F

But once we have the list, can we build it yeah we can. We can it's entirely buildable externally uh to be able to handle it. You know in the field on the clusters you have now. I think that is likely to be the direction we go.

B

I I will say just having sort of come into this area sideways via these discussions. um I got super confused by the difference between the ephemeral field, which drives the pvc flow and the csi field, which does inline volume specs. um I know, there's been like updating the documentation. A few times has been mentioned, but uh it would be super useful to have like a if you want to provide this kind of storage.

B

Do this with your driver, if you want to provide this kind of storage, do this with your driver um type of flow chart with the the caveats and warnings like if you want to allow pod authors to do it, provide this kind of driver but watch out for like arbitrary parameters or kernel parameters or like something that doesn't just bury the documentation on the particular page talking about inline volumes, but actually lays out like here's as a csi driver author, you can provide volumes via pvcs and they can be consumed these ways or you can do it in line it can be consumed this way- and here are the considerations like kind of the the overview with the pros and cons of each might be helpful.

G

And maybe that already.

B

Exists but right, I had a hard time finding that.

G

We have something- maybe it's not perfect, it's definitely. It doesn't mention the security. Definitely there is a chat here. Okay, we have something. Maybe it's not perfect,.

G

All right thanks.

C

G

I

G

So uh maybe, as.

C

G

uh Like the recommendation in the both security standards about inline volumes, it still holds, uh kubernetes will not provide any policy, and we will just update documentation in this and provide guidance about the security. Is that correct.

B

That matches my expectation- um and I think we already had issues filed for the drivers that we knew of that were making use of inline functionality with problematic.

G

Exposure, nice guys, somebody driver, I think they dropped the support phone number correctly, but I'm pretty sure that the nfcs and driver they will. They will either want it there or they will fork it because it's used um yeah. We can document it in the driver that about the security consequences. Definitely, but um I don't think we can just remove it easily.

B

Yeah, I I don't think we were contemplating removing it necessarily, um especially in the case of the nfs stuff. It sounds like there are mitigations with the the user, id and group id controls and so figuring out a way to effectively apply. Those could be reasonable.

B

A

So, uh what's the action item here.

B

I think, uh as sixth as part of six storage wanting to ga the inline field, like making sure the the docs are clear and call out these implications, and um I think we've already engaged with the drivers that are known there were a couple drivers that were known that were using this.

B

So I think it's primarily a documentation.

D

A

Are any other comments for this cup.

A

Okay uh pot security plans for v1 uh for v124, ga or not g.a,.

B

Yeah, so I uh tim put this on here, I'm not sure, are you on tim.

I

Yeah hi cool I've talked a lot. You want to talk some.

B

um Yeah sure so, um pod security admission is currently in beta as of 123..

B

um At one point, we had discussed that going to ga by 124.

B

Would be and would be ideal from a pod security policy deprecation standpoint.

B

So, as the timeline below says, psp is slated for removal in 125..

B

That means that customers or your users will need to migrate their clusters off of psp in 124 or by 124, um so so, in other words before they upgraded to 125.

B

um So it would be really nice if uh pod security was ga, so they could migrate from pod security policy uh to a ga feature. um A couple other considerations there yeah so as david mentions psp is beta. So it's not the end of the world. If we're telling them, you have to migrate from one beta thing to another.

B

um If pod security instead went to ga in 125, then probably a lot of users are not going to actually do this migration until 125 is out just kind of realistically based on people's upgrade timelines, and so, if it went to ga 125, they at least have some assurance that the thing that they're migrating to is not going to change or go away in the future.

B

And uh yeah, so that's consideration and then the other consideration is just um you know. Psp went to beta in 123., 123 hasn't been out for that long.

B

I don't think that we have a whole lot of feedback either positive or negative. I think we just don't have a lot of users of pod security, yet.

B

So yeah, I think that's the that's. The current situation is anything you want to add jordan, um I linked to the tracking project just calling out some of the outstanding items. There aren't a lot. uh There was one sort of cleanup usability one where, if you submit pause to a restricted, namespace you'll sometimes get a forbidden error from the baseline policy and the restricted policy that basically say similar things, which is ugly, so it'd, be nice to clean that up. uh David brought up an issue where it would be.

B

Our ede tests should configure the namespaces they create, so that a cluster that is enforcing restricted policy by default will still pass ede tests uh that got started at the very end of last release and didn't quite make it. So um I think that is a good requirement for ga.

B

um I would want to see all of our ede tests explicitly set the pod security level. They need to pass and ideally scope themselves to baseline or restrict it where possible.

B

The only other thing that was in progress was related to the pod operating system field, which is working its way through feature life cycle um cubelets. So the field got added as alpha in 123.

B

cubelets enforce the field matching if it's present in 123. and so.

B

At the point where the field goes, ga we can update pod security to only pay attention to os specific fields, which is nice it'll, make the restricted policy cleaner. uh If you're, creating windows pods, and you don't- and you think it's silly to have to specify like restricted capabilities and linux, specific things in your pod spec just to pass the restricted policy you can say this is a windows. Pod and pod security could relax and be like oh cool, then I'll only require you to opt into restricted windows related things. So.

H

It'll, be nice.

B

I don't think it's a blocker for ga, that's more tied to the life cycle of the pod os field.

F

The lack of feedback on the beta level for something that is going to impact every pod and every namespace.

F

It really seems like you'd, want to get feedback about how it's working and.

F

And I haven't seen any of that yet.

B

Yeah all the feedback I've seen have been from people who were writing blog posts about the feature which was not nothing, but it also wasn't like wide user signal. um 123 like realistically, I think, is just now like rolling out to sort of production, managed production environments um so requiring the migration from psp to pod security in 124 to be from one beta thing to another. Beta thing is not the end of the world.

F

Yeah, like I I know we are still working through how we handle migration plan, uh how we get clusters that did not previously enforce to enforce um what that looks like in terms of auditing and user opt-in and um how it plays, with other admission plugins that we currently have that's all still being worked through, and um you know not that we're necessarily like you must wait for us.

F

But you know openshift is fairly knowledgeable about like how this stuff worked have years of experience and forcing security on pods um and, like we haven't gotten our feedback back, I haven't seen other people's feedback come back yet either uh and so planning for a ga. Without that feedback worries me yeah other than a desire to encourage people to migrate from a beta thing to a ga thing.

F

Is there a strong benefit to gaining in 124 versus 125.

D

Could I ask a maybe dumb questions um so I know psp is slated for removal in 125 right. um um Could we, instead of removing it, disable it by default or something and just give you a like if the concern like the concern I'm hearing from david is we don't have enough feedback and our runway is relatively short so, like we now need to make a decision, and I guess I'm asking: can we make our runway a little bit longer.

F

I would prefer not to change our policy on the removal of beta apis.

F

If we have a beta replacement, I would prefer to suggest people move to the beta replacement that we have every intention of taking ga yeah and.

D

Good that also sounds totally fine. I, I guess.

D

The the thing I'm trying to ask is: can we can we decouple in some way the the the psp runway with the psa runway? I guess- and I think you know david is suggesting- would do that which is basically it's okay, that you have to migrate from a beta thing to another beta thing, I I I worry that we ga something as important as uh pot security too soon and then realize we've done something bad too late.

D

I mean yes, we can. We can fix anything, but you know: we've had recent conversations on like the cigars threads about v1 stuff is forever like. Really it's really forever, and you know you can kind of tweak it. If you have to you, don't get to take it out and I think that's a great good policy.

B

Yeah I for pod security beta. I don't know that. There's a huge downside to planning to ga and 125 basically give an extra cycle for 123 use and, I guess maybe early 124 use.

B

I will say that um the current discussions in cigarch are around like, should we really be enabling beta things by default in production and right now it's focused just on rest apis, like new rest, api endpoints. um It would not surprise me if the same question was asked about other beta things in the future like, should we really be opting all users into beta things in production by default, um and so in the like?

B

It's probably not relevant for this discussion, but I think it's worth asking the question like.

B

If we think it's good enough to turn on by default, uh I would expect a pretty crisp list of things that would keep us from going to ga uh and if we like, is it just user reports that we're waiting on and, if so in the future? If we are not enabling beta things by default, how how are we gonna get that?

B

I don't know that is particularly relevant for this, since it is on by default, 123 and 124, but.

F

So I think that it is possible to get feedback without having something on by default. uh If we look at at cluster that people who respond to a prr survey, for instance, um 30 of people turn on an alpha feature in production, so so they third percent of plus yeah 300 people turn on alpha features in production so like they can find it if they want to. We have not been idle uh so turning it on. We found the ede issue, because we were you know, trying it early, pushing things through seeing what broke.

F

um So I think if this had not been enabled by default, I believe that our feedback would still be coming about now and and that feedback at least the the hardest parts for us are around the migration of turning on forcing um by default, and I it could be that it is worse for openshift than for anybody else right.

F

It could also be that it's it's hard to turn on and maybe if we get feedback from two three people uh who've tried to turn this on across a wide number of clusters, they'll be able to say like if it was just this little piece that was different. I'd be able to do this more easily. um I don't know whether it won't, but.

B

One one thing to clarify there, like one of the things we worked really hard on on this feature, was that it is easy to turn on, and then you can selectively enforce, like enforcing, is a different step than.

F

Is the feature on sure? Okay, the difficult part is enforcing where you get the maximum benefit by enforcing in as many name spaces as you can.

B

So I guess I'm it seems like. There are two aspects there. One is um someone just coming to the feature cold like they. They aren't doing any enforcement in their clusters today and they want to start using this, like we haven't gotten a lot of that feedback. uh We I mean we've done benchmarks and our test coverage is actually excellent, but we haven't gotten user feedback, especially.

I

With interacting.

B

With other policy mechanisms, so that's that's something it would be helpful to have more. Second one, your feedback, I think, like the migration aspect, is specifically related to like transitioning from psp to that and whether we ga pod security in 124 or 125 or later, if psp, is gone at 125.

B

The graduation time frame of pod security is sort of irrelevant.

F

The current issue is actually facing um having dual enforcement mechanisms. You have previous enforcement mechanism, a you have new enforcement mechanism b. uh It is not pod security, it's something different and- um and how do you have both of these turned on at the same time and make sure that they have some sort of coherent?

F

um We can create pods and have some reasonable predictability about whether they're going to work or not.

I

B

B

Okay, would it, I think, if the main thing we're waiting on is signal from users, especially users, trying to manage migrations.

B

We should actively seek that out during this cycle so that if there are changes that would be helpful or need to be made, we could work on those while in beta and try to deliver things in 124, otherwise we'll be in the position where changes would have to happen in 125, and I don't think we'd be ready at that point. Then.

F

It is standard's top priority for the next two months.

I

F

D

Okay, anyway, please stop abusing standard under such a nice person.

D

A

I do wonder if it's the migration aspect, that is making it harder.

A

By people who are using old, psps.

F

I I can't speak to all cluster cases, I'm not trying to um the the migration, the very first stage of if you start a new cluster, how you turn this on was fairly straightforward, um even the stage of if you have a cluster, it's already running workloads. How can I enforce what I currently have fairly straightforward?

F

um The the difficulties come in with you have a different enforcement mechanism today, and you want to support both enforcement mechanisms tomorrow. How do you reconcile the two and pod security policy? Is one one example. uh I believe there are other secondary enforcement mechanisms out there. So.

B

A

B

A

B

Go ahead for 124, I uh like the ed tests and user feedback on migration and policy. Coexistence are the two things that I'm hearing um the most concrete uh that we need to work on and resolve. Is there anything else if I know we're out of time, if people have other specific things, they would like to see. um Please note them here or reach out to mri or jump on the list. um We want to make sure we're in we're using the timer 124 to resolve stuff. Well,.

A

How I guess, how does the ga timeline for uh security impact the psp removal, I think we kind of jumped around it, but.

B

um Because psp is beta, uh I think pods migrating from psp beta to pod security beta is reasonable. I don't think that anyone should be waiting for pod security to reach ga before moving from psp to it.

A

Okay, so so this is the independent of uh pod security, ga right.

B

My opinion is that it is.

F

I think that it is as well.

A

A

Well, I just want to record that.

A

Okay, anything else on this we're definitely out of times all right. Thank you. Everyone, thanks for the chat, goodbye.

D