Kubernetes SIG Auth, 22 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

SIG-Auth Bi-Weekly Meeting for 20220622

A

Hey everyone: this is the sig off meeting for june 22nd.

A

uh See tomorrow, is enhancements freeze for week 125., uh so we're just going to go over some of the open she got kept so make sure we get those in so like you, and I reviewed this. I think this one is relatively fine. I just have basically one open question, which is, I know, david's not here, but it's basically.

A

This is not. We are proposing this to not be part of conformance and as such we want to be able to turn it off, and I said that turning it off using the runtime config seems impractical, because you would turn off the entire authentication group doesn't sound like a good idea on any cluster you care about.

A

You can disable using runtime config down to the resource level. You can.

B

Because I was staring at the.

A

Code- and I was like this does not look like it- supports.

B

Resource david added that as part of disabling beta apis by default.

A

Okay, so that okay, so all right, so that just that just means this part needs to be updated to the whatever the syntax is for disabling. A particular resource was that that relatively recent.

B

Yes, uh it was added in 120 or 124 124. Probably 124 is when we said that new beta apis would not be on by default, and part of that was needing resource level control over enablement and disablement. So, if they're not on by default, then you need to be able to turn on a particular api. I see the comments. um What version was that on, because I'm pretty sure that capability was only added in 124.

A

Oh yeah, so that's why max you're you're on an older, older cluster, so it didn't support that syntax and I I didn't read too deeply into the implementation of runtime config. But my initial.

B

A

Because your eyes will bleed yeah, it didn't look fun and I was like I don't really understand what this monster does, but, okay, so all right so max. I think we just need to figure out the syntax for exactly disabling this particular resource. I assume it's group and resource right, not like version. It doesn't include also a version now. It's group slash version, slash resource all right, we're wonderful.

B

So we'll just have.

A

To figure out the incantation- and I think you could probably drop the whole bit about uh a validating web book- I don't think we would recommend you do that um if, if there is a specific syntax for this, uh so I think that was my only open thing on this one. Otherwise I think.

A

David did not back it from prr, but I don't think he had anything else either because he basically said hey mike and well. Go read this and tell me if it's good.

A

Mike did you have anything else on this.

C

um No, it looked fine, okay,.

A

Cool, so I'm going to say max if you fix that one bit up would be will be good and implementable in 125..

A

So that's good.

A

Is to hear here.

C

um I think he's out this week, um but I I would say, let's go over it as well. Yeah.

A

um So I did watch the recording from last time um and I thought about the whole work revocation thing, and I think I generally agree with what you all were saying last time.

A

I think the only question I had about the revocation stuff is: if we build some- or we presumably will have to add some code into client, go for using this resource and you know having trust based off of it. Would we want to build within that the capability of looking at those extensions for like the ocsb, urls and stuff?

A

So that way, if you were using our code, you've got sort of that for free, like I, I don't think the client side aspect of this is discussed much in the cap, it's more of just about the server side. This was kind of a question I had.

A

How was it what you mean by built in uh so like? I think what we're saying is that uh if you want revocation, that's cool use, one of the existing extensions within x509 that lets you do that.

A

All I was saying there is, that seems, okay, but will we provide any like code? That does that? For you already in clanco, basically like if you, if you want to you, know if you're a a go project and you you want to consume one of these things, would we help you do that.

C

um I would probably lean towards no, unless we start using it, maybe in the pr like uh printer, keep control printer or something to add introspection, support.

A

Yeah- let's see other things I had uh so I I think I generally like the design- that's here now with just having a dedicated feel for respect designer name and just using admission to enforce it. um It is a little bit strange to me that it's optional, but I I get why I I think the use case is fine, which is just to have ca, bundles that are not attached to a specific signer in the sense of those kubernetes liner.

A

So I think mike you had said that you did not want to direct binding.

A

um I guess I'd ask why what's what's the concern, what you mean a direct binding for our back for system authenticated, so I I think you had said that you want create pod to sort of indirectly give you access to this um one of the side effects of having the name name name of both the object and the sets within it be just strings that somebody came up with. Is that they're kind of hard to discover?

A

