Kubernetes SIG Auth, 1 Feb 2023

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

sig-auth bi-weekly meeting for 20230201

A

Hey everyone: this is the cigarth meeting for February 1st 2023.. uh We got a few items on the agenda, so I guess we can get started. Let's see, I, don't see any announcements all right, so we can get to discussions.

A

um So the first item- let's see dirt and I- know I discussed this with you and passing.

A

um I wanted to ask folks here just to make sure we were sort of on the right path.

A

um So nalek was looking into implementing uh Wild Card support for the encryption configuration which today just takes a string that represents a resource and parses it into group and resource, and just does pure string matching, but, as you can imagine, it wouldn't be necessarily hard to put some wild cards in there.

A

uh So, like initially I had wanted to support stuff like you can encrypt every resource within a group uh just because that sounded kind of nice um uh and also wanted to support like encrypt a bunch of stuff, but not some other stuff. That's like overlapping um the way the encryption config is structured.

A

It's really painful and hard to try to like come up with a strategy that results in a thing that the user would understand that they did right basically like, because you can specify providers at multiple levels and you can provide resources at multiple levels and you could have overlaps sort of arbitrarily um right. Like you. If you supported group wild cards, you could be like talking about like the core group or some other group, and then you could have start.star, meaning everything um as a starting point.

A

At least we were going to just maybe try, starting with. um If you do star star, you just can't specify anything else, so we basically get their Crypt all or nothing kind of deal, and maybe we could figure out a way to make it less. Meh, um like you, know, reduced a strictness of the validation over time.

B

So the uh the config file it the matching, goes into order right, like the config file, says here's what I want to encrypt and when it's looking up how to encrypt a particular resource. It starts at the top and goes through item by item until it finds an item whose resources list match that type of resource and says I have found the config for this resource, and then it looks at the providers for that entry and says that's what I'm going to use. Is that not.

A

B

A

uh Yeah, it's it because it needs to know like what provider is going to be used for encryption versus all the providers that may be used for decryption.

B

Okay um from a user perspective, if I can look at the file and a particular resource and start at the top and say the first entry that matches this resource, like this blob will control how it'll be encrypted as a user experience, that seems, I can explain that I can document that.

A

B

Just like today we don't support star star, um but if we added support for star star- and so you could say, things like I want to do a particular thing with secrets and then the next thing I want to have star star match some other configuration like I I can explain that to someone and say, like you start at the top and the first entry that matches your resources, what we use for the config does that seem like a.

A

Yes and I should have done a better job of writing, nonsense examples of configs that we as we went through this exercise and we're like yeah, let's just write out a bunch of configs and see what we think they should do. It was it. It wasn't. Super super obvious what was going to happen.

B

um I'm I'm happy with the goal of letting someone say: I want to encrypt everything, um yeah I think start if it starts at the top and goes down on the first match controls what gets used. That's probably the most reasonable outcome. I, don't know what that looks like momentation wise. What.

A

B

A

uh Yeah I think go ahead. I'll.

C

Just say, I think it's worth uh noting that going in order does allow essentially the negative matching that you express, because you can choose your selective thing. First, it would be consistent with selecting a group and one of the reasons why we don't support it in in the rest,.

D

C

That we normally have like uh our back doesn't do. This is because they don't have the same sort of consistent ordering uh I. Think I can only think of a few examples where we said we're going to order by name and go in order, um and that might even have just been openshift apis. So going in order seems like a good option to me to get the thing that you want without having to build out a full here's. How you express priority when you have multiple matches.

A

Okay, so if someone put in their first configuration star.star and then the second one Secrets, the second one is just ignored.

C

um Yes, because nothing would hit it.

A

Right, um okay, oh man, we have to write rewrite the whole parser. It just doesn't do this right and I just it. It makes the Assumption today that it can do purely string based structure building and now you have strings that mean more than one thing. Basically, so it has to be smarter than what it is today.

A

Okay yeah, so, if, if it's just purely looking down and we have to yeah I think we can make it work if we just rewrote the parser to do it in that way um like like, basically right now, I think it tries to flatten the list all the way down and I think it just needs to not do that to make that work. Yeah.

B

That makes sense, um I, Someone, putting star star and then later putting secrets. That seems like something we could probably like catch and maybe disallow, because it seems like an error.

B

um So if we can catch or warn or disallow later things that are totally masked by earlier things, that would be nice to do if we're in there.

A

uh So what if you did like I forget I, always forget which order it is it's resource.groups. So if you did star.food group, but then you also did like bar.food group, that's also an error because the star is going to match I.

C

Would let you be as nice as you want it to be yep.

A

I I, don't what do you mean? David distribution.

C

But if you wrote it I would say sure: let's do that. Yeah.

