Kubernetes SIG Auth, 16 Feb 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: [SIG Auth] Bi-weekly Meeting for 20220216

Description

[SIG Auth] Bi-weekly Meeting for 20220216

A

uh Hello: everyone welcome to the uh february 16th meeting of sigos 2022.. um Let's get started, looks like we have a little demo um to kick us off. Jordan, yeah.

B

C

Make sure I'm sharing the right.

D

Tabs there we go.

D

C

All right, can you see my terminal yep, all right cool, um so as part of the work around migrating to bound service account tokens. We wanted to make sure that we had a good user experience, and so we spent a lot of time in past releases working on the aspects where secret or tokens are mounted into running pods, and so that that went pretty.

C

Well, as we are wanting to turn off the auto generation of secret base tokens, we want to make sure we have good user experiences for people who might be trying to use secret base tokens, and so um we just added a command to cube control, to allow creation of bound service account tokens using the same cue control, create pattern that we have for other resources.

C

So I just wanted to give a run through of what that looks. Like so first step, I'm going to create a service account, this already existed and this service account is going to be the thing I'm going to be getting credentials for so to create a token for that service account.

C

I can now run keep control, create token and tell it the service account I want, and this is submitting a token request and getting back a bound token and by default it just spits out the actual token, so I could dump this into a file or capture this in a environment variable.

C

If I output this to something that is not an interactive terminal, it actually drops the new line as well, so we avoid the like trailing. New line gets picked up and passed in the header values anyway, but because this is a standard, cue control create command. We can also output uh the api response. So if we wanted to see other parts of the api response, we can say output yaml and we can see all the information about it right. We can see what our request was.

C

We can see the expiration timestamp that the server set on the token, and then we can see you know the token um and so just to prove that this is actually doing a thing. I'm going to capture that into a environment variable and then curl the server, and it correctly authenticates me this service account. Doesn't happen to be authorized to do anything, but it is authenticating me as that user, so authentication is working a couple. Other things you can do. um The create command supports the options that the api object supports.

C

So we can ask for a shorter expiration time. So, instead of the default of one hour, we can ask for a shorter period of 10 minutes.

C

One thing that I added to the server while I was doing this was a warning. If you ask for an expiration longer than what the server will allow. So we've always said the request is advisory. The server can shorten it at its discretion, but now, if you submit a request, that is longer, I have my server set up to bound it to just under this.

C

You also get back a warning header and that gets displayed using the normal warning response mechanism. So it's in the header and the response cube control already prints that to standard error, so we're taking advantage of that mechanism, which is kind of nice.

C

Last thing I wanted to show was uh binding, so bound service account. Tokens can be bound not only to the service account instance, but also to a particular secret api object or a particular pod api object, and so I'm going to show what it looks like to bind to a particular secret api object.

C

So I've created my secret and now, when I create my token, I'm also going to bind it to the secret and tell it the name of the secret that I want to bind to, and so you can see that showed up in the spec. So the server recognized that and then what that looks like in practice. We do run that again, but capture the result.

C

um So now I've got my token bound to that particular secret object and it works to talk to the api. But if that api object, that secret gets deleted.

C

That token no longer works, hahaha that's funny there we go that token no longer works. um I think that was our 10 second token cash, uh I'm pretty sure that was it, um and so what that lets you do is revoke. Tokens uh like create tokens for service account, associate them with a particular secret or pod, which is what we do for the ones injected into pods and then control the lifetime of that token. Via that api object as a proxy, there was actually no content in that secret.

C

It was just a marker, an api object for us to say this thing with this you it still has to exist, or this token isn't valid.

C

Oh yeah, one last thing was about audiences, so we really want to encourage people to start using audiences when they're setting up tokens for use against things that aren't the cube api server, and so that's supported here as well. So I can ask for a token for a particular audience, so this might be for talking to vault or talking to some other endpoint, and if I capture that and try to use that against the api server, uh the api server says like I don't recognize this token. This does.