So I was just trying to think of ways to make it so that one could do that, and if the information is meant to be public on the cluster itself, and if we added like field selector support for the designer name like it would it would be really nice to be able to just be like hey, keep cto get. You know, cluster trust bundle, field, selector designer name that one and you'll be like all right, cool. Here's, here's the stuff on this cluster, and I can I'm configuring my pods. I know what to do.

C

Right, I guess what does that have to do with that, our back, binding or well? It's.

A

Without an r back binding there, it's that's not universally going to work right, like somebody would have to set up the cluster in that way. To give you access.

D

I mean having a default, our back binding that allows anyone authenticated to view seems like the right option. How exactly it is expressed. Is you know not really an issue right.

A

Basically, I I I get the sense I got from the cap was that we're, okay, with an indirect implication, on being able to read all the data in this api and I'm like. Can we just then just make it direct so that way, the names are less magical like the names of the um that's within them.

C

I so like imagine a situation where you have.

C

You're running, like a builder or something where you have maybe um a bunch of tenants that are running like builds in containers, for um I don't know, building a website or running like I guess, hugo or something in that situation. You like you at runtime. You don't want the tenants to have access to the read arbitrary data about the cluster.

C

What you really want is um the runtime to be isolated. So I guess there's a distinction between like authorship of the podspec that and like the running pod, which I think is important.

A

C

A

Running the pod, without a service account then like, if you don't want them to be able to poke into the cluster.

C

Yeah, I guess you would not auto mount the token would be a better approach there, um but I just think that there's a distinction between like authorship and runtime. That is important. I would not like all authenticated to have access to uh clustered trust, bundles.

D

Okay, it's not it's not inherent it's just the explicit default like it need. There's nothing that says, cut that cluster administrators can't remove that role binding if it's in the defaults.

B

uh We shouldn't well, we shouldn't make default role bindings. If there's a plausible reason, people would need to remove those. We should.

D

B

Be creating default role bindings that were basically sure could be universal.

A

And that is the general stance we've taken with the default so far is to make it so that needing to pat stuff out of it is possible because that's supported within the reconcile loop.

A

But it's supposed to be exceptional, because it's kind of annoying and puts you in this weird state, because your back no longer gets reconciled, which is kind of against the point of our back reconciliation in the first place, um would would with a approach like we took for the oidc discovery stuff, be more amicable where we bind it to system phone service accounts.

A

That way, I could at least I could at least impersonate a service account and then read it myself. Instead of having to make a pod.

C

That would be better, although I don't.

C

I would defer that until there's like a real need for it, um because, like we intend for service account- or I guess things running on the cluster- to consume this via volumes, um I guess it would be.

A

How do I know what to put in my volume spec, because now all the things are magic, there's two magic strings inside my volume spec now the name of the cluster trust bundle and the set within it, which I have to somehow just be told. Now.

D

The the cluster administrator is responsible for distributing that to their users.

A

Yeah, isn't that always going to be you're always going to have to yeah, but the original design was. I had to know one string, which was the name of the signer. Now I have to know two strings that are actually unrelated to the signer.

A

Like I think the api is expressed better and is less magical in the sense of the name, isn't like weirdly deterministic, based on some algorithm on the designer name, but like like. I I'm trying to think of like myself installing something into a cluster using tooling and would like to make it somewhat more automatic. Instead of having to know magic strings.

E

Are you suggesting that there should be like a default like association of your trust, anchor sets with signers, or something like that? So I I still just as a user need to specify the signer I want and then maybe I can override the default if I really want, but otherwise I just get like what the signer gives me or what that association is.

D

Most clusters want a default system. Authenticated can view these. It's not as if you can't they're, not innumerable by just creating a bunch of pods with you know, likely signer name, um you know creating pods with likely signer name mounts and trying to figure out if those exist.

A

Yeah, I was more just thinking in the sense of this sounds like public information for things that aren't on the cluster. So how do you express that and to meet that system.

D

I I personally think that trying to disguise it, even in the case of a you know, of a shared cluster trying to disguise that signers exist is the wrong approach.

D

um These are fundamentally public opinions, but I I do understand why people want to avoid that.

B