E

Okay: okay, all right.

A

um All right cool all right so now like now, we have a lot of extra work to go. Do to write rewrite that person yep.

F

Yeah I think I think the flatten out thing I will have to figure I mean we do have order in the beginning, but then we just say that nope, we are just throw away that order, and here is the map and we're just gonna pick the Transformer from there. But I guess we'll have to think about that up. First then,.

A

Yeah I think we yeah um yeah I, think we have to I think we have to not let it get all the way flat. Basically, I think we have to keep some of the structure around all.

F

E

A

Okay, all right! Well, that tells me what I need to know for that. uh Anyone else have any comments on this before we have a probably very long conversation with Rob.

A

All right cool, uh so has everyone had a chance to read this cap? That cares about this topic.

A

I know Jordan, you read it a bunch because you made a bunch of comments. uh David did you have a chance to look at it.

C

uh Not in detail I think this came up before uh wouldn't mind say a two minute summary, particularly around permissions.

C

A

Yeah rob you want to take that.

G

Yeah sure uh so, reference Grant the entire idea that this came from Gateway API we've discussed it two times previously at cigar, so it should be familiar, at least at a high level. uh We had two specific things we were trying to enable uh one of them was cross namespace references to TLS certificates so that a Gateway or a load balancer could have a TLS certificate attached in another namespace uh and then the other one was cross, namespace forwarding.

G

So the idea that a load balancer could forward traffic to a back end a service in another namespace.

G

um In both cases, we we wanted to enable a you know, a cross, namespace reference and have a handshake on the other side. So the reference Grant sits on the other side on the receiving side and says I trust references from this other kind of resource in this other namespace to reference me- and this was well defined. At least we thought it was well defined within Gateway API and when we initially brought us to sigot, the idea was, let's start in Gateway API.

G

It meets your use case, it's reasonably sensible and if others have a similar need, we can discuss more at that point. uh More recently, Sig storage started using the same resource and that kind of has forced the issue of. We should probably try and find a a more natural neutral home for all of this, uh and that has brought up more broader questions about.

G

How do you take this resource that had two very clear purposes to begin with, and uh you know known use cases and make it something that is sufficiently generic, that it could work for a future unknown use cases. uh That's where we're at now I. You specifically asked about access, control, I, think or authorization. uh One of the things that Jordan mentioned in the cap that's currently unresolved is.

G

It would be very helpful to have some kind of requirement that the person creating the reference Grant resource, that's allowing the access allowing the reference to occur uh actually has either read or write access to the the resource they're allowing to be referenced. That because reference Grant today is only a crd, that's not done, but that does seem at least theoretically plausible. As part of this, I can answer any any follow-up questions, but hopefully that's a good intro.

C

Yeah uh and and then for my memory as I recall discussing this a while back might have been a year ago. um This didn't do anything on its own, so this was a way to express intent, but didn't actually Grant permit, didn't actually Grant read permissions, for instance. That would be something that would have been built on top. If you have a reference, Grant and I have accepted it, then maybe another controller grants read access to a thing.

A

C

G

That's a very important detail. Thank you. uh This this whole process assumes that uh it is being implemented by some something that has broader access. uh So the most common thing is, you know, Gateway API I think we have around 19 different controllers right now and I have some different implementations uh and all of them would Implement reference Grant. uh This is runtime verification, so the idea is that uh not only does it Grant, but also if the grant has been removed, revocation needs to happen uh and before I forget I should also mention.

G

Shane is also on. This call he's also a Gateway API maintainer and he can jump in if he has anything to to add or uh editing point, but.

C

Thanks I think that's, like my my background. I think I'm caught back up thanks.

A

So um I I have a lot of open questions, uh one that I forgot to write down, which probably is the most critical one um is so Rob so I know, Gateway API is using this, and something in storage land is also using. This um are in general. Are we comfortable with the idea of like codifying cross namespace interactions?

A

I mean it sounds.

E

Like we are because we already have two places that.

A

Are doing it, and so it's like it's not like you can go back and undo it uh yeah.

G

Yeah I think I think it's provided significant value and in my opinion, but it is certainly a stretch to say we have provided this for now. Three very clear, well-defined use cases to we're, providing a generic means to do this for potentially anything in the future. I I understand. That is a stretch um that we need to be cautious. What.

B

The thing that I've I've been sort of doing on um there are two uh aspects like if this is wildly successful and we're like oh cross next week, sharing is cool.

B

um There are two aspects of this approach that I'm trying to think. If we'll be happy with one is that, um if reference, if a common reference, Grant object, starts getting used by lots of different people for lots of different apis um in order for the controllers who are going to honor it to use it, they have to have basically Global visibility to all reference. Grant objects.