E

D

Token, doesn't let you.

C

Authenticate to me so um nothing new api wise, but this takes the power of the api we already made and makes it accessible to control users. That's it.

A

Awesome. Thank you. Jordan.

A

Can you bind to a both a pod and a secret.

C

Just kidding, I don't think so, I think the bound object ref is singular in the api. um Yeah is it I don't know. I can't remember.

A

Awesome thanks uh for the demo, jordan.

A

There are no questions. uh Let's move on to uh issues of note.

A

uh First, one looks like we are incorrectly parsing tokens that start with a space.

A

um Who put this on the agenda.

D

Maybe it was cj, I I think more actually, but we were triaging issues on monday and he added this to follow up.

C

Yeah trying trying to figure out like are we gonna, do anything about this? If so, what and when and how we're just trying to like clear out sort of perma valid but not resolved, whether they're actionable yet issues.

A

Oh, this one is a tough one, yeah.

D

A

Okay, what do you think I don't know if it's worth it, it just seems.

C

It's so I think it's very confusing that if you think you're sending a token and you have an extra space, the server actually says. Oh, this isn't a valid bearer token header. So our bearer token authenticator just ignores the request um and you end up anonymous.

C

uh I think it's probably worth warning saying you sent a bearer header, but this is a malformed one, so we're not going to honor it. Like that's a non-breaking thing. We could do that.

C

Would let people know when they have this issue.

E

Or yeah the header, with a token that starts with the space.

C

D

C

It's a malformed header. uh I don't think the spec allows spaces leaping spaces and tokens um okay,.

A

And if it is a token that starts with a space, then we've been returning system anonymous for imperfectivity. However, if we start returning a warning, that implies that we would change something and if no.

C

Not necessarily so warnings are for problems, we are aware of that are actionable by the caller, and so we return warnings for apis that are deprecated, that don't have a replacement that aren't intended to be removed, but are deprecated so we'll say so. You know this is dedicated. You should stop using it. That's the action you should take in this case we're saying warning: you're sending us a bear token header, that's malformed, we're ignoring it uh fix your token header.

C

I think I think a warning is the least we can do it's non-breaking and they clearly meant to use token authentication and they're not actually using token authentication.

A

Do we ignore it if it is a valid token, or do we just look for space split on spaces.

C

We so the bare token authenticator says: does this request have a header that I recognize and if it doesn't have bearer space token with no spaces, then that authenticator says I have no opinion about this request ignore it, and so it falls through to the anonymous case. It's it's as if you submitted a request that said authorization blah blah blah blah blah like this. Isn't this isn't a recognized uh authorization header, so it ignores it.

A

Then why don't we just okay? So then what is the downside of just fixing it.

C

That would turn requests that currently fall through to anonymous and depending on what they were requesting, maybe were allowed like. So the example mo gave was someone has a load balancer that they thought they configured with a token and it's sending it with this weird malformed thing, and so it's falling through to anonymous. But the end point it's hitting is health z, which is actually allowed to be requested by anonymous, and so by.

C

Turning this, what previously worked as an anonymous request into a hard failure, we could be breaking down.

C

I would start with a warning I would consider making it treat it as an error, but I think that's a second step, a second decision, and I'm not sure about that. uh I didn't.

E

Actually have the.

C

Ability to like how many of these hitting, if there's a way to do that, um so a warning, maybe a metric, and that way that at least gives people like some visibility to if they have clients that are doing this or getting this.

E

Can this header end up going to downstream systems, or does it die inside cuba passover like do we need to have the authenticator notice that the malformed header was there and strip it? Even if we are going to allow the request as system anonymous.

C

We strip the authorization header uh in the authentication, filter, okay, yeah, so once once you pass through the authentication filter, we drop the authorization header completely, so it's not visible to anything downstream in the hand or chain. Okay.

A