You, I think, there's a distinction too, between whether the information is considered private and whether we want to encourage like consuming that information via list watch like requests like if we, if we, I think the the continuum is probably start with the volume consumption via volumes, because that's the clearest use case, then if there was evidence that people were fetching it via the api, they can grant the permission to get the thing, the well-known names via the api themselves.

B

It's not like they're blocked from creating a deployment where a service account fetches it from the api. They can do that if there's evidence that that's a generally useful thing, I think the next step would be to grant get access on the particular well-known names that we have corresponding to the signers, because it's a lot easier for us to reason about like here are the kubernetes signers.

B

We can make judgments about whether those trust anchor sets are reasonable to consume. It's harder for us to make judgments about like how is every trust anchor set going to be consumed.

D

I would just put it in the docs. Here is how you add the permission like do we already have docs around permissions that your cluster probably should have but are not included, because somebody might not want to have them.

D

We have docs on nearly every pod that runs anywhere. Sane has a the pot anti-affinity right, um that's just in the docks. Maybe we just add this to the using cluster role binding stocks to create this, where cluster trust, binding stocks create this role binding, so that people can actually list which signers exist.

B

I mean if yeah we, we should document the ways to consume it. If we expect volume consumption to be the normal one, then we should document that and then say: if you want to pull from the api, here's how you can grant that permission. That seems perfectly.

D

Reasonable yeah, I think that's how we phrase it in the docs is you should tell your users here, but if you want to give them the ability to list which signers have trust bundles available, here's how you do so.

A

A

um Okay, I think that's fine, um I I I'm not gonna necessarily push on this one too hard. I just was I leaned towards making the thing more useful from a default standpoint.

A

One of the things that tier has in here is our back associated with being it our back. That is enforced via admission, that is, for a similar, signer name restriction, and I was trying to come up with a verb to describe what it means to control a signer name on one of these objects.

A

So far, I came up with the word and trust, which I don't necessarily think is exactly the right word. It's kind of vaguely close to what I want as an example. The word sign and approve are the other two existing verbs we have.

A

um Does anybody have some good suggestions for being able to set a signing name.

A

I'm not sure if there's a word that describes this concept.

B

And I do I I miss the the details of this bit. This is basically checking something similar to csrs. So before you sign or approve a csr for signer name, you have to have specific permission for that signer name. This is something similar for the trust anchor sets.

A

Yeah, so you need general update on a cluster, whatever bundle in our back to be able to issue the update at all. But then, if that object has a signer name defined, which is immutable one set um you must.

A

You must have this extra permission to be allowed to update that specific signer uh in the in the kept here was like, I think, writing it out, like as a full like crud style echo, and I was like I'm not sure why you would do that. I just said you would you would just use a custom word like we did for the other thing, mostly because all the code already exists, um uh and so I was trying to come up with a verb that described the act of creating slash, updating, a a bundle, update, bundle.

A

That's not really a verb uh but sure that that that that could be okay. It could be okay,.

B

um I'm okay with describing the mechanism and.

D

B

Deferring the particular name to the implementation say like here are the ideas, something along these lines: yeah.

A

Okay, I think we can leave it. That's fine as long as we get the mechanism that actually matches the other one. I think I'd be happy as well.

A

uh Let's see this one is basically they have a discriminate. A field like a one of api in the volume thing, I'm like pretty sure, say, api machinery is all in on discriminators and you need to have a discriminator, even if you don't have a thing right now that needs a discriminator.

A

uh I think uh that covers most of the stuff there I think two high-level stuff I had is. I don't think we have a pr on this and I think we need one because this is like I I have concerns around like performance of this. This thing I I don't. I don't fully understand exactly how much work the cuba is going to be doing to keep all these up to date, especially if you have a large amount of pods using it.

B

Does this go into discussions about updates to the content while a pod is running.

A

Yeah, it says that the qubit will keep it up to date, and I one of the questions I asked is all like: how often does it do that uh and just in general I don't there's like no metrics and stuff discussed, so I don't. I don't know how, like an admin, would understand how much cpu this is basically consuming across their cluster or anything like that.

A

So I do think we want to have at least some amount of resolution there and since david is out, I don't know who I think john and wojtek are the other two prr folks. So what.

D

Metric do we already have on config maps, because we should mirror as much as possible metrics on config maps.

A

I'm not sure if configmaps is a good target, because config maps are really old, so they predate our prr process, meaning they don't necessarily reflect what we would do today, uh but in.

B

Terms of like visibility to performance, I mean config maps and secrets did cause performance issues and the scalability team did a fair amount of work to try to improve that, and even added things like immutable, config maps and secrets. So you can flag things that shouldn't change so that people who hit specific problems could dig themselves out of holes by markings as unchangeable to stop the cuban doing work on this.

A

Yeah that to me sounds like a really bad bandage.

A

I mean it works. I understand what it's doing.

B

You're going to run 100, 000 pods, maybe don't mount tokens in and mark your secrets as immutable like there are things you gotta cut off to get the scale targets you want so at least having the options are better than not.

A

Yeah, um but so what should we do in our cpr for this? Because I don't, I don't think we can merge this without that right.

C

Yeah, I think, there's a lot that still needs, so I have not commented on the kept about this yet, but I think the api is needs a fair amount of work. I'm kind of confused by the complexity, um specifically like multiple non-default trust anchor sets in a cluster bundle. I don't understand why there's one does anybody here know, or should we wait for it to hear for something like that.

A

I don't think I've understood the question.

C

Cluster trust bundle has a status, and it is a trust, anchor sets uh which contains multiple. What, but, like essentially bundles of certificates,.

D

Right, the intent is that eventually- and this is this- is very much a google alt use case first and foremost, the intent is that eventually, you will be able to say for this bundle for this particular. You know group, um you use you use this ca bundle for this other group. You use a different ca bundle where there are multiple ca. Bundles that are, there are multiple ca, bundles contained within one cluster trust bundle um separated out.

D

I I don't think that that's the right approach to this api, but that is how um how it was explained to me.

A

Why would you not use different signers? Sorry, I think I could document because alts.

D

Wants to have wants to make use of sub signers in a way that is.

D

Is very sensible but doesn't actually work in x509.

C

I think again, so that is a very opinionated uh response to this. I don't think we can do this question justice without both sides right, I absolutely agree I'll just I'll. Just for that question I think the other one is uh the um actually. I have two more comments on the api. The other one is. This: has a status with conditions um uh similar apis for projected volumes. Data distribution do not have conditions.

C

I am not sure about the value of that. It says the documentation says ready when designer uh for the signer to indicate to the cubelet that the cluster trust bundle object is up to date. I don't uh get that because.

C

When it goes stale, why don't? Why doesn't the signer just update, updated, not sure if there's value in it status, field here and then I think the final confusing point about this api is the actual um uh trust anchors projection has files trust, ankle, anchor, set file and flat file um types there's, and I it I'm wondering if we can simplify this a bit.

C

For actually how we reference these trust anchor sets from pod specs.

C

Because it this seems flexible, but not very intuitive and much more complex than.

C

What we have for other projected um volume types.

A

So certainly I think you could you could get rid of this slice right. You could just say that there can only be one because you can have more than one projection right. You just add more if you needed more than one and then this bit over here is the thing: that's missing the discriminator, because the idea is the reason for this being included is right.

A

Now it's just flat file, maybe someday we'd, add support for like a java key store, which I do not recommend, because but whatever I'm sure somebody can write the code to make a java keystore bingo, um but yeah it is a little bit flexible um while we're picking on the api.

A

One of the questions I had that I forgot to write is: if I decide to pick a kubernetes signer name, is that okay?

A

Can? I can I say that I forget the name of our signers, but one of our finers has this bundle is that all right seems seems not. Okay,.

A

Oh, what do you mean like the like the? I can't remember the name, but maybe jordan, you remember like the like the cluster hot signers, like we have four of them right that the the csr controller does they have specific designer names in our api? So if I was to go, make a bundle and just say hey by the way, this kubernetes signer, this is the ca bundle associated with it. Is that okay, I don't think it's okay, because it doesn't really make sense.

A

So I would either expect the api to just flat out reject that or there would be some mechanism for those to be reserved for.

B

Somehow I mean whatever mechanism: is it using this to distribute trust anchors for kubernetes signers seems plausible to me right um when you say like if I were to create an object?

B

Who are you if you're a cluster admin, then maybe this is how you're populating the trust anchor sets for the kubernetes signers like uh if there's an authorization check around you know permission to populate for a particular designer name. Then I I haven't thought a lot about it, but you populating trust anchors for kubernetes signers in these objects doesn't offend me.

A

So what I'm hearing, though, is probably what we would ask, so this kept right now does not say anything about the controller manager, but maybe it should maybe it should have some mechanism that tells the controller manager hey you're, passed in the ca bundle for all these things. I think at least some of them you, you should go populate objects in the api that match it, because that's where we expect people to actually consume it. Now you have an api.

B

It seems plausible that our signer would reconcile the ca bundles.

B

um We need to be careful that so the signer is given a singular certificate to sign with um that doesn't mean that that is the full bundle, uh especially in rotation cases or aj cases. So um I I think it's worth mentioning and discussing like how does this interact with the kubernetes signers? Are we going to create objects that hold the bundles for the community designers, which components going to do that how's it going to do that? How do we handle rotation cases like right now?

B

The api server is the one who is given the full bundle of acceptable uh client cas so uh that, but that's not universal, like the api server, isn't the one that's verifying all of the certificates for all of the kubernetes designers. It knows about the client cas, but that's about it, maybe not sure anyway. I I think that's that should be mentioned and clarified and discussed and say like.

B

Are we going to create objects? Are we not if we are where and how and what's the expectation there.

A

Good, uh so I think what I'm hearing, though, is, I think, ted you had some comments. I would ask you to write those as a comment in the chat. I think mike you did too and I'll take the one about describing that well, the built-in signers probably should should do something with with their own bundles and this somehow uh so, but I think what I'm hearing is that this is not ready for 125 and I think that's okay just but do you folks agree with that?

A

I'm going to move it out of the milestone to indicate that.

C

A

uh So I I'll, I think I don't remember. I don't think this is in the kept tracking sheet anyway. So I think that part is okay. um Okay, is there anything else folks want to discuss on this? We have 20 minutes and we still have at least one more thing.

A

Okay, so the next one is uh mike or jordan. Have you either one you've read this one any chance or rita have any of y'all.

B

Read this I opened the link that you sent me to the comments that you made and other than that I had not.

A

It's okay! Well, that is like my biggest uh confusion on this, which is so all right. So uh the high level of this proposal is to allow for a fully structured configuration cli pass it with the cli flag to the api server. That.

A

When the feature flag is enabled is mutually exclusive, with the existing authorization cli flag in particular, it lets you specify as many web hooks authorization web books as you want, and then it also lets you specify in which order they go into with the like the node authorizer and the rbac authorizer, and that type of stuff.

A

One specific thing that david has asked for is: I want to be able to deny system going masters, so I want that to be represented in this chain, so I may order it appropriately, as in I might want to put a deny authorizer in front of it and while I believe that is technically possible, I don't think it actually works, because I think this group name system called masters- has sort of leaked out of our code base and is embedded in many external consumers as a thing that is always allowed to do all the things.

A

So I'm not sure if we can realistically enforce any constraints on this group anymore.

B

We're not just out of our code base, but even things built from our code base running in a distributed way like aggregated api servers.

A

Right so yeah that I pointed out that, like the delegate authorization options just hardcode this as a thing that is like always allowed because it's supposed to be within our code base, our back just says: if you have this group you're allowed to do anything on our back.

A

um So I mean like this. One is fixable, I guess, but this one is not. I think, um but but like I feel like somewhere in here, david said that they carried a patch and openshift to make this work. So now I'm like real confused. I'm like what work. I don't think it works at all david.

B

Yeah I mean being able to define multiple web books and order them relative to other configurable authorization.

B

Authorizers um seems reasonable and plausible and useful right. It seems like what david's asking for which is. I want to take the you know, always on first in the chain, super user authorizer and move where it happens in the chain. That seems like a distinct feature, request thing with its own considerations, and if we allowed that to be movable, then it could be ordered uh along with other authorizers in this. So I I think this is independent of what david described about subjecting the super user group to web hook. Authorization.

A

um Okay, that's my 10 second take on it, yeah no yeah! I I can. I can see it. I I'm just not sure I I I think I'm just stuck on the. I just don't think what david is asking for is technically feasible uh within an ecosystem.

A

uh It's I think it's enforceable just within our code base at a point in time, but not anything further, and I don't think we would be satisfied with that enforcement.

B

uh Maybe I mean authorization runs before anything else gets a crack at the request and anything else that is doing authorization checks would be using like subject. Access review would enforce it and things that are using their own authorization. Logic maybe are already off in the weeds, like we have a hard time making any sort of guarantee about things that have built their own isolated authorization, checks right.

A

So but like, for example, I I have servers that I have written myself that are based off of kids io, slash api server, that delegate back to the api server, but they, but they are hard coded with a check right now. That says, if presented with an identity in this group, don't bother delegating because that's just a waste of a network.

B

Yeah, I I think those would be the questions we would ask in a separate cap that was trying to order the super user authorizer, but I don't think that is blocking for this. Okay.

A

That's mine uh all right, I'm less sure what to do with this kept now, because david has asked for this pretty explicitly. So I'm not like yeah. Okay, that's a further conversation to have.

B

If we scope this to define multiple web hooks and allow ordering the multiple web hook, authorizers that that doesn't cut us off from in the future, letting you order the privileged authorizer in that set explicitly, instead of it implicitly going at the beginning, like it does today,.

A

um Okay, uh the was someone just trying to say something.

B

And I'm happy to jump in and comment on that aspect.

A

Yeah, um I kind of remember one of the things I had uh well. One thing I had asked for which I believe is not possible, is so right now, there's no way to pre-filter any pre-filter, any web hook from being invoked, uh um but so the reason I would want this is.

A

I would like to be able to self-host an authorizer that is, that is at the very top of the chain that is allowed to do denies, and I can't think of any way to do that that doesn't break everything that I mean unless it can't filter out like systems.

B

What are you, what do you? What kind of filtering do you mean.

A

The ability so I like to take a very specific check, a specific example. If jordan, if you remember how the openshift scopes authorizer is implemented, it only acts on requests that have a particular extra field, because it knows that the authentic the crew, the openshift off stack, was the one that actually did the authentication and not like the kubernetes code.

A

So that's kind of the filter. I would like to be able to express is if a resource or a user looks like this, then, and only then invoke this web book, otherwise skip it entirely.

A

So that way I could have at the very top of my chain a self-hosted deny authorizer, but no, it's not going to like completely destroy the cluster. If that component is offline right now, it's real easy to make a circle.

A

As described here, um actually I think what's described here basically says you cannot self-host the authorizer, because it's just not it's just not safe.

A

Just come here.

B

Yeah, that seems useful. I don't know how strongly we should hold that as a requirement for like get being able to define multiple web hooks and being able to make them struck like a structured config, for it seems useful. The filtering aspect is a lot easier to do. It's like possible to do once you have an actual config, so um I just don't have a sense for how much time or complexity that would add.

B

I wouldn't want to delay the ability to have multiple of them and having like a real config format, uh I wouldn't want to delay it just.

A

Right, so if we want this to land in 125, if we scoped at least the alpha of it down to just just basically structured config for yeah yeah, structured config, with a explicit ordering.

A

Oh, that does leave one question. So one one one thing that's a little bit unclear in this doc is the exact. um Let me find a second.

A

So, like weirdly, it still has a cube, config path in there, but also this um and this. So it's it's just I. I think this is a typo. I think they meant to delete this and forgot to delete it based on some of the comments I've seen, um but the the gist of what I had asked. It is to not continue to use the cube config format as a way of specifying what the web book is and instead like specify the.

C

Url you want and the.

A

Harder part about that is in how do you specify auth, because we have exec art? We have oil dcr.

B

Yeah, I'm not eager to basically duplicate all those server config fields from cube, config.

A

Yeah um yeah, I'm also not happy by using that file structure. It doesn't.

D

A

Make sense it's not like what it's supposed to be for.

A

A

Yeah, like that, that part's less clear to me like I, I honestly would rather just start with like uh you get exec off. So if you want to find you can host a plugin, so, like no authors like then at least you get cert and tokens. If you want, because your exec, odd plugin could literally be echo or token if you wanted so like technically it does, it basically does all the things.

B

uh Making someone shell out to a command to get a token is abusive. I.

A

Know I know it is, but at the same time I I don't necessarily want to yeah like I.

A

What should we do here should be basically have within the authentications substructing this api, a discriminator that says what type of art they're trying to do and then let you fill it out.

B

I don't I don't know uh the reference cube, config files from other structured config, like admission configuration.

B

A

B

Have a good answer right off the bat I'm? Maybe I'm not as offended by referencing and keeping big as you are, uh I'm also thinking of people who are using webhook today and like how how do they get from where they are today to um this it's way easier if it's basically translating their flags into.

B

Stanza and then copy pasting that stanza and tweaking the one thing they want a different like ordering it differently. um So is it what we would make if we were starting from scratch seven years ago, maybe not, but is it bad to like? Have it be coherent with the flag version? I don't know.

B

I'll leave my comment about the super user. Authorizer order requested being independent.

A

Would it be the end of the world if we had the basically the same config structures that are in the cube config today in this api, just the audio parts that makes.

B

This be a sensitive file, broken, which I don't want yeah. I like the fact that the credential aspects are not inlined here, that's true! No, uh that's the only specific thought I had about that.

A

Yeah, I don't know if I don't have a good answer on this- this one's really ugly but yeah the ass, the aspect of having secrets in a config file. I do agree with that. I don't want that because I just I just don't want secrets in there uh and that is where the credential plug-ins help.

A

Then the secret isn't in the config file.

A

But that's not true of tokens.

A

I can't hear you anymore.

B

Jordan, this is me uh another possibility. I did mute myself. Another possibility is to inline the server stanza and the user stanza in this type and forbid the credential containing fields. So, instead of token you would have to say token file and like point to a file uh and then like.

D

Under the covers, we.

B

Can take that and take the server stands and the user stanza and dump them into an in-memory basically make an mreq config, and then we can use all the same client, config construction like it's. We just translate that internally. So that saves us from like a config file, referencing a config file for sort of simple cases where they don't need to specify credentials and they don't need to specify a bunch of stuff. I don't know I like. I said, I'm not that offended by basically just translating the flags we have into a snippet.

B

I think that's easy to understand for people who are currently using it.

B

And it's it matches what we do for other admission, config files- I don't know.

B

I do have to drop them. Sorry.

A

uh Do we feel like this is ready, or should we just wait till 126, because we are kind of out of time.

C

B

Don't feel qualified to judge, but I mean you've looked at it more david's, looked at it more uh david had a short list of things and one of those things I don't think is you should be addressed as part of this. I don't know. Maybe it's ready.

C

Mike what were you saying? I I don't think I heard I. I think this was kind of a late comer. I've not looked at it 13 days ago, so we, this wasn't even up last sig off. I think this would be a rush to get in um it freezes this thursday, it's tomorrow tomorrow, yeah.

A

Yeah I mean I'm okay, if we just decide that the runway is too short because, like like you know like max, is kept, we talked about like three different times and then it was basically just right. They kept this one. We talked about a very long time ago. I think, but there's like a many month gap between a conversation and an actual cat.

C

Right, um if you think it's really close, I can give it a review tonight.

A

The the cube config stuff makes me a little unsure, but if you want to look at it, uh I guess what I'd ask is, if you have time between now and freeze, look at it. If you feel that strongly enough to say that you think it's ready, then then we can pursue it. Otherwise, I'm okay, if if it slips- and we just take more time on it, because sigoth has like well seven kept being tracked right now for 125, so I think we are pretty well committed.

A

That's not fair.

C

That sounds good.

A

Okay, cool! uh Well, we have like 20 seconds after the meeting, so I'm gonna say that's. That's the meaning.

A

All right, y'all, uh we'll see you in two weeks.

A