B

Is that like when it was just for Gateway API? If this was just the Gateway API reference Grant, then it makes total sense that the Gateway controller can see all instances of this object. um Will we be happy with all controllers of maybe varying permission levels having global visibility to all cross namespace granted information?

B

So if I want to give access to a TLS secret to the Gateway API, you know my homegrown controller, that's like doing some custom resource cross, namespace Grant is going to know about my TLS secret name and existence and namespace and consuming namespaces. That's one question.

B

um The second question is uh what you described earlier: Rob about like we're, counting on controllers to basically already have access to the objects and self limit, consumption of them or or access to them um for things that are scoped to a particular type like the Gateway controller. Having access to all Gateway resources again makes total sense if I'm going to share a TLS secret from one namespace to another. Namespace I wouldn't really want the Gateway controller. Having global secret read access to all secrets that exist, and so are we encouraging people to?

B

Basically, give Global read access to objects and then say, but no no, it's cool. We had a reference, Grant um they're, going to limit themselves right right right, so those are the yeah. Those are the two questions like by making it a general thing: I'm, just anticipating controllers that install with like get all secrets and get all reference grants and they're like, but that's cool, because we're using this library to limit ourselves.

G

Yeah, no, no, that's completely fair and uh we we're definitely we've definitely seen cases where Ingress controllers, and certainly in the future Gateway controllers, have uh you know they sit on the front right, and so, if they sit on the front and also happen to have access to all secrets in the cluster, it's a it's a scary thing.

G

G

A lot of our inspiration for reference, Grant uh came from contour and what uh Contour did is they really tried to encourage deployments uh to keep all their TLS certs in one specific namespace reference Grant enables that uh it is just one of many patterns you could use, but it is a pattern that I think is better than default, but not well documented, but I, but I think reference Grant can be used in a good way. I I know talking with the mo I think earlier.

G

You moan suggested something like we could have a custom authorizer which maybe what you're getting at as well Jordan, I I, don't know how that would work. It may be amazing, but that's outside of my area of expertise, yeah.

B

I, don't know either I I think the difficulty is the user, creating the reference Grant saying it's fine for Gateway objects to use this secret.

B

They don't even know the identity of the controller that needs to have read access to the secret like that information isn't available to that user um like ideally, those two things could have happened at the same time, like the user could say it's okay for this secret to be used by gateways in this namespace, and also here's read access to the secret to the controller, who needs to actuate that, but they don't have that information and controller identities aren't really an API that we've like at that point.

B

The controller username becomes an API which is kind of crazy, so I I don't have a particular solution in mind, I'm just trying to Stew on like what are we going to motivate people to do.

A

So so Rob on the I don't know what the term is like deployment topology of like having a namespace that I don't know my awesome TLS search namespace, uh where you put all your TLS search and then you give read access to your gateway controller to all secrets in just that namespace.

A

That sounds like at least something we should mention somewhere in the cap as like, at least a answer to the question of well. Even if you give access to read, even even though you need to give access to read a bunch of stuff, it doesn't necessarily mean that it has to be cluster-wide. You know you can constrain it with a careful deployment.

A

um I mean to George point. It would be really cool if you made a reference grant that somehow allowed the actor to also read the thing just by the reference. Grant existing that'd be real cool but I as as Jordan said, we don't know the identity. To give the read access to, or or whatever the access is, it might not be. Read might be right.

C

F

Saw you unmuted.

C

I did I was I was gonna ask how much better that is than just saying. If you have permission to read this thing, you can create a role in a role binding. That says other person. You can now read this thing, um but I guess I'm I'm more interested first in in knowing how does a user when they create a reference. Grant know which controller, if any is going to honor the reference grant that they have created like.

D

As a user, I have.

C

If I have this generic API, it's not obvious to me that I can use it generically and.

E

If I use it wrong, I don't know what feedback.

C

G

Yeah that that's entirely Fair uh in Gateway API, the only feedback at this point that we have provided is on the referring objects. So, for example, a Gateway referring to a TLS certificate. There would be an error present on the Gateway in status if these reference was not allowed uh they're in the cap itself. There is a question of if we should have some kind of status or feedback mechanism on reference Grant itself.

G

uh The concern of that so Gateway API left space for status, but did not Implement status uh and and I know that status May on its own not be a a good solution to this. But it is thus far the only thing that we've considered uh open to alternatives.

C

Even if we used status, what would fill in a status of I'm not doing a thing with this thing,.

G

uh So one of the proposals I mentioned not directly in the cat, but in a Converse, actually I- think it's in the cab now uh uh would be that status could be used uh as a kind of controller name uh and a pair of controller name, String, plus uh approximate number of uh resources. This resource has granted access to. So this reference Grant is currently providing access to this many references or for this I I'm, not exactly sure what that would be.