Yeah, okay, so some of the warning and maybe metric.

A

We can consider.

A

uh Treating this uh as a bug, sometime down the line, but um that's a warning, seems that we are falling through to uh anonymous, uh seems uh reasonable.

C

And useful, like the main, I think most people either are hitting something that anonymous can hit, and so they don't actually care if they're, authenticated or not or they're super confused right now about what do you mean? I gave you a token. Why am I getting errors about anonymous like what in the world's going on, and so the warning will help that type of person.

C

A

All right sounds good.

A

Awesome next one: uh is it expected that bounce service contact can stop being refreshed uh for pods that have been soft deleted?

A

So, let's see what happens, the node authorizer gets a delete pod um when the pod is soft deleted and then gets a tombstone when it's fully deleted. Is that right, jordan.

C

Yeah, it's deletion time stamp set, but the pod still exists.

C

The pod doesn't go away until it's completed, it's termination grace period or the process has effects, it hasn't been cleaned up and the cubelet says it died earlier than.

A

Its grace period and then what do we get from the informer.

C

um Informer just sees it as an update to the pod.

A

It seems completion as an update or the soft deletion as an update.

C

Yeah, because it's just updating it with a deletion time stamp. um Do you know where this is happening? Is it is it that the cubelet stops trying to keep the volume out up to date?.

E

I'm still not sure I was just throwing this out there to see if this was like yeah. That's totally expected um no.

C

It's not expensive. I.

E

Need to dig further then.

C

If I have a pod that I say takes an hour to shut down um because it has to whatever, like finish a job or during connections or whatever um the volume mounts that say, they support remount should keep getting refreshed during that life cycle.

C

Like the volume subsystem in the cubelet, that like is it continuing to refresh those mounts, that's one question and then the other question is: will the node authorizer allow the cubelet to keep requesting updated tokens for a pod? That's in its deletion grace period and the answer there should be: yes, like that we intentionally um don't cut off the cube. Let's access to get tokens until the pod is like gone or has exceeded its grace period.

E

Okay, yeah, then I'll need to boil this down to like a reproducer and.

B

E

Issue, I think um yeah, it is the case you said like we have a team in google that is like setting termination grace period to 12 hours uh like. Why is my token, stop working, I'm like. Why are you doing this, but it just.

C

Seems like, but but no the the volumes of the cubelets managing on behalf of that pod should continue to get updated until the pod termination is done. Okay,.

A

A

Right um cool, moving on to discussion topics: we have a cubelet certificate, provisioner projected volume.

A

um Let's see uh to here, do you want to take the floor and explain what this is.

E

Sure so this is um a follow onto a proposal that ted and I brought last year um that was more wide-ranging about uh sort of integrating service account certificates into kubernetes. um The feedback from that proposal was: let's focus on one first piece that brings immediate value and is shippable. So that's what this uh proposal is. um Basically this. What I'm proposing here is a plugable mechanism that lets um gives kubelet the ability to request certificates for pods from signers.

E

Signers being the in-cluster implementations of things that listen to csrs, approve them and issue certificates against them.

E

There's two aspects to the proposal: one is the actual nuts and bolts of getting a certificate from the signer and then the other is a new way for signers to communicate their set of trusted root certificates to pods.

E

There are basically I've got a couple of use case examples in there. One would be for the server tls use case, where you wanted to request a certificate and key that can be used for server tls and the other is for mutual tls, where you want a certificate key that can be used for mutual tls.

E

Let's see, the other main point is that um the communication between cubelet and the signer is pretty constrained. So we've gone opposite so, instead of making the csr that cubelet sends to the signer very configurable, instead, we've settled on a fixed format.

E

For that the csr, and then we just tell the signer just because that the csr that came from cubelet has this format doesn't mean anything. You just need to parse the information out of the csr which it carries. Information about the service account that the certificate is being requested, for it contains information about the pod. The certificate should be bound to um and some other a few other pieces of information, and then the signer can make its own security checks.

E

Does it believe that this is a valid certificate to issue and if so, issue, whatever a certificate in whatever format it likes? um So you could imagine a project like cert manager would parse out the service account and pod information. You know: do some out-of-band check um some non-kubernetes check to make sure that hey? I really expect this service account to be backing. You know a given dns name and if so issue the certificate against that dns name.

A

Yeah we had previously uh talked about uh um separating the like what is the coupling between uh the cubelets uh certification requests? Functionality in the trust, anchor cubelet trust anger, set projection.

E

There's very little coupling actually only that.

E

E

Only that they are both needed for the mtls use case, um but the trusting reset use case could also be useful for non-mtls use cases and that you still need a way to get trust anchor sets into the uh pod file system and right now. This cube projected volume type, is how you do that.

E

But the intention is that trust maker sets would be widely readable within the cluster, so pods could just directly read them from the abs server as well.

A

Yeah, um so it seems like uh the trust anchor set, um is independently useful um in my opinion, and I think that would be. I don't know everyone told me, but it seems like that uh could proceed now. We have you know an old issue kind of tracking this work. um It seems like um you know we could get it kept in for just that piece in 125 and start making progress there.

A

um I think I heard similar um opinions from uh david and others uh last meeting, if I recall correctly um for the um the other portion, what has been the feedback so far.

E

um Let me take a look over. We had some discussion around what actual security checks are needed um inside signer and inside cube api server around.

E

Granting the csrs to prevent to maintain the node isolation.

E

Node isolation, guarantees of humanities.

A

And what are the go ahead? I was going to say and what solutions uh are proposed.

E

I think where we settled is that, while it may be a good idea to restrict uh you know built-in suspenders, which cubelets can make csrs, for which.

E

uh Can make css for uh whichever um signers and asserting whichever service account identities? It's not actually security, critical, because the expectation is that's just having an unapproved csr hanging around harms, no one and it's the signer that needs to take the action on approving and issuing the certificate.

E

So it's inside each signer that they have to draw a security boundary, and we've outlined uh some of the security checks that they will have to do in order to maintain the node isolation. Battery.

A

Yeah, I guess more, I guess, then the question is: how do how do they do that? What's the best way for signers to implement that, how do they query the? Do they query the node graph? Do they maintain a separate graph.

E

So all I can say is that we built something similar built on csi drivers and our custom signer. We thought about. I think we currently maintain our own node authorization graph rather than trying to be back on the.

E

Node authorization graph inside q, api server.

A

um So what are the leaf certificates signed for? Are they signed for pods service accounts services, anything under the sun that is totally up to the signer implementation?

A

Okay, what information? um I'm sure it says it already in here uh what information I I guess, it's just basically the signer name that dictates whether you wanted for a service or whatever yep.

E

A

E

It so we send some information to the signer inside the csr, but signers are free to check more information like pod or service account annotations if they want to so like a cert manager, style use case where you want to get a publicly trusted certificate, you could imagine um you know your pod is in a service. The service is annotated with the dns name, that you want to appear in the certificate and then the signer is responsible for checking that the pod and services account really do back that service.

B

Not that I'm certain that it matters, but would the api server be responsible for checking that the csr bytes match up to the csr object.

A

E

A

Not today, yeah.

E

And I think what we recommend in the security rules is that signers check very carefully that this was actually requested by a system, colon node identity, um and then that gives some assurance that this isn't just some rando making. Csrs.

E

And checking that the csr was created by system, colon node is.

E

Sorry lose my train of thought that is enforced by the api server like the the caller, that's populated by the api server, as the csr is created.

B

Right anybody can create a csr, but the signer checks that it is in fact a node that created the csr.

A

A

um Yeah, I I think this looks plausible. There is certainly, from my perspective, there's certainly a lot of configuration um knobs that um I might recommend adding incrementally, but.

A

The general flow seems reasonable. I guess the one thing that I would be interested in is, if there's any ideas on how to um extend the node authorizer with, like maybe like um a cert verb on service, counter cert verb on service. That would make the job of the signer um easier, rather than maintaining their own graph. If that's, what it comes down to, um they would be able to issue. Subject access reviews.

F

Reason that we're talking about adding this as a projected volume which which I'm not super up on storage, but I believe projected volumes are actually baked into cubelet code- uh is the primary reason we're looking at adding this to the cubelet code to have access to that cubelet identity, as opposed to doing this in a csi driver, and if you have a functional csi driver today is, is that csi driver using the cubelet identity in some way? You said you were betting, that it came from system colon nodes.

E

Yeah, so we today on our, we have a spiffy issuance um thing that backs some stuff inside jk. It's um we today hijack the node identity, so we run our csi driver as like super root on the node, and we just steal keyblade's credentials in a certificate and then act as the node identity.

C

So it's highly privileged on the node, but it also is no more privileged than the node.

D

And the node, so that's how.

C

You get around the uh or how you avoid escalating to like.

A

Yeah, I think it's a fair question that needs to be addressed in the cap of why uh we would use a csi driver. Well, I would use the protective volume instead of the csi driver. um The one thing about trust anchor sets is, I I think it would be really nice to reference them from dynamic web hook configuration instead of embedding certs there.

A

So I think you know at least some support in core is probably maybe useful or necessary. For that I don't know if that's an argument for making trust anchor sets exposing them via projected volumes. I think there's then the separate argument for using projected volumes rather than csi for the actual certificate, provisioning stuff um sure I'm I'm happy.

E

To split it out and make like a real cap for the trust, anchor set stuff and work on that first.

E

I think there's some strong, so at least in my mind, the strong argument for putting the using a cubic projected volume, as opposed to a csi driver, is that it's primarily around, like cubit is already responsible for pod identity in general, and these certificates are another aspect of bot, identity and there's a security, critical aspect of odd identity. That's very easy to get wrong.

F

E

Likely to get it right.

F

By authoring it as a projected volume and I'm not familiar with writing either of these things, I'm just surprised to be easier to get right. That way versus a csi error.

E

Well, I guess we could offer a a one-and-done implementation of a csi driver that, like ships with kubernetes, um that's a valid approach. But if we're doing that, then it's kind of like eating resources on every node, as opposed to just putting a little bit of extra logic in cubelet.

A

Yeah, I'm not sure what the current philosophy is um around inclusion. That might be a good question for a storage team.

F

E

Interested in that right, because.

F

As a csi driver, I could install this on older clusters. Current clusters, keep it up to date on you know every cluster I have, they could all run the same version.

F

I see some benefit to a csi driver, I'm interested in in what like whether there's something functional that makes it easier to write or if it's simply well, this gets us included everywhere.

F

It's okay to answer in the cap. After talking to sig storage, like I don't, I don't need to have an answer now. It's just I mean I, I would say it's not. There's no.

E

There's no like blocker to shipping this functionality as the csi driver. That is just advertised as the way you get certificates, um but I think that argument can be applied to a lot of stuff that cubelet does so I'm not sure what the maybe sig storage is. The person is the community to talk to about that.

E

A

E

B

Was a question in the chat.

E

um Ahead, would there not be a need to pass some arbitrary data credentials to the signer for it to be able to identify the identity requesting the certificate um at least the way I'm thinking about it? Is the csr is fixed?

E

It only contains information that identifies the service account and the pod that was actually requesting a certificate, but signers can read extra configuration data from annotations or from any other source that they like, but they start all their operations by noticing that it is, you know, service account x, running as pawn y requesting a certificate.

E

Then they may go. Look for additional configuration in other places like the service account may be annotated with some identities that should appear in the certificate, and then the signer has to do whatever checks. It feels like isn't are necessary to make sure that those aren't being spoofed.

A

Yeah, the authentication information is immutable after the certificate signing request is also created, so the data about who created the csr is as trustworthy as cube. Api service authentication configuration.

B

But what if I want to add multiple certificate, projected volumes certificate projected volumes to my pod with the same signer? How does it determine which one is which.

A

E

That's a good question: yeah, that's a good question.

B

um I could see just adding and not to the csr, not even on the csr. No, that wouldn't work.

B

um I was going to suggest adding to the the projected volume a projected volume like configuration, string that but we're we're not referencing in the csr which projected volume mount, which projected volume volume- I guess pod.volume name uh might be something that we could add to the csr format.

E

That seems reasonable, like add the volume name directly.

B

Yeah and then then you could say that the volume name is www.foo.com, and that would be enough, for uh you know, for the.

E

I think technically, you can have multiple different projected volume sources inside a single projected volume, so something a little more involved than that. um But I really what I want to avoid is having pod authors put some arbitrary data in the volume config.

E

I think that's hard to get right, but I think we can find a way to disambiguate multiple volumes or multiple projected volume sources right.

B

Inside well, pod authors, putting putting arbitrary data into the the pod spec seems fine, so long as that is not necessarily reflected in the csr format right if we were to allow them to put a uh arbitrary arbitrary data into the pod spec. But the only way that you can reference that, but by looking at the csr grabbing the name going to the pod grabbing the volume from that.

B

That seems like it's less likely that you're going to get that wrong. Maybe I don't know.

D

Okay, I'll have to think about that.

A

um Yeah, it sounds like if you need that level of flexibility. uh You almost just want uh it's a support, annotations um or equivalent.

B

That might be the right answer is just just annotate annotated on the pod. Although annotations are mutable.

A

It uh it only matters on the certificate signing request api and if those annotations are mutable on the csr objects, which I can't remember, if they are or not, then you can just create a separate field in the csr object. That is not mutable.

E

Oh so you're saying has the ability to, in the projected volume source configuration, have the ability to configure annotations that will appear on the csr all.

A

Right it could yeah, I guess, key value on this projected volume that could appear either on the csr as annotations or as a separate key value for um somewhat arbitrary configuration.

E

E

So I guess next step I will make a cap for the trust anchor set piece of this.

A

And talk to sig storage, about recommendations on entry versus auditory.

A

Cool uh does anybody else want to give any more feedback, or do you want feedback on anything else?.

A

Awesome. uh Thank you to here.

A

Looks like we are uh through with our regularly uh scheduled topics. Is there anything else that somebody wanted to grab time for before we head into ci stuff.

A

A

Okay looks like uh we are less green than usual.

A

Maybe not two or four our.

A

Upgrade tests are a little bit flaky, but they have failed once I guess they run daily.

C

I'm not losing sleep if it passed the last five times.

A

Yeah all right.

A

Yeah, I guess they're low frequency so.

A

um The rest are.

A

A

A

Test doesn't exist anymore.

A

And upgrades are still pretty green.

D

Secret store uh yeah for the periodic ones like I already have a pr to fix it, so it should be green. So awesome.

A

Cool and flakes.

A

uh Still, the service got discovery.

C

This is there's still an open issue for it. um It got bounced around. It looks like there's something weird or some difference with the network setup on some of the upgrade tests, and so it's affecting the way the api server starts, like it can't figure out what its public ip is, and so this is like one of the only tests that actually does things that care about the public ip.

C

um So it's failing, but it's a misconfigured api. I've routed it to networking folks and they don't have any idea. So I don't know what to do with this.

A

C

A

Like the perfect.

C

Nexus of the cluster directory and the upgrade tests and network weirdness and no one's really sure who is responsible for that bit on that config.

A

Okay, so what do you think we should do? Do you think we should invest more time into trying to resolve it.

C

At this point um well,.

C

I don't honestly know.

C

I guess I would ask them if no one is taking ownership of the network config for the upgrade tests, then I guess I would like exclude this test or exclude this test type in that job. I don't know I don't like that, but I also don't know how to fix this job.

A

um Okay- and there is a bug going around.

A

That you filed yeah, um I can drop it in to the agenda or in the chat.

A

A

um All right moving on, we had a couple flicks of the same test in the non-upgrade suite the non-upgrade street is unaffected, or do we expect the same failures.

A

In the non-upgrade suite.

A

Do you know if this is only upgrade related to jordan.

C

I think are those on windows. I I can't really see your screen. Sorry.

C

Oh yeah, they are on windows, okay, I think we reached out to windows and there were like dns propagation timing, issues that were known on windows where um stuff doesn't work as quickly on windows. I don't know if there's an issue specific to that. That seems like something that should stay open and actually um maybe get addressed, because that seems like it's beyond the context of just this test.

A

There are more windows issues down here, same test.

A

Service account should support in cluster config. With token rotation is, has a flaky rate of.

A

Six times for.

C

A

You look at what's happening.

C

Like that, flake is saying the pod never became ready. um So that's not even getting to the point where the test was testing what it was supposed to test. I suspect, if you look at that failed job like there were a lot of okay timed out. Pods didn't become ready issues with that.

E

A

C

um What's the actual error above I.

A

Think we've run exit status, one.

A

What, uh if I recall correctly we'd like run like a command in check.

A

The pod file, um the token file.

A

Read file via container, so I think we'd run like cue control, exec or something weird to figure this out.

A

Yeah keep control exec.

A

Is failing occasionally.

A

With the 256.

A

um yeah, it might just be weather as well, but we can double check that as weather.

E

A

Oh, this is interesting default service account has too many secret references.

C

That is a test that is stressing, creating and deleting uh the secrets and making the token controller react to that and then clean them up and then create new ones and then add those in.

C

I would guess that this flake has existed for probably five or six years at this point and with the stop auto creating tokens work going on this release, um I would expect that test to go away because we will no longer try to spawn and stomp in new tokens.

A

um Metadata can submit. Is this actually useful tests to continue to have? um Has this ever actually helped us in any way.

C

Who knows about the dust.

A

uh I think it was ike who've worked on this a really long many years ago, five years ago, four years ago, but it runs like a proxy that blocks the metadata server or specific paths on it. I'm not sure it's like if this is like a good generally useful, open source test.

E

Is this only this only covers gcu metadata, concealment right, I'm sure.

A

uh Theoretically, yeah.

C

Yeah, if it's only specific to gce and it's it is installing the proxy itself and that's like a test image, that's not a thing that we run generally. Then it seems like we're testing a test image which doesn't seem that useful.

A

Okay, um I will take an ai to recommend that we drop this or just drop it.

A

E

What is this in general? What is the status of like platform-specific stuff like this, because I know there's an effort to get all of this out of tree anyways right.

A

I think effort I don't know uh there has been an effort for the past three years.

E

A

A

Somebody has to spend a lot of time to detangle the test infrastructure um from gce at this point um in.

C

General, we want these tests to be testing open source things so.

E

Right a test should be exercising.

C

The components that get shipped with the kubernetes release now, if some of those components are extension, points- and there are particular implementations connecting to those extension points, it's fine to have tests demonstrating that. But ideally the thing we want to be testing is the extension point. So a stub or a test harness or compatibility.

E

C

E

Think gce, I don't think metadata consumer falls into that, at least from my knowledge of how it's set up. It's like its own, totally separate thing. So it's only.

F

E

Need this test, if, like kubernetes, is shipping and supporting gce support right? If not, there's no need.

A

C

A

C

A

C

uh Awesome we'll try to follow up on those our idc issues as well.

A

Enjoy everyone, I think we're almost done uh with these anyway I'll I'll finish the last two offline. uh Thank you, everyone for joining sigath today, I will see all of you in two weeks.

A