Kubernetes SIG Auth, 26 Apr 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Sig-Auth Bi-Weekly Meeting for 20230426

Description

Sig-Auth Bi-Weekly Meeting for 20230426

A

Hello, everyone welcome to the April, 26 2023 meeting of say: goth. Let's kick it off. We have quite a bit on the agenda, uh maybe just to kick it off. um First announcement is, if you missed the kubecon, say goth Deep dive, here's the uh schedule, along with the slides and the recording, should be up in I. Think next week uh and Jordan. You want to talk about the other topics.

B

Yeah, um so uh for those who were at kubecon, it was great to see everybody. uh We had several good discussions, kind of working out some long-standing questions about designs and things. um We tried to take good notes for the people who weren't at kubecon um I've missed plenty of coupons and wished that I knew what people talked about. So we tried to at least take notes and leave breadcrumbs and um for our our own memory and for the benefit of people who kind of wondered. What topics did we talk about?

B

um A lot of those uh conversations are going to.

B

Thanks David, um a lot of those conversations are going to trickle into updates in the the cap, designs, uh pull requests and things in the next few days, hopefully this week uh next week. um So uh look for that, but I did want to point people to the uh some of the notes.

B

We took um that segues into the next couple of bullet points, um so we're starting to spin up work for 128 and kind of got a clearer picture of which things are ready to proceed with implementation, which things seem achievable to get a design pinned down and and actually uh get an initial implementation of 128 and then a couple things that are probably going to stick in the design phase for 128.. So those are links to queries into the enhancements. Repo. Take a look at those we I.

B

We tried to actually assign things to the people who said they would be working on stuff who we think will be working on stuff. So look at, what's assigned to you, make sure it matches what you're planning to work on and I didn't have a lot else to say. It was mostly just kind of uh an announcement to go.

B

Look at those things make sure it matches your expectations if it doesn't like jump in slack or something that we'll figure out who to add who to remove or what to pull in or what to push helps. But I wanted to make sure everyone was on the same page and then the last item was just linking to a couple of things that Sig API Machinery is really driving, but are of interest to save off. So some of the continuing improvements to admission uh stuff that is probably interesting to people here.

A

Okay, a quick question: I: don't think that I think this is new right, I, don't think we talked about it.

B

um Micah and Mo and I spent some time talking about it and kind of had some ideas uh which uh uh I think you've got included in the notes on April 19th, so uh Micah and Mo and Igor were gonna.

B

um Try to take some of that feedback and update the design so I, don't think we're ready to wrap this up and have it be implementable yet, but they had some next steps to kind of continue pushing on the design. Gotcha.

A

Okay, cool thanks all right; uh I! Guess with that: um let's talk about username spaces support.

C

um So hi uh I'm Rodrigo, uh so we added in sync node. We had the support for username spaces as an alpha feature, uh but we wanted to check with with you folks here how how it should interact with pod security policies during kipcon. I chat a little bit with more about it, uh but uh it's invest anyway to come here to the meeting and make this topic available for everyone.

C

Basically, what what we are doing now is like we are adding a new namespace that is the username space, so Corner Spot. Until now, here's the the host username space and yeah the restricted policy. This allows hostnet spaces, so we're trying to think how we should yeah interact with both security standards like what we talked with more was basically at some release. Probably when the feature is still Alpha, we should add it. uh We should disallow the host username space in the restricted policy for I, don't know kubernetes whatever version and then go from there.

D

So so think, other other things to add there is. uh We would also want some uh some Fields, like capabilities uh to be expanded. So when we are in a username space, it's actually safer to give more capabilities to the pod. You can be running as root because you are not really root on the host and so on. So it's like when we are in a username space, some of the other fields get relaxed and that's what we want to be able to express.

B

So, just to for my own memory, like a default pod like if I just create a pod and I, don't specify anything by default, it uses the host namespace. Is that correct, yeah.

D

B

Users, okay, um so the Baseline level would continue to allow a default pod.

B

So the uh the guidance for the Baseline level is that we don't allow sort of escalating things or putting things into a pod spec that escalate permissions Beyond just the defaults, so you can't say privilege, true, you can't say like add a host Mount volume. You can't say, host networking true, um but because host username space has been the default that will continue to be allowed in the Baseline level.

D

I think that that's that's fair, so what if someone enables a username space now can we can we say that they can be rude? They can add more capabilities, because these fields are actually tied to the username space.

B

E

That sounds like it would be safe if the cumulus supported it as well.

C

Supported what.

E

So so the QPS Server doesn't have knowledge of whether the cubelet will honor the values set in the pod right. So.

C

E

You introduced this feature in 127 Cube lesson: 127 know about it, but the cube API server could not relax its validation until one at 1 30. At this point right uh because of the N minus the break.

C

Well, it's actually more tricky because to use a username space, we don't only need changes in kubernetes. We also need supporting container runtimes, the Linux kernel and the file systems uh used by the bot, so even in 130, you're gonna know for sure that will be on earth.

D

We can assume that okay, the node level stuff is taken care of, and then we just worry about the cubelet and the API interaction here.

C

E

C

Yeah, it makes sense like.

E

It would make a pod that wanted to turn on those capabilities like as I, understand the way username spaces work. We would be able to let a pod that was using username spaces run as root, and the point is that that would be allowable in a restricted policy, because you would not be able to to escape from your container and and impact things on other containers. Yeah.

B

So there's there's two directions: one is relaxing restrictions on things like run as user for pods that say username space true um and like David said we would. We would only want to do that once we were sure that the username space, true thing expressed in the API, was actually effective. All the way down to the node in the runtime so like the prereqs for that are the field hits GA. So we're sure that um we're sure that it, like the feature, is locked on.

B

You can't have a component that is saying actually I don't pay attention to that feature, and the oldest node that we would support in SKU with the control plane um is either going to honor the username so slag or reject the Pod. If it turned off the feature, I'm not sure how it was implemented on the Node side uh and I guess you were saying: there's also container runtime stuff.

B

So do we have positive detection on the Node side to know that the container runtime supports username spaces, or does it just sort of tell the container runtime run this thing with username spaces and if the container runtime doesn't support it? It's like oh well, you got host namespaces. Do we have positive detection there.

C

D

C

So basically, the short answer is no there's a longer answer that uh that is, uh will probably back for the change to continue runtime, so it will probably honor or even on Old container runtimes, but but yeah like the the changes is a Backward Compatible change. So if you set this field in the CRI API, that is a crpc API on the other part you doesn't know about that field, then it's ignore.

B

So so that's back that's backwards compatible in that it lets the Pod run successfully, but what we actually care about before we relax policy is that it fails safe by not running the container. If the username space restriction wasn't honored.

D

So yeah, so if cubelet and the runtime are using the compatible grpc API, then, ideally the container runtime should fail if it cannot honor the flag uh pass through.

B

The CRA so so yeah some details about like how how we know that's the case and like at in what version did that logic get put in place? That would help us know when we can relax the run as user restrictions based on the presence of the.

C

uh Yeah, so for continually 1.7 for cryo I think it's cryo125.

B

Ideally into the cap and maybe have a section in the cap talking about relaxing the uh the Baseline and restricted Cloud security standards.

C

Okay, but maybe to to have an agreement, maybe on the simpler things first or maybe, these are simpler to to resolve, but so at some point the restricted policy. uh Should this allow not studying the user using the host username space right or that is not what we want for the restricted policy.

B

We so we are able to add new requirements to the restricted policy. um I'm, not sure if we would say we would disallow setting host or if we would require setting.

B

uh User namespace, true I'm, not I, can't remember the field name.

C

Yeah uh so, but those are synonyms right if you disallow using the hostess or namespace you're, mandating that you should use a username space in the board. Yeah.

B

It if I recall correctly, you are only allowed to set username space for stateless pods, which don't have volume mounts. It seems really strange to me that we would require pods to use username spaces like as a security measure when they could just say actually I'd mount a persistent volume in and then we would no longer require them to use username spaces.

C

That seems pretty soon Okay, so yeah, okay, so that is another thing like uh we'll add support for stateful parts, usually probably soon, uh but what I don't understand from your comment is: do you want us to wait until we support stateful Parts uh to add Port security, integration with Port security standards, or shall we do something before we support all kinds of parts? So.

B

There's two directions that we integrate: one is relaxing things like the run as user for yeah, which are using username spaces. I, don't think we have to wait for stateful support. We just have to wait to make sure nodes are actually honoring the username space restriction.

B

The other direction is we require username space in the restricted policy and David has a hand he can go. But to me that seems weird to require changes there when someone could just reshape their pod and not be required to use user interfaces.

C

Okay makes sense, yeah sorry, David go ahead, yeah.

E

So so I would really like to find a way to adjust pod security admissions so that, if I want to opt in I know that uh all my nodes are going to honor this because I own my deployment I would like to find a way to enable pod security admission to relax the requirement in advance. I think that's useful both because it allows refinement in my cluster things that are safe in my cluster are actually safe.

E

I know this, so I can turn it on, and it allows us to get um pre-ga signal on both the capability. Does it does it run well, is it efficient and the user? The felt user impact I am now able to change my namespace from either baseline or privilege down to restricted. With this new feature, I would like to have the ability to do that and without a way to signal that pod security, admission I, don't know how I would get that same signal.

C

um How how was that handle for other features like second, for example, that are similar in that we need the container runtime to really implement it, and.

E

C

E

Were present before, uh except for the.

C

All the others, what OS.

E

All the others predated pod security mission.

E

C

E

You you are the lucky first feature.

B

uh Well, the Windows support intersected with pod security admission and uh we actually waited until the oldest node had support or would fail safe with the the Pod OS field. Before we relaxed pod security admission.

E

uh So so doing it that way you know certainly safe. It prevents the ability to assess the felt user impact and I'll I'll say that I think you know I guess neither of these are super common right, but I, think user namespaces is broader than Windows OS.

E

The tricky part is it can't just be a feature flag, I, don't think I mean I, guess it could be.

B

Yeah I I, don't I, don't love the meaning of a given version of cloud security standards not being consistent across clusters. That's.

E

That's I'm I'm, certainly open to a second signal right, but I I do think we need to have a way to gain to gain feedback like does this interact? Well, does it intersect properly?

E

Maybe that's a secondary configuration option.

E

And none of what I'm saying is like hey: we should change the default. What I'm saying is, if we're going to opt into this and turn it on in a cluster and like the chances that Renault is going to come to me and say David. We should turn this on in a in a tech preview cluster. It seems very high, I'd like to be able to have a full story.

B

um I could maybe see an alpha level thing so that, like it, sets expectations appropriately like this is a preview thing. This is not a thing that you're expected to enable and then upgrade and like it's a try, it out thing. Maybe uh I, don't know I, don't think I.

E

Mean I'm I'm open to that, uh so I can I, don't think I would want it based well I mean looking at it. I, don't think I'd want it based on the feature gate like I. There's one argument that says: okay when you turn on this feature gate. This is what you get the issue is that because we can have skewed cubelets, um an old cubelet, wouldn't honor that feature game right, so there would be no way turn that on I wouldn't want to break somebody else's cluster. So a second opt-in would work for me.

E

B

Could have a specific feature that just controls relax pod security for this thing starts as Alpha dies as Alpha.

E

uh No well based on the yeah sure, um because it would never be on by default right. That would I think that would satisfy their need and it would let us get the code that we need in and try it yeah, because.

A

E

You can see you end up in a state where, like okay, you got three releases to get to the cute little bit and then now you have to have uh several releases in the API server to get stability and yeah.

B

Anything that's talking about pod security. Admission behavior is scoped to the control plane. So a thing specifically tied to that I think makes sense.

B

um As far as a cap update, I, think probably a section in the username spaces cap talking about how this interacts with the the Pod security stuff is, is good, I think that's what we did for the Pod OS cap.

C

Okay, but sorry, I'm, I'm kind of lost, I'm, not sure I follow. So the idea was: what do what seems to the idea that seems to fly is to have two feature guides right or how is it can someone maybe.

D

I can try to summarize what I got out of it and David Jordan correct me, so we'll we'll go and update the cap for username spaces and describe how we would want things relaxed and on the side to start getting feedback on whether a restricted policy can require this. We have a separate flag which will stay Alpha in order to test it out early and not having to wait till it's available on all the notes- and this is the second change also a part of this clip or that's a different cap.

E

Yeah, we'll be a part of of your cap to describe it locally. There yeah.

C

Okay right, but then the feature gate to relax the the checks for the rest of the Pod spec when username spaces are in use, will be a feature get for which component for the cubelet and the API server API.

B

Server pod security only lives in the API server, but.

C

Then but but you want but David wanted some guarantee that if we enable this feature, the cubelet will honor it right. So.

E

C

E

Coordination to the vendor or deployer or whoever's managing it if they come in and say, okay control, plane uh now use username spaces in uh pod security admission they better be sure that all their cubelets support it.

C

Okay, okay, so we can be super clear in the documentation about it like if you use this other feature.

C

The burden is on you to to know that you're not supported.

B

Yeah, if you opt in early it's on you to know that okay.

C

B

We relax by default I think we would need to have some guarantees in place like the oldest, supported node, understands the feature or failsafe and has a way to verify that the container runtime will honor. Okay.

C

C

If I'm missing something so we have two lines, one is two feature gate one is to relax the check when user in spaces are are renewed, so we allow things like running this route.

C

This will be a feature, get feature gate on the API server and the burden to verify that the cumulative will honor. It will be on the cluster admin and then we'll have another feature gate uh when the host, when the feature when username spaces are ga to for the restricted policy to enforce uh username spaces so and for that, the feature will need to be GA and support. Of course, all about not only stateless spots did I get it correctly. I.

E

Do I do not think I see a need to support all pods before enabling this feature. Yeah I should be able to recognize the pods for which this applies.

C

But but I mean uh like the like support, all the parts when we want to enforce username spaces in the restricted policy, because Jordan was saying that otherwise, you can just add a volume and circumvent the yeah.

B

So relaxing for username space pods, it's fine once we can do it. Save for people often requiring username space. Pods I, don't think makes sense until we can just require it for all pods, stateful or non-stateful.

C

Right but and the field should be GA beta Alpha, to require d.

B

C

Can't require setting.

B

A field- that's not GA, so, okay,.

C

C

Okay, so I think that's sum is up so for restricted, we'll wait to change the restricted policy to require returning spaces. Wait until the field initiate supports all the parts to relax. The checks for for when username spaces are in use, we'll use a a different feature gate and the burden to verify that the equivalent will honor it will be on the cluster Army.

C

Is this a good summary or am I missing some something important here.

B

I I think that makes sense. I I tried to update the notes as well, so hopefully that oh.

C

Okay, I wasn't going to do that thanks, yeah.

E

I think I followed all that I think I'd like to see it written down in the cap and reserve the right to like add a comment of I forgot. This oh.

C

E

Course, but in Broad Strokes, yes, that's that's what I'm thinking I think that gives you a way to phase this in get the feedback you need offer a carrot to a user. Who does the thing that you want to um I'm, maybe less sure about eventually requiring feel to be set.

B

But I'm also less sure about it. I know I wouldn't do it before it was VA and I really don't think we should do it before support yeah.

D

Behind me, I think we're also planning the stateful support so hopefully like by the end of the year. We'll have some clarity on.

E

Right but like hopefully, that gives you like a level set like I I I want to consider that last bit separately and the answer to that. Maybe a separate, no and here's the requirements to get there or no. This just isn't the right choice, offer a carrot and not a stick.

D

um Yeah, that's fine, I mean we can. We can revisit it.

C

Yeah yeah we can. We can mention in the cap that uh this is the rough high level idea and before migrating to GA, we'll clarify with cigar author.

F

All right, thank you. Thanks. Thank.

C

A

All right um automatic reloading of HC Acer in Kate's, client, libraries.

A

Do you have anything to share or you want to talk through it.

F

um I'm not sure if there is here, but uh can you guys hear me or not yeah, we can hear you: okay, okay. um Basically uh somebody working on a slightly different product than me brought this up. um Basically, when you rotate the you rotate the cas backing a kubernetes cluster, it looks like the root the the ca root that we Plumb into every pod, we're talking to cube API server.

F

That's not it just read once at pod, startup and then kind of held Forever, at least that's what it looks like to me. um So you have to bounce every pod in the cluster when you rotate the.

A

E

I only looked at the code, that's a bug, not a feature.

B

I really thought that we had reloaded TLS files.

B

uh Is this like the in-cluster, config and client go yeah.

F

So we make a cert util new pool with the file name.

F

That reads it and makes a new pool from the bytes all right.

E

I would be happy to see that fixed.

B

B

G

B

uh We if we can't load the file we error. If we can load the file, we set a pointer to it in the client config in the client config, we say dot CA file here. Let me uh talking about oh yeah. There we go so we this. This is a check to make sure that the like the file that we're pointing at is a valid start bundle, but we actually propagate downward is a pointer to the file, not the content.

B

We loaded from it, okay and so later uh elsewhere, back on the ranch uh uh like I'm, pretty sure that if we are given pointers to handles, um we load the content, but then we set reload TLS file is true and I thought we uh like set up. The background was the issue you were seeing just based on inspection of code, or was someone actually observing like a rotation failing to.

F

It's a second-hand observation of observing a failure to do this rotation, so I'm, not sure in what depth they actually looked at it. I'd.

E

Be supportive of a test proving in update this? Oh.

G

E

Test fails, I'd be happy to see it made reloadable.

B

It looks like the automatic where we automatically set reload TLS files to. We are only doing that if you were given cert files and key files. We do not set that to true.

B

If you were given a CA file so uh yeah, it looks like there's a bug, but it's above and a test and a fix would be welcome. Okay,.

F

Sounds good I just wanted to check like? Is it something we need to discuss or is it like? Can we just do that? That sounds you can just do that just fix it.

A

Lauren, are you looking at uh specific files right now? Do you want to link it.

B

Yes, I am, and yes, I do.

A

A

B

Thank you for bringing.

A

B

A

All right uh next inconsistent authorization of node resources.

G

um Yeah uh I I put that in so uh so there's a urban looking at like trying to get the metrics uh uh add-ons like Prometheus running on uh clusters, with some restrictions that prevent you from um uh running exec on the nodes. uh I saw that there's this kind of difficult position that we put users in that like there's, two ways to get say: node metrics uh on any kubernetes cluster, the kind of the official or the most supported way would be uh via the API server right like we don't.

G

We don't recommend that you uh we allow direct access to the cubelet so uh and uh the problem with uh getting say nodes metrics from via the API server uh requires a very high level of privilege. It basically requires the proxy sub resource on the uh the basically that lets you like run arbitrary commands on on any container running on that node on.

D

F

G

There is some uh subdivision of the uh like the rbac that cubelet will use uh to authorize requests so that, like you, only need a subset of the permissions to say access, metrics or stats. um So we put users in this difficult position where, like you'd, need different position. Permissions.

G

If you are the connecting to the nodes correctly, which we don't recommend or if you use the recommended path, which is via the API server proxy, then you require like a very high privilege, and you can't really take advantage of the uh our back uh sub resource division. That is uh that cubelet supports. So this is basically an explanation of that and one I have kind of put in as examples or like initial thoughts about certain ways.

G

We could potentially fix that one is to make the way cubelet creates uh Maps the request path to the request attributes when performing a authorization request consistent across cubelet and API server, so cubelet would would require just node slash, metrics, API server would require node slash proxy, so one proposal is to make the authorization uh nodes in API server match what cubelet does so you, you don't have to have direct access to the node and uh you you get to assign the least amount of privileges to any client that needs to access, say node metrics.

G

So my question is like: what can we do? uh Is this a problem that is worth solving and is? This uh is accessing? uh Is letting add-ons and applications access the node endpoints directly kind of a supported path to the long term uh r.

G

Are we taking the position that like if you are connecting to any node resource, uh any cluster resource, you should be going via the API API server? No matter what in which, if, if the letter is the position that we hold, then we should probably fix this inconsistency and allow users to uh assign least privilege to uh to their to the workloads.

E

I'm not a fan of changing the rbac contract or actually I guess this would even go to the all authorizer contract to.

D

E

Path for resource requests.

E

That's not a statement of like you.

F

E

The other problem that you observe when we're the other but I.

D

E

I have appetite for making that larger shift because, like what would happen, if someone didn't honor, it you'd have to make sure that it failed safely everywhere. Yeah. It's.

A

G

I kind of that's why I kind of marked it as a hack but I think the real solution is to uh is something that looks more like the reinterpret request right like, uh but that also has problems in that uh to preserve backward compatibility. We would need to uh uh also allow proxy proxy should also match the metric sub-resource right, um so so that any previous authorization to just allow proxy, which is what I think more most plants, would do, um would also still work.

B

Does it does the node is the is resource request, false there accurate when the when the cubelet authorizes things it authorizes them as a resource request.

G

Directly, you don't have much of a problem right, except that we don't. We kind of explicitly say that uh direct node acts like accessing the cubelet API endpoint is not like not permitted. It's kind of an API server bypass press, you bypass all of the admission control and all of the like the security controls are uh all of the controls on the cluster are in the API server and letting uh letting clients access, tubelet, directly kind of bypasses them, and we don't recommend that and not not.

B

Really like it still gets, you still had authorization, which is all you're going to get. If you go to the API server for a read request, like a get request.

D

B

The things that you can do against the keyword API directly with fine grained authorization. It's like read of logs, read of metrics, maybe read of PODS like those read requests, still hit authorization.

B

The cubelet can still delegate authorization checks to the API server you're, not you're, never going to hit admission for read, requests um I'm, just trying to understand like what additional policy do. We think we're gaining by going through the API server SED I'm.

E

Sorry, what I was going to ask to be sure where the scraper he was running ran.

G

uh It could run outside the cluster right.

E

And that's where it is, he.

G

E

Knows because they're not exposed yeah.

G

Oh yeah, that's that's also a possible a reason to look in look at solving this problem right.

B

Yeah I, um what every time we talk about, the cubelet API, uh we kind of skirt around the fact that the cubelete API is not really a thing. That is, super well defined and we kind of say: oh, we don't really want people like using it, but then some sometimes it's.

B

The only thing you can use has has this prompted any discussion and sick note about like defining that better or guaranteeing that we're testing it or, like I'm, hesitant to do special case things in the API server around an API surface that is sort of explicitly disclaimed.

G

um Right um so uh to regard even let's say we make improvements to, but the changes that you would need to uh uh it's like I'm, trying to imagine the better cubelet API that would make this problem moved and I'm thinking. That would be something along the lines of uh where the safe and metrics sub resource is a uh is a resource.

G

That's actually known to the API server and interpreted especially like in the uh today like when you do a API V1 notes, uh node, slash proxy slash, metrics, uh stash metrics is just a path. A cube, API server doesn't really care what that is right. So, but if there were a node API, then the path would look something more like uh nodes. Slash no uh note, slash, node, slash, say metrics API or something like that, and uh that would be the uh that would then be proxy to cubelet. So is that the thing that you're.

B

Like um maybe like, if, if we're, if we're actually saying this, is an API service that we want to support um rather than trying to just solve the authorization part of it, and let people still go through this sort of unstructured catch-all proxy hit a random endpoint on the cubelet middle man in the in the API server and just authorize it especially like it seems like if, if logs and metrics and stats, if we're saying these are so uh fundamental and important, we need to support it.

B

We need to do special things around them, like actually exposing them as real sub resources seems like a more natural way to do it. I I, don't know if we want to say that about those.

E

Apis I thought so so I might have misunderstood, The Stance just taken three months ago regarding node logs. uh Are you saying we should reassess that and say you know what these these endpoints are special. We do know they have different Behavior than proxy in general. We do know they can be authorized differently than proxy in general, and we do recognize that in some deployments they are valuable to be recognize differently.

E

I'm happy to do that, but that is different. Right I just want to make sure we don't send them off and then light them up for the same thing. That happened in no blocks.

B

I, don't I, don't know. I I wish. Okay.

E

I am convinced that at least three of these that I recognize logs, metrics and stats are different than General proxy and that the people that I would give access to for logs and metrics and stats are different than the ones that I would give access to for proxy in general, and so I could definitely see a case that says these for nodes are special.

B

Metrics I can believe, because that is produced by the cubelet and limited to the cubelet log. I. Think the questions about like what's the scope of the API and does this make a first class API that exceeds the scope of kubernetes components. I mean it's the same thing we talked about before stats.

B

I could believe as scope to kubernetes components, but I actually don't know the stability level of that I think there's been a lot of work around like what stats show up there and as we move from Docker sham to containerd and from C advisor to I, think some of those stats got deprecated like I I, just don't know the stability level of those things and once we expose it as sort of a cube, API server facing API I think the like what we guarantee about the content of that needs to be a lot clearer, so metrics and stats I think there's a clearer path too, but I would have questions about like the content of those things logs I think we run into the same question about.

B

Does this surface via API, something that exceeds or goes outside of? Kubernetes scope.

G

Do I understand correctly that you can't you can authorize someone to access just the parts logs right uh that that is something that's possible through our bank today? Yes,.

B

But right I mean the sort of the rationale behind that being different than node logs is that the Pod logs are completely owned, like they're limited to things managed by kubernetes. What you can access via node logs is currently like any log on the system and with the new Alpha systemd Windows service support. It's like any log of any service running in the system. Yeah.

G

That that is, that looks like a kind of a time bomb like because there's lots. There are a lot of components which accidentally uh forget to scrub the uh the logs of sensitive data and uh yeah. It's.

B

um So, rather than focusing just on the authorization piece, I guess I would want to know like are these apis? We actually want to support so, let's Define them and like say what the guarantees are, rather than just special casing the authorization bit okay.

G

So I think I should go talk to signode and see uh see what they think about this is that right.

B

I think more clarity can only help, even if even for people who are currently using those endpoints directly against the cubelets um and I would I would try to do this yeah more more holistically, and for that we need feedback from the signaled on, especially the metrics and stats like what's the stability of those? What's the long-term plans for those, if we wanted to promote those.

G

And there are a lot of other actions being added as well like this checkpoint is a new uh entrant which unfortunately, was not added as a new sub resource when it was so you're still using proxy, then.

B

Yeah I I think proxy is a decent um until better guarantees are made uh having things live under proxy and require like super broad access and have a disclaimer on the says. This can't be part of conformance like we don't this API service isn't really guaranteed.

B

um We shouldn't promote things out of there until there is more clarity about what we're actually supporting there like as soon as it becomes an API that you can call directly and Cube API server. I think people have way higher expectations that that won't break.

G

Okay, so yeah. So the conclusion that I draw from this discussion is that, like the the path is to define a stable API for these things, so that uh they can become excellent, stable, uh fully grown resources and uh then kind of the the fact that we use proxy as as a casual path, goes away by itself. Right.

B

That seems better to me. What do you think David.

E

I yeah I mean stability, I, don't actually know I, don't know today what the sh I also don't know today. What the shape of stats is I thought metrics was fairly well set, though I thought metrics was here are: are Prometheus metrics same form as everything else yeah.

A

E

Was known so unless we're going to say to the, unless the no team is going to say, come back and say, we think we should re-evaluate the shape of our server and that one looks pretty stable to me.

G

Yeah, uh but uh one question I have is that like? Would this be a much bigger problem uh than uh that's defining like a kind of a metadata format that uh makes it suitable for uh direct uh like a full-fledged API surface, uh but we need to Define, like the schemata of the stats contents of the stats response itself right.

G

um Would that would that be a prerequisite to making it or or could we could this be like a raw extension where it could be arbitrary, Json data under a field and some metadata that says uh that these are a node stats? Those.

B

Are probably better questions for Sig node, I I, don't know that I would try to radically change the content of those endpoints. What I would care a lot more about is like if someone, if we add or not, we if signode adds sub resources for these and someone integrates with them. Can they be confident that they won't get broken in the.

E

Future and for that I think practically. You need to have some way to recognize your serialization version and I. Don't know if the serialization version is known for stats, I, don't know for Prometheus I think we have an expectation that it won't change, though.

A

E

I guess we haven't defined it oh and then for logs I suspect. We could actually find a way to constrain logs to do the 80 case safely um and not exceed scope, but I wouldn't block something like metrics on it. I just want to make sure it was going to end up in the same category.

G

um Sounds good thanks, I'll I'll check with the no stick node and see what they think.

D

A

Okay, um I think that's, that's it. That's all the stuff on the agenda uh there, any anything else anybody wants to talk about. If not, we can end it.

A

All right, thank you, all, have a good one.

G