G

But an approximate order of magnitude of this controller is both watching this and also relying on it for X number of things.

C

And so it would be the absence of information in status that would indicate.

G

Yeah I mean that's any anytime. You have a a resource like this. At least this is what we found in Gateway API, that is implemented by multiple controllers.

G

uh Absence of status is really all you can rely on, because you can't there there's nothing that publishes the lack of implementation right, that there's no component that exists, that can say: hey like I'm, not implementing you. uh What we've relied on in Gateway API is. uh We have some defaults that are that show that nothing is currently implementing this and then a controller can pick it up and overwrite that uh but other than defaults. That's about all! We can rely on.

C

So so then, I'll I'll throw out like the counter example right. If this is a specific resource, if it is a gateway, API reference Grant and it's very clear who owns it, uh what a user could expect as a result um and in a way that the generic one does not is that is that actually a value add of having a specific type versus a generic type.

G

Yeah absolutely and I I think uh related to that is uh conversation somewhere in the cap on resolved right now of if we want verbs in reference Grant. uh So one of the concerns about reference Grant today is we've: we've kept it very tight and we've kept it defined to Gateway API use cases, and now this one Sig storage one.

G

uh But if you create a reference Grant and you attach two arbitrary things, how do you know what kind of reference you're enabling you know in reference Grant in Gateway, API we've, you know we we haven't had that issue yet, but if it becomes arbitrary, then you can imagine it would verbs help.

G

You know you can imagine a forward or forward traffic a verb that bad name, but something like that or a read cert or yeah I, don't know so it's various words like that that very clearly capture the intent and then I think that uh is is very close to what you're describing David of a Gateway specific. You know that this this grant is intended specifically for Gateway use cases uh I.

C

G

Know if that okay go.

C

Ahead I'll say: if mobile indulge me one more uh I guess my my next thought is: it sounds like you have created a powerful serialization right. The idea of a reference grant serialization that says this is how I can map like twos and froms uh and and maybe uh usage uh combined with them is- is useful in terms of being consistent. But do you actually need to apply the same serialization in two spots right in the two examples you have?

C

Is it actually better to have one for Gateway API here is where I store my reference, Grant kind uh and in the storage one I use the same kind, the same serialization and store it into a different resource so that when I list them I can say like I have the controllers. It solves the controller problem. Where you look and say: do I want to have permission to read all of these.

C

It solves a user problem uh of maybe people who are allowed to assign this grant to storage, aren't allowed to assign the same Grant Gateway API, uh and it resolves the user expectation problem of what do I expect to happen when I use this, because it's different I expect different things to happen depending on what the consuming controller is right.

G

Yeah now that that's actually a really good idea, I hadn't thought of uh the my biggest concern is the coupe cuddle ux around. That is awful. uh You know you basically just have to use fully qualified names in every command or chaos, uh but you know I, think that feels solvable. uh Maybe I don't know uh that that definitely does solve the controller, access or or help with controller access. uh It is unfortunate that you would yeah I, don't know, I, don't know how you maintain that spiraling mess.

G

If you know more and more sigs, come on board uh and I'll want to basically do the same thing, but in their own API Group, and then we get tiny little variations of the Gateway APA Gateway API one adds a verb and the other one doesn't, and you know it it's. It solves a real problem or set of problems and adds other ones is what it feels.

A

Like so uh on this same topic, so one of the things I had asked about so, which was basically should reference grants, be targeted at a single controller with a field that can be selected on right now when I use the word controller, there are very Loosely, it was really meant to like the controller would be like Gateway like or a Gateway API right, like I know it's many many controllers and many implementations, but they're conceptually the Gateway controllers or Gateway API controllers.

A

So that's like a thing, so it doesn't solve the read access problem because it's still one resource, um but it would solve the who am I giving like who do I expect to address this reference, Grant right X. If I have Gateway API listed the CSI controller whatever it does, will just ignore it, because it's not meant for it right. It doesn't matter like so. The name that you're codifying is an API, but it would. It would just be a single string that doesn't really have to change all right.

A

So it's not like it's an identity but like a like a sort of a fluid one that represents.

B

I mean it seems like you already have like is: is it? um Is it important to distinguish the particular controller you're already saying here's, the type that's going to be consuming it? It seems like any controller servicing. That type should have access like we are we're already describing what this is for in the.

C

So it doesn't Auto scaler manage the deployment resource.

C

E

C

It manages a deployment resource. Does a deployment controller also manage a deployment resource.

B

Deployment controller does and auto scaler does not, because it accesses deployments scale.

C

I mean clever, but um it's not obvious to me that we have a clear one-to-one mapping. No.

B

I'm I think it's fine to not have a one-to-one mapping. Actually um a one-to-one mapping means that, like if two of the controllers involved in an object needed to you know, you have one setting something up and one tearing something down, but they're both authorized to take action related to an object, I, don't know, I I, don't think we necessarily want a one-to-one mapping.

B

E

B

I I don't want to derail us too much, but uh I'll just ask this like. If, if we could make the user experience be anything we want.

B

Would expressing the intent for my local thing to be used by some remote thing?

B

um Would we want that to both Grant access and um sort of make make the record of the Cross namespace uh uh Grant, or do we like having reference Grant the sort of inert and require a second uh authorization like real authorization step? However, that's done for the controller or whatever is actuating this to actually have cross access.

A

And uh in the TLs case, I like it, if the reference Grant is the one that grants you the access, because, like the controller, the access to read the TLs Secret, because right now, I think most controllers are given broad access or the deployment has been carefully tuned to only look at one namespace for TLS Secrets. Basically,.

G

Is I yeah I like that as well? My concern is: would reference Grant be misused, then just to create you know basically read access, Grant, read access, I mean I, guess you're, just considering reference Grant at that point at the same level of admin access as any other rbac resource.

B

Right yeah I mean if it was actually effective at granting access and didn't just record intent, then yeah it would have to be treated like you know. You have to have the permission you're trying to Grant um I'm I'm, mostly trying to not move forward with half of a half of a story that has this like unspoken and also really Grant access, and we don't have a good way to do that, and so everyone's just going to give Global reductions.

B

G

That's fair. um It does concern me uh that, uh as as much as that sounds ideal, it sounds a long ways out. It.

B

G

B

Are people using reference Grant? How are how are they granting controllers access to read? What have you seen.

G

I I, honestly I think most is the global access that we're used to today, for which is.

F

G

E

B

um We can move on to some of the other questions like the selection stuff.

C

I I well, actually, I have I have another one related to this, so I'm, not as familiar with the Gateway API. If I've understood this properly. My my expectation is that um I have this way to expose uh some sort of Ingress into my cluster. I need to use a surfing certificate to do that. I go to a Gateway, a Gateway Ingress of some kind, I specify a secret, namespace and name and then in order to to explain to to.

D

C

To the controllers, behind the scenes that I have permission to read, this I also get a reference grant that I create in another namespace, and there is an opt-in in the original namespace. Is that how this works today.

G

Correct the the reference Grant lives alongside the secret in this case- that's being referred to, so it has to live in the same name space and ideally, as Jordan's subscribing, should should connote the same level of access right so that the person creating the reference Grant in the secret namespace should also have read access to that secret um that that last part is not enforced today, but is part of this kit so.

C

If there's already another object that says, I want to use this thing, uh I want to reference this secret namespace a name. How is this reference Grant, better than a role binding today or a role or role by me today? Where?

C

Okay, uh it's because you have Global read access? It's not a.

F

C

You don't have any access and they Grant it to you. It's a case. If you can read anything and you need to limit yourself, I see okay, I. Finally, I've made the last hurdle. uh Yeah I am also welcome. David uh yeah um I was a little slow arriving. I have finally gotten there um yeah, that's the opposite of the direction. I would have expected that to build up from okay.

A

Yeah I mean, but right, like the the gist of the problem, is you have lots of stuff running in lots of namespaces that needs TLS certificates and the controllers are servicing a bunch of different namespaces? So the ideal situation is users put TLS secrets in.

B

A

Namespace because that's what that's normal uh and then the you know the, but you know that gets problematic. If you don't want to give Global read well, then, if you put them in some other namespace that will then how does the controller know you're allowed to read that arbitrary secret from that new space for your.

C

E

A

I mean I I, guess you know you, you could imagine.

A

Instead of there being a reference Grant, there could be some schema for the controller to generate a subject, access review, based on the specific thing it's trying to validate, okay, and if that was allowed, the controller would know you have the reference Grant and if it was not allowed, it would know that you don't have the reference Grant and thus it wouldn't let you do it um to.

G

To clarify, are you referring to a subject access review for the user, that is creating the Gateway or the author of The Gateway, or are you like controller? Wouldn't have that? Are you actually talking about? Like a you know, bespoke way of use a new way of using uh a new role, a new verb? Basically, that uh would would be that how you use the subject, access, GPU, I, don't know.

A

So what I was trying to conceptualize is, you know, controller, has all this state and it sees uh um a I, don't know a Gateway service thing and it it's saying it wants to consume a secret from over here and it needs to like hook it up right and say: yeah like am I allowed like is this allowed from across namespace right? So the reference Grant is what it's telling it today that that is. Okay am I, am I still correct. There uh I haven't like gone off the deep end.

A

uh I was saying that like, if you could, instead of looking at the reference Grant and doing some computation or looking for a reference Grant and doing computation, if you could instead do a subject, access review that was somehow built on the thing that you were trying to check that could theoretically work I, just don't know if you have the information to build a structured subject accessory with the right, like Target user I'm, not exactly sure who the target user for that subject. Check is uh right.

B

There's there's like three actors, not three actors, there's the user that created the Gateway object. We don't have their identity that that information doesn't exist. All we have is the Gateway object. Then there's the information about the Gateway object. You know this is a gateway resource in this API Group. With this name in this namespace, that's not really the subject. That's like the referring resource and then you have the controller identity.

B

So those those are the the actors or the objects in play. Subject: access review like what question would we want the controller to be asking? It seems like the question reference Grant is trying to answer is: can this resource reference this other resource yeah.

F

G

Could resource.

B

G

Yeah, if you could somehow represent Gateway as the identity, uh somehow right like this, this is the identity that is trying to access, and then you had I, don't know I, it's it. It feels I, don't need it probably doesn't make sense, but it it does feel similar to the model at I.

B

Don't know this reminds me of um like delegated access discussions we've had in the past, where, when a controller took an action in order to actuate some resource uh like, ideally, you would want the action to be authorized both for the controller doing the thing, but then also have information about what it was doing it for um and make sure like. That combination was okay in this case. Ideally, the controller wouldn't even have access to read the secret, if not for this reference from the Gateway um welcome.

C

The ghost of Eric tune um so as I remember that his suggestion from gosh seven years ago uh was to ascribe an owning service account that was checked for permissions at the point of usage right. That was I. Think that was his very initial sketch is. Is that closer to what the Gateway API here is trying to model like the apparent? Presumably the person creating this Gateway Ingress? Sorry I, don't know the name of it.

C

I should learn the name of it, um but that person may not have rights to themselves view the serving certain key pair, but the uh the actual Ingress pod itself or Ingress owner does, but you would only want to be allowed to use it if the the actor, who created not the actor, who created the the namespace, something in the name space where the Gateway Ingress was created, had permission to use the secret, even if they can't see it. So that way you could revoke it part way through right like so.

C

So, if you get to a point now, where you revoke this check, something actually has to delete this reference. Grant.

G

So deleting the reference Grant is something that controllers are required to respond to by revoking the access, so that that generally means it's pretty destructive in Gateway API terms, it means basically spinning down the listener that was using relying on that certificate uh yeah, but but in general it relies on blocking access and the one the one thing I want to highlight is I think you were kind of getting there already, but it's not that the creator of the Gateway needs read access uh that on the secret they're referencing.

G

They just need somebody who owns that secret to say that secret can be referenced from a Gateway over here, but that again that the person controlling the Gateway doesn't need to, or ideally should not, you know, have access to the secret itself. Just know enough that I'm allowed to reference this in the Gateway controller can do what it wants with it.

B

um Yeah, the idea of responding to revocations makes if we model this as just authorization checks like that means that there's nothing that the controller can watch to know that the authorization was revoked. So.

D

B

Instead of watching reference, Grant and self-limiting and then revoking when a reference Grant went away, it instead did a subject that codes review. It's like I want to set up an Ingress, so I'm going to do a subject. Access review can I access this secret, or can this thing access to the secret? Yes set it up like you can't watch?

B

Subject: access review results to know like the authorizer in the background changed his mind. Well,.

C

If you create the single subject, watch with the actual service account in reference right, you remember. The original proposal was limit. My power to the power of the the service account that's referenced, uh then, when the rights are revoked, you're unable to re-establish The Watch.

B

That doesn't seem different than a poll.

A

I, don't know it would be just a recheck of every 15 minutes or whatever your watch got dropped.

G

I I think somewhat related to this uh Mo had a question and somewhere in the agenda about what what go interface yeah, what go interface, uh the controllers would use and I agreed with the idea that yeah this.

G

This is similar to the idea of a subject access review as as the initial interface, but to make this Library helpful, you need some kind of centralized cache or something like that could inform controllers that that the reference that was previously allowed now needs to be revoked, uh and that so so, although this looks I think this is really similar to what Jordan was already saying that, although your starting point can look very similar, you need something more um in in that Library interface. Whatever.

A

Yeah that was part of the reason I asked it was like I I, see vaguely and authorized thing that takes some inputs and tells me something. But since there has to be revocation there has to be like I, don't know, add event handler or something that looks like an Informer thingy. That tells you that you need to like I, don't know rerun the authorized function. I, don't know, I'm, not exactly sure what it would tell you, but at the very least it should trigger you somehow uh to do something.

A

um I mean at the same time. I don't want controller implementation, so just be like I can't figure it out. So I'll just keep checking I'll, just pull authorize every minute for everything just to see what happens. I mean I. Guess it's: okay, because you're probably only smashing your own cash. So it's not a big deal but like it's still, not not exactly the experience. I want people to have.

C

Yeah there's something to be said in different directions: right um one of the advantages of authorization is, it can be external right, it can create whatever you want to drive that permissions or not.

A

Right, no, no I, I I'm not like advocating for us trying to somehow make some watchable subject: Action reviews or something like that. It's more just uh I wanted to make sure that we capture it at some level that there there's some Nuance to whatever library that we're going to create for people to try to use here.

A

uh Since we only have like 10 minutes, left and I did want to give like Kristoff and stand up some time, uh what are like any high level clicks next steps for Rob here, David Jordan, and what should we do next here.

C

I I haven't read deeply enough to see if there's a section that compares the generic concept of a reference Grant to the specific usage of specific apis, one for Gateway One for storage, one for whatever comes next.

C

um If that isn't already, there I think some sort of detailed dive into it. Like I listed a few cons that came up here, uh I listed a few Pros that came up here, I think describing that an alternative seems useful um because they they dealt with how we handled the uh the user interaction.

A

So David, how long till cell has access to the authorizer? So you could have a custom resource do on c-checks.

C

Of the second Alpha should come this release, uh so it should be in Alpha. This release. I have not looked for an imple PR, yet.

A

But I haven't been keeping up with the kept. Does that give access to the authorizer I can't remember.

C

It does the second Alpha gives access to the author.com.

A

Okay, so it becomes tractable to have like I, don't know a yaml that you can template out. That gives you like.

C

Reference it does, although I think, for many permission, style checks uh crunchy on the outside, like something where you just check when it gets created and then never check again have some limitations that are not awesome.

A

I mean our back only checks when you create right, we don't like retroactively, remove stuff because you lost the original access too right. That's true, so I mean it's something like I I think that would be my biggest concern about like hey. Let's give some completely external thing that people can reuse is we have a lot of power in our built-in apis and I know: custom resources slowly are getting further and further along on their track, but I hadn't kept up with the sales stuff.

A

So, uh okay with the eight minutes, left Kristoff stand out what is going on.

E

Of the items from the pre-acceptance tasks, as you can see, uh we have many of the of the items on the list are already checked out in the past few weeks. uh We uh basically we worked most of the uh of the logic uh to use uh to use the app steam handling of you know, options and we use the uh Cube API service. Secure. Seven uh to actually you know surf are the proxy, and then we use the delegating authentication and authorization.

E

You know the uh so yeah much of the cold change. uh I think it now looks much uh closer to uh What. uh What the sake of wanted us to do with the repository um I. Think that you know the the heaviest tasks uh have been addressed, uh that there are still two left on this documentation and the other one is h2c uh topic. That I believe that she wanted to talk about and I believe that she also wanted to give an update on some of the tasks that he was working on.

D

Yeah so basically uh standard Joint Forces, and he made quite a lot of nice. Changes, looks really like a communities project now and removed on the way half of my changes that that were more kind of closer to the previous logic. So uh great thanks to him that he supports me, um it jumped forward um and yeah. Basically, what left for me was.

D

Basically, you checked the the cve that they would uh mentioned in the first review that it doesn't fit, and he David had also some suggestions about some security issues that might come so I verified some of the default settings that we were running with, that everything is safe and okay and I think that's mostly it the only questions about h2c. If we want to keep supporting it or not.

D

So basically, um it's HTTP 2 over TCP and I think it was necessary for um back then for him, the number one version I think tiller or something like that needed it and Cuba effect proxy was used to to protect it. So the question is: do we still want to move forward with it or do we want to drop it, because we also created um a new branch which is called sick art acceptance, because some of the changes that we need to do to satisfy uh the review um was to make breaking changes.

D

So the question would be: if we're doing already some breaking changes. Do you want to make another leap and drop more of the features that we think might not be necessary anymore? Or do you want to try to keep it um because it's really hard to know until the users start complaining right? So we are curious. What what the opinion of sickoth is.

D

If this is a feature worth carrying on or not I remember that I had a discussion with David, where he said that he would be more or less fine as long um as the Upstream doesn't trust um the proxy. So when we have some folks with a feature that you can at um identifiable information um into the header, so that apps you can use it. So this would be something that we we need to remove in case that the connection is not encrypted.

C

Foreign, so just in case say my memory from uh looks like that was David nine months ago, uh and people here aren't aware. Are we talking about the connection where an external user is sending their token to the QR back proxy, as does not have TLS enabled or are we talking about? We always require TLS for the user to send us their token, and we optionally uh allow non-tos for the connection from the QR black proxy to the backing uh server.

D

It's it's a banking server, so um I think with the last progress that Santa made to the new branch that we created, there was no non-tls, um so the approx is not serving anymore or without TLS. So.

C

That part is already cleared like it's it's the case now, where we don't allow someone to send us a token without TLS enabled, and now we're just talking about whether it is acceptable to have a back end. That only speaks to http.

D

Proxy and the back end, if it should always be TLS or if we allow non-tls connection uh for it with HTTP 2. okay, because in some cases there are some educations, where some Services rely on that.

A

um I I guess I would ask if we're only talking about h2c here on the from our back proxy to backhand, like h2c, like is relatively like Advanced. As far as like things go like I'd like who's using this.

D

Well, so, basically uh proxy is something that Frederick bronchick did and I watched his explanation in on one uh on a meetup on YouTube, where he kind of said that it was contributed to protect the because it was without TLS and with Cube epic proxy. You could have some kind of protection in front of that, but I I didn't follow up on on it um very strictly because yeah I'm, not the ham user,.

A

Yeah I guess I'm just trying to understand how are people using Q Bar back proxy today? Are they so they? If, if you had TLS coming into Q barback proxy, are people reusing like? Are they re-encrypting between Q Bar, back proxy and their back end? Also, I, don't know.

E

E

Like I mean it's certainly possible and I guess that you know it might be done that way,.

C

E

You can imagine.

C

Two cases right there's one case where you use QR back proxy to establish all the permissions and if the request comes to your backing process, it is good enough. You don't need to know who the user is. They've already been authenticated and authorized, and.

D

C

That case, it's pretty clearly safe to use HTTP HTTP. If you really don't want to have a secure connection and you're local inside the Pod you could, you could argue that that's safe uh in in the other case, you would say: okay, uh I do want to know what user it is because I'm going to take action based on which user it is and then should.

C

We support a use case where you don't actually protect yourself from external connections or somebody else saying: hey uh yeah, you know what I am system system Master uh on for this little pod uh give me rights. Should we make that possible? Is the is I think the last question.

A

Yeah, so traditionally, what I've done in this specific sort of topology is to support um things like service meshes, which I know isn't the case here, because, probably not, but what I've done in the past is I have allowed the clear text connection as long as it was either directly 127.0.0.1 colon, colon one or a UDS.

A

So if I could 100 percent guarantee that the thing I was talking to was local to me, that I was okay with the plain text connection. Otherwise, I was like no gotta. You've got to re-encrypt it and figure it out.

C

I think that is recognizable.

E

A

So I don't think it blocks the normal use case or what people have, which is it's right, like the things are co-located, so there's there's no there's nothing to intercept, uh but it also protects people from sending tokens or trusting tokens and contacts that don't make sense.

A

um At least it tries to it's not perfect I mean you know you can't protect them from making like a different listener on their app. That is like unprotected or something, but you know you can certainly encourage them in the right direction. Here.

D

Okay, so summarize it, as the suggestion is to keep it under certain restrictions.

E

C

Mean it means you have restrictions right, so you would keep it. You would not send the user or or identifying information unless it was directly to a file or to localhost.

D

Okay, that's a rule that sounds implementable.

A

Yeah I mean if somehow you had proof that no one was using it in that way. Then I'd go yeah, you could drop it, but I, don't I, don't think. That's the case. I fully suspect that people are using it um as their front door and not exposing their service in any other way. So it seems like I. Don't.

D

A

To be by the way h2c, it can just be regular HTTP one plain text also I, don't think that matters h2c is like weird, because, like you need a relatively like Advanced Network stack to support it like I, think we take for granted. How good go is that networking I've recently been learning rust and I have learned how bad it can be when your standard Library cannot like do PLS so yeah.

D

Okay, so um Mo, you said you would be willing to do the review. Yeah.

A

I know I will do that. You tell me what you want me to review you. You start assigning me stuff and I'll review. It.

D

um Basically, um I think it worked really really well with uh David last time that we were basically in a meeting and we broke it up in one hour meetings and we basically went through the code base and, and then he discussed with me what he sees. What he's happy about, what he's not happy about I mean especially not happy about things. What are the things that really created um kind of um comments on that pull request, um and you know I think it's a good way to work on that.

A

Yeah I mean if you want to schedule some time with me, yeah, let's, let's do that! uh Yeah high bandwidth makes it go back faster, so yeah that sounds better than me. Spending hours reviewing the entire service so yeah. We can do that, uh but yeah. We are like way over time, uh so uh we'll see y'all in two weeks.

A

D