Kubernetes SIG Auth, 24 May 2023

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

Sig-Auth Bi-Weekly Meeting for 20230524

A

So everyone this is the cigarth meeting for May 24th 2023. Let's see I think we have a relatively light agenda today. So let's get started. uh Okay, so first announcement, so I think I've spoken with you about this Jordan.

A

um So in 128 I was going to Mark uh cam sv1 beta 1 as deprecated, um and then once V2 goes GA, which is normally supposed to be 129. uh There will be a feature gate that is um off by default, that you must enable in order to use the V1 functionality.

A

um So you would be nagged when there is a ga replacement to go. Do the work to replace your stuff.

B

I might have misunderstood. Does that say 128 we would deprecate in nag, but I want to BGA to 129. That sounds okay, because it's beta but I want to be sure. It's beta.

A

uh So Jordan convinced me not to nag, so we will deprecate in 128 and have it in release, notes in 128. and then in 129. Like let's say in 128, we add the feature gate it would be enabled by default in 128, but.

B

In 128 longer enabled by default, okay I just want to make sure I understand when the nag is happening. Your intent is to nag not when there's a beta replacement, but when it's a ga replacement.

A

Yeah but I want to tell people now there are no fixes coming there's no improvements coming stop using this. Please.

B

I, don't know for sure that I agree with no fixes, but no new features. I definitely agree with yeah.

A

B

Sounds reasonable.

A

I mean I, don't know what we would fix at this point. If.

C

We found a vulnerability in kmsp1. We would try to fix the vulnerability, but we're not going to like try to address the scale issues or the things that kmsb2 was intended to address. Yeah right. That makes sense and just to be crystal clear. I know, you'd and I agree on this mode. Like we say deprecated, we are not ever intending to drop the ability to read uh KMS V1 encrypted data out of STD, we um probably ever uh so. People get really anxious when they hear they were deprecated and.

D

C

Like oh, is it going to be deleted and no, but you should stop using it and move to V2, because it's better in every way, yeah.

B

I I think, are you sure about never like.

C

What, if no I'm, not sure about never, but a lot of things would have to change like automatic storage, migration, I think I.

B

Think that's the one big one that I see yeah.

C

Yeah, so when, when we're saying deprecated, this is not so we can start a clock and like Drop, KMS V1 read support in three releases. That's not why we're marking a deprecated.

A

Yeah, so I I, think sort of the maximum concrete plan I have is if V2 was GA, maybe three releases, maybe even more than that we would drop right support for everyone. So you could. You can move off of it, but you you're not supposed to use it for rights anymore at that point, but that's like the earliest I feel comfortable. So like a year after b2ga.

C

um Yeah but that's a separate conversation. This is just to tell people like correctly label the KMS V1 feature as like: it's not it's not going to get better.

E

A

E

Not the teacher is not going away, but we'll only have critical about expenses built in Italy.

F

C

Yeah criticals in the eye of the beholder like dirty fixes, I, don't know the.

A

E

Fixes in the future yeah.

A

That one is easy: does it leak the crypto Keys? Somehow, then sure we will fix that um and if it somehow does that and we haven't noticed yet almost certainly V2 probably is impacted too so.

A

Okay, um um okay, so I don't hear any issue, though, on the the relative semantics um here: uh okay I can I guess, move to the next one, which is little demo, um so I know I, don't see any eks folks on the call, but I know that they were interested in um external signing of service account tokens, and one of the things I had asked about was to have um support for uh certificate-based signing of service account tokens uh for that feature.

A

Basically, so that way, if you wanted to have external private key material that isn't directly accessible, you could still like provision like short-lived certificates, like into the cluster that you want. So that way in the same way that, like KMS V2, fixes most of the performance issues of KMS V1 by moving the external server out of the main Loop of the every call. Basically, um that's what you could do with certificate based signing um so I implemented that and I was going to show a little demo of it just kind of fun.

D

A

I did not implement this with an external signer I implemented it with an internal like the internal code. uh So let me stop. Sharing this terminal and I will share my other term.

F

A

One moment as I remember how to share screens where's.

E

The button here.

A

It is I will say, teams has broken, my brain I can no longer remember which button does. What, in all the different chat, apps I have to use now.

A

Okay, so I just have a locally right. It's a great, almost certainly way too tiny foreign I have a locally running terminal that has a local cluster up running from that branch, and so, let's see so, if I show this. So, if you guys remember, openid has a jocks endpoint for the API server. This is the regular key, the one that we have today.

A

This is the key that is based off of a CA. So you know it's got some key ID, but you can also see that it has an x5c.

E

A

So this is the.

E

Root CA right, so obviously this is the public key information of that root. Ca.

A

Right um and then let's go, let's see what should I do next. So if we were to create a token we can I mean, let's do actually, let's do Oculus.

A

um So if I do, who am I but with a token for the default service account, um we can see this nice little warning that I added to the code base, so I could actually see that my stuff was working because Jordan's really happy, because it's a warning, because that makes him happy um it's one of the easiest ways to demo. Something now Jordan is to log it as a warning, so you can see it in your terminal. It's great I love it um also.

A

It worked the very first time so I was super skeptical that it actually was doing anything so I had to add this morning just to prove to myself. It was doing anything uh but so like if we look at the token. So if we look at the token- and we just grabbed the header and decode it- we can actually see that it has an x5c uh certificate in there.

A

But if you look at this key ID or this key ID, it does not match this key ID right, because this certificate, the the sorry this token, is signed by a certificate. That's not in here it's a sir. It's a certificate that is chained up to this route. Ca, so I can show that. So if I was to.

E

Share this real quick, so.

A

This is the root CA, that's from the Jackson point and we can kind of see you know its parameters um and then, if we look at the one that I get from uh service account token, it is a different cert that has um you know it's not a CAA, but it does have um client auth on it, whereas, like I think I, don't know if openness cell shows it here, I don't know if it shows here there, um one of the things I ended up doing because after sort of reading stuff online about this flow, like the biggest mistake, I saw that people tend to make.

A

Is they put a root CA into their trust? That doesn't semantically make sense for tokens so, for example, they'll put like digicert or something in there, so basically anybody's anything can be kind of used because anyone can ask digicer to give them a cert um and obviously I know. If there was cas-based support, someone would try to use their company root CA, because that's what people do but I, don't think the intent there would be that I want my company's route, any certificate signed by my company's route.

A

Ca, to be also able to sign tokens that are used within my kubernetes environment that doesn't make sense uh so to try to safeguard that I basically made the code require that the DNS name on the Leaf certificate basically match the issuer. Hash that's configured on the cluster um I, don't know. If that makes sense, it's something.

A

um Let's see did I want to show. Is there any other? Is there any questions at this exact point before I go to like the code to show people what it actually does a code.

G

I had one question about the did stuff right, so if the key ID does not match uh like if the, if the array there are multiple elements in the array, like typically, they use the key ID to figure out which one to do, but with this would they have to go through the array and try out all.

A

G

Ones to see which one works.

A

Yeah that so that is fair, I guess if you were um so for the API server, it doesn't matter because it only trust. Like one group ta like sorry, not one, it only trusts a Roots, uh a bundle of a set of roots right, so it doesn't matter how it chains up to any one of them or more than one of them. It just has to chain up to one of them right um so right now the logic is very kind of simplistic. Where it just says: okay do I see a token.

A

Did it fail, the normal token verification for service account tokens uh do I, have the ability to do root, CI verification, and does that token have an x5c header?

A

If it does, then it'll try to basically root up to that the the routes that are trusted and if that works, then it'll take the public key from the certificate and use it to verify the actual token, so I I think the reason you're asking that question Anish is the fact that, like if you were an external provider- and you were trying to verify these, it might be more difficult because you might be verifying many many different ones um like you might have many many different routes that you trust as separated trust domains and then have meaning across them.

A

So I think we'd have to think more carefully about how we, how we do that. Obviously one way would be to make it so that the key ID- that's um in the token matches this one. You could totally just do that. I guess that would totally be fine. It's not really used by the API server, so I think we could make that.

C

Well, are there are there expectations in the spec like the tokens that come back? If that the key ID will be represented in the shot key set, or is that different for uh x5c stuff, I'm.

B

Just not familiar.

C

With x5c validation of dots.

A

I'm not 100 sure how that plays in with x5c I'd have to look at it more closely. um So I can I can take that as an action to kind of yeah.

C

I feel like some of the client libraries would trigger refreshing their view of the key set if they saw a token that had a kid that wasn't in the last fetched one but I don't know if that's like an on failure, fallback or if that's a. Hopefully it's not like I, saw a token with a random key ID Let me Go fetch, because that would be a general service inspector, but yeah yeah I, don't know it's.

A

Worth checking yeah, so that's good feedback, yeah and I think it probably makes sense to make this and this match mostly because the API server doesn't use this at all um or its verification. So it could just be for external actors to figure out which route CA they're supposed to chain up to, um let's see, did I was there anything else. I wanted to show on.

H

A

um I think I'll stop the terminal stuff and go back to the code. Real quick.

I

All right, where did.

A

Okay, so on the code, it's actually like a relatively small change.

A

um So if we look at it's a this is like the main authentication Logic for service account tokens and basically, if regular e-verification fails, it will basically check, can I do TLS based or certificate based verification, and does the token that's being sent to me have an x5c header on it. If so, uh what it's going to do is it will take the verification options that it has.

A

So that includes the root Cas that it trusts and then it will try to chain those up with the certificates that are on the x5c header, and if that works, it will take the leave certificate, get its public key and then use that to actually verify the token itself. So that's basically how it ends up chaining up right. So you you trust the leaf, because you trust the root and then you can use the Leaf's public key to verify the signature of the jar itself.

A

So basically it's like Dynamic Keys effectively it's kind of what it ends up being.

C

When you say the leaf, do you mean the leaf certificate.

A

Yeah so the leaf that was used in the chain so.

E

H

Can we tie this all back to the AWS eks thing like what.

A

Properties of this make you see it as.

I

Of viable alternative to their.

A

Oh, it's: it's not an alternative. It's meant to be um like a co-requisite. Basically, is that if we uh support that flow, the like eks is sort of happy to make it so that every time a service account token is signed, you have to make a remote API call um off the API server and go off to wherever to get stuff signed.

A

That's not necessarily tractable in the environment responsible for so I wanted an approach that could sort of mimic what we did for KMS, which is keep everything within the API server as much as possible, and only in the background have the external remote call. So the way I would see this happening is the plug-in.

A

You know this external, like you, I, don't know a grpc plugin could sit there and you know every minute or whatever hour, whatever get a certificate issued by some route. Ca that's trusted and then use it for signing.

H

I guess how does it like? How is this different than having a.

H

Key per server and Publishing that, via the jux URI.

I

Without the x5c.

A

H

I guess like imagine this, with uh without x5c, where you just publish those yeah.

A

So I think the difference there is.

A

um The certificates are inherently lifetime, scoped right so like you can keep them short-lived and they don't have any meaning outside of that tiny lifetime, whereas a public private key pair is just Forever Until, you decide to rip it out of the end point so.

H

In a path, validation for x5c we're not going to validate like I.

A

Mean if I mean this just this is this function, just does cert dot verifies so basically exactly what you do in regular TLS.

H

Stuff but then the keys you're not like.

I

A

Keep it at least 10 minutes, because that's the minimum length that we want tokens to be valid for, but.

H

A

H

I

We trying to reduce exfiltration risk of a.

H

Key like and we're not, these keys are live forever, so I can just still pull one out.

A

H

Use it in perpetuity to science service account keys if they're not like.

A

I think what it would end up giving you is just like pretty dramatic, constant rotation effectively.

H

Yeah, but with a like, if I publish all.

A

The keys that I think are valid. I can at least remove.

H

Them here, if we're not doing any like.

A

uh Validity duration, validation and the path validation, then.

H

A key that is used and potentially exfiltrated can be used in perpetuity.

A

Right did I did I, say something that made it sound like. We would not be doing time-based validation, okay,.

H

Well then, if they're valid for an hour, then the tokens can only be valid.

A

For an hour, and then we could just we.

H

Could just like I guess we could just keep swapping out the keys that.

I

um In the gxuri every hour or something.

A

Right, so that's one of the nicer things is you don't have to make external actors check all the time right, the the root CA stays stable and is ideally somewhere deep within your Vault and.

H

I guess so, it would reduce the amount of fetches to the juke's URI needed um and the trade-off is like larger tokens. Yeah.

C

I mean and more complicated validation like I I, don't actually know how good the support for Xbox is across, like John verifying yeah.

A

So I I think the way that would end up having to work is you in your plugin would decide when you want to use this so like that sort of is up to you right, like you, don't have to use it all the time or you don't have to use it at all. There's no hard requirement to use it I'm more talking about having an option and then letting whoever is issuing the tokens issue them that way and if they're not valid to the other entity. Well, it's going to fail very obviously.

C

I

C

By like I'm trying to think of this changes or expands what someone using a cube, API server tokens and how they're verifying them like today, we don't support this, so nobody verifying tokens against Google, API server today would necessarily know if their x5c support was broken um as soon as QB API server supports, even if it's optional like supports an integration that can produce tokens like this produce. Just like this now, every client that runs against Cube, API server and verifies tokens has to at least consider the possibility of tokens like this.

C

If they're gonna like say, we interoperate with random Cube API server XYZ so right, um it would be good to know like maybe a survey of the not just the go ones but sort of the you know top one two three like if I was going to validate jots in random language, whatever what library or libraries would I likely be using and do those actually support, x5c like knowing where this level of support is in the ecosystem would be helpful.

A

When you guys did, though, uh uh the open ID stuff for cube, what did you validate in that process for consuming of tokens? I'm curious.

F

um I think what do we do? I think we.

A

Wrote about I mean if you wrote it up, that would be good. Then then I could try to poke at it and see.

H

Definitely uh I I recall AWS, explicitly and uh Vault oidc.

I

Credential back end.

C

I

C

uh Feature has been confirmed: incredible, independent, relying parties, um basically the Federation solutions for the cloud providers and looking at popular IDC libraries, so I. We could dig into maybe the graduating PR to see what got pointed at, but we did similar sort of due diligence. um There I think uh the tokens we were generating at that point were like bog standard tokens.

C

It was really just the discovery like hitting that Discovery URL and being happy with the discovery content yeah, uh so that in my mind, that's a smaller surface area than like a new type of token signature. That's pretty esoteric.

C

um That is foteric.

A

I mean come on like if it was that esoteric, I, don't think I could get the whole thing working in. What like 250 lines can't be badassed.

C

That just means that the library we're using had support for it, which is awesome, I, just don't I, don't have any sunscreen how common it is. Yeah.

A

Yeah, that's fair, okay, so I will all right so.

F

F

F

A

uh Any other thoughts or comments, I I, think I would generally agree with the sentiment that we wouldn't do this unless there was something else to tie it to right, like I, wouldn't like so I ended up, adding like two flags to the API server. To make this work, one was um well what other Roots he is that you trust and the other one is when you generate a token or when you sign a token, what x5c stuff do I need to attach to make it so that on the way back in it'll verify correctly.

A

So that's just you know like what is the public cert for your right, because the private key that you're given for signing is just a private key. It's not a certificate, so it doesn't know that piece um so I did that that's fine, but I, don't think we would do that unless there was compelling reason effectively um or some variation of that.

H

Yeah, that sounds good. Let's.

A

Just be super crisp on the cost.

E

Benefit trade-off in, like the cap sounds good.

A

Well, let's see and then we have KMS stuff again: Nicole gee.

G

Now I'm, bringing it okay.

A

All right: um well, you can finger and I guess we can talk about uh canvas V2, crypto, so Mike you and I spoke about this at some length and I took most of what you wrote up and then added more comments. Based on my comment. Last conversation with Jordan um I just wanted to see if we were in consensus enough for at least for me to go, try to implement all this and get it ready for 128.

H

Yeah I think the one the alternative that is not here is that.

I

Aes GCM SIV implementation in tank um as.

H

Like it's, it, which seems to be the only.

I

Potentially viable implementation of eight es, GCM SIV in go so.

A

Yeah so I think uh I think the biggest concern I had with like the tank. One was like uh the so. The open um uh issue to add support into standard library has like a PR or a change attached to it. That is like mostly assembly code, I, think there's a bunch of assembly in here. uh So then I was confused concerned about how the tink library was implemented and just go.

H

um I I guess the like poly Val hash.

I

Is just a go implementation there's there's a NOS ASM implementation here.

A

Oh well, yeah I mean there's always a Northside one, just to make it fall back. If you don't have the right platform.

E

A

I I I more mean, like you know, we're probably going to run this on AMD 64.

H

I guess what what do you can? What are you concerned about performance.

A

And any random timing, something in others that.

D

A

Up um and I may be at a high level of like. Well, it's not in the standard Library are we sure I mean you could argue. Super box is not in the standard Library. So you know maybe you've already crossed that Chasm.

E

A

Yeah so yeah yeah for folks that are not familiar. It's nonce misuse resistant. So if you have a nonce collision with asdcm Sev, um all that happens is you lose the Cipher text of like the current object effect. You, don't you don't catastrophically disclose every single thing that you have previously encrypted with.

E

That stuff, so.

A

It it like basically limits your screw-up to basically the current thing that you were playing with, but.

G

A

You pay at performance costs, for it. I forget the percentage that was in the RC.

C

When you say lose, you.

I

Mean disclose yes,.

A

So, instead of uh we had regular asgcm with like one Collision, if I remember correctly, you like immediately disclose the plaintext of the things that collided, plus the authenticating key and I. Think if you have more than like three or four, then you just catastrophically lose the actual encryption key that you.

H

Aes gcme lose authenticity, so you lose.

I

The um authenticated encryption, but uh the the hash can be that I've like changed hash.

A

Can be attacked.

I

um And then you can xorge to cyber texts with the same key same knots, uh to get an extorted value um of the plain text. But it like the SIV I. Think that.

H

It's the uh ciphertext all right, the plain text: the and the.

I

Nonce and the key are all combined to create a synthetic IV which would be different for different plain texts and that prevents uh the that results in the Collision resistance with something like something called polyvel but I think I. Think the only problem with repeated.

H

Yeah I'm not sure that you lose a.

I

Single uh ciphertext, where the ReUse knots with as as gcmsiv um I, would double check that but I.

A

Even if you ignore that I know that if you lose, if you have a few nonce collisions, you can basically do some polynomial math to retrieve the actual encryption key. It's one of like the exponents in like the shared polynomials across things like I I, that one I did dig into ADP. So that's the real question here is we're using the same data encryption key effectively for the lifetime of the process.

A

So if there were a handful of collisions, then it's kind of just host. Basically everything you encrypted with that is kind of gone and.

C

The collisions because we're using and incrementing integer for the nonsense, the collisions were mostly around like VM restore scenarios where.

F

A

I, don't think we have.

F

C

And then restored or something happened in you know, memory went back to a checkpoint and like replayed the same iterations and.

A

Once they replace them, it'll it'll have many many collisions, basically as far as when it went back right. It's because it's just again.

I

um But the other thing is I, there's no great implementation and go and I do not know if there is a fips implementation in any of the standard. Fips open, SSL distributions, which.

E

Are two downsides.

I

C

Does seem like a big downside.

A

uh uh Sorry Mike, can you clarify which thing doesn't have a fips implementation, I, don't think asgc.

I

And sov I couldn't find a fips. Oh yeah, implementation.

A

I'm unaware of that myself, but I hadn't thought of that. uh That is true, that is in itself problematic.

A

uh Fips can't can't seem to get away from me.

I

It's relatively new.

C

That was going to be my next question like how what how like battle tested is this and how confident are we that we would like we'd be happy with this as the foundation for Kate Miss V2, like forever.

H

uh 2019 was.

I

The standardization.

E

I

A

Not, which is why there's.

I

No fips because it takes seven years to get a module.

A

That makes sense so, where 2026 y'all it'll be there.

C

And and then you said, the standard Library implementation isn't emerged yet yeah yeah.

A

I don't know it.

I

A

Going to be right, I don't know if, like Filippo or anyone else who cares about this stuff actually wants to.

E

A

Like what is it yeah? It's it's.

E

Just a proposal, I guess right now.

H

There's a tank implementation.

I

And the people- the reviewers, legit I- don't know how widely used it's been. Though it's up here you go um I guess we can move on to the uh second option.

G

What was the second option.

A

E

A

You mean what's written here: Mike yeah, okay, yeah, so the first option and I'll try to write some of the details down in a bit, for it is basically what we just talked about, which is it uh the SIV implementation. So that way, if we screw up the non-swell, it's not a big deal um or as a less of a big deal, and we can kind of stop worrying about it.

A

uh The second option is basically a scheme to basically extend the nonce that, as GCM is using so the the notch size of asdcm is just 12 bytes and there's no way to increase that, because if you try to give it more bytes, it just hashes them down to 12 bytes. So don't waste your time.

A

um So that means that you do need to do some kind of key rotation, because the chance of collisions goes up. If you do too many, um so KMS V1 got around this whole problem by just you, re, never reusing a key ever um needed the problem of horrendous uh startup times and performance costs, because you were constantly hitting the remote KMS to decrypt or encrypt the decks you were using.

A

um So this scheme, which is roughly analogous to what we discussed a while back with the diagrams and stuff I had was it would stop calling the thing that we send to the plug-in the deck. We would probably start calling it The Seed, which would be a set of 32 random bytes, and then we would use 16 bytes of a nonce with hkdf expand and shot 256 to basically generate a random key per right.

A

So I don't know if the math works out exactly as like an additive to the nonce like. If you could pretend it was a 28 byte, nonce total, um but just as an example, secret box uses a 24, byte nonce and basically it considers that good enough for just having random nonsense, um and then we would end up storing the. So today we already stored the nons, the 12 byte knots alongside the uh encrypted deck in cyber text, we would now just store more nonce data.

A

So that way we knew how to regenerate the deck that was actually used and then to make reads, not take a performance hit from hkdf. We would have some kind of cash, probably unbounded size, but then we would limit the growth of the cash by giving each entry some TTL and probably will make the key into the cache the NCD path of the object which we already have, and that would prevent um like frequent rights to the same object from polluting the cash too much.

A

And then, um if you were just making lots of lots of new objects, then the TTL would prevent unbounded growth, that's kind of how we would keep the cash from going too big, uh but the cash would basically just say. Oh I, see that you have this um nonsense.

G

E

A

Know what the deck that goes with that is so I'm just going to use that you don't have to go through the phone math, basically of httf.

E

A

So this prevents the issue of a non's collision because you never really reuse the same key. So if your nonsense, Collide is kind of whatever.

A

Jordan you look very unhappy.

C

That that's my confused face, I just can't I! Don't have that in my head. So I, it's hard for me to reason about I would probably lean really hard on folks, like Mike and other other folks who either can reason about like that chain of construction for the months or have like crypto review teams. They can ask about that. I I, just don't I, can't I, don't understand what each of those like lengths and chaining those steps together. I, don't know what the properties of that ends up being.

H

Yeah, we can uh make sure that the.

I

Smart people double check that.

E

A

Like did you get any other feedback from the crypto Folks at Google.

H

Not yet, okay, so.

E

Wait not it I'll focus more actively.

B

Picturing, a bunch of people like around a whiteboard in the college lecture room trying to determine whether this this works. Beautiful Mind, Style.

C

The Conspiracy Theory guy with like pins and red yarn, yep.

C

um So yeah, like assuming people who know what they're talking about look at this and say this like cryptographically, is solid.

C

um Knowing what the performance overhead is uh was my the only thing, I really had an opinion on and uh I think if we key the cash off of the LCD key, so we retain at most one decryption key per actual entity entry, then that insulates us against cases where someone's doing a ton of rights of the same objects um and did you have the overhead I think uh it'd be helpful to throw the overhead per cash entry in here just so, we can kind of reason about what the memory use would be for various amounts.

F

Of TV data or entity object, counts.

H

Yeah, what are you concerned about memory usage, overhead.

C

um For the cash I'm concerned about memory usage overhead, because, like someone, spamming updates to the same object, um will actually get compacted out of etcd, but unless we limit the cash to roughly match like the number of objects in a CD um like it, you could do a lot of a lot of Rights in like an hour uh and so like thinking about what what's our Max QPS. What's a ballpark like Max, writes per second, how much overhead is there per key.

A

um Yeah so I have I can paste these numbers into the um doc, but, like last numbers I collected, was that when on the right so where you can't have a cache or anything or at least not easily, you go from six allocations for just regular AAS GCM to 32 allocations.

A

So it's not free by any means um and and then you go from like 42 000 nanoseconds to 96 000 nanoseconds. So it's like twice as low but I mean it's we're still talking 50 000 nanoseconds, which I forget.

I

We also have a number of other, egregious.

H

um Performance issues like not issues, I guess because nobody has noticed them, but we are so lacks in other places that.

A

I

Feel like uh examining this in isolation is.

A

Kind of makes my makes me scratch my head.

C

The performance on right, I am far less concerned about the performance on read um if you're going to do a global list and we're paying this overhead on every read of every object, that's way more concerning which makes me think we need some sort of cash, and so then my main goal for the cash is to not let you own the servers so.

H

The in we store encrypted data in the Proto for kmsv2, which means every time we deserialize a record. We have to copy encrypted data from the object, rather.

I

Than if we had started as like.

H

The object as a prefix and then the data we would not have that extra copy. The other thing that we do, which is um uh not great for allocations, is for every runtime unknown in protobuf encoding. Whenever we serialize that we do a full copy of the.

A

Proto message as a reminder: Mike this: this code path doesn't go through that. Why.

H

Does this code that.

A

The first part it doesn't go through the standard, runtime decoder stuff that we have uh so.

H

It is eventually.

A

It does when it goes.

H

Yeah or the actual object, yes yeah so like both of those are like full object, copies I think that if we want, maybe we should revisit putting the encrypted data.

I

In the Proto message and storing the proto-message as a prefix.

H

To decrypted data.

I

If we don't want to.

H

um Copy that every time we read.

I

Which was the behavior of V1.

A

I see what you mean: I think yeah, okay, so like. If we just if we were treating as raw bytes, we didn't have to put it in like a struct and yeah.

H

When we deserialize on Marshall with Proto that data is going to get copied.

I

Buy for bite into the Proto object and then we're gonna I, don't know what your implementation does if it does in place an encryption or not, but then that has to get copied again from cypherdex to plain text. So um we can reduce the number of those copies down to just reading it from SCD or whatever, um and make back everything that we lose by doing this hkdf. But.

A

Then we lose all the nice structure and stuff that the product gives us yeah.

H

If it is important to you, then there are like other places to look to get.

I

um When we're banging for your buck, yeah.

C

So maybe it seems like there are two two things to investigate there.

C

One is to make sure that the benchmarks that we have that are saying: here's the comparison between GCM and SIV, make sure those benchmarks or or have a benchmark that captures more of the operation that we actually go through when we read the object from a CD so that it would sort of show what Mike was talking about in proportion like yes in isolation, the GCM goes from six applications to 32 allocations, but this is part of a bigger operation which involves 10 000 allocations like that would be helpful to know for context.

C

But I, don't know, I, don't know what those numbers actually are.

A

Okay, so like Benchmark, like a complete like read or, and that's your right from that's uni, with real, like YouTube secret data or something.

E

A

Okay, that's fine I can I can I can take that that makes sense. um So let's say let's say that the benchmarks are fine and the performance is acceptable, so we're kind of we're. Okay, with this approach, barring our crypto friends telling us that we're doing crazy stuff, basically.

A

I don't know what that beep was. What's that beep saying, let's move to the next topic: okay,.

F

10 minutes to my next meeting, ah basically.

A

uh How about I see you on the call? Did you want to talk about your thing.

D

Hi everyone uh nice to meet you all uh sorry to interrupt the the sake of meeting it's just um related to. um We I think you have a repo called SEC ask tools. uh This uh reboot, just you know like to have uh some GitHub actions to run to monitor them. The dashboard for the third class- and you know like other stuff like that, and we would like to uh you know like make it more General.

D

So, instead of um we wanted to reuse it, so instead of just duplicate or replicate the repo for scheduling uh we would like to just um see if this is okay to rename the the repo name and make everyone everything can just contribute one file, which is the GitHub action instead of just um you know like own and maintain a separate trip over that, because I know we have a problem across uh the organization, kubernetes organization, that uh we cannot uh create GitHub actions and kubernetes uh repo.

D

So I believe this will be like a good solution for now until we figure this out.

I

D

Make sure what do you think about that.

A

So for context, the cigar tools, repo, has a GitHub action that looks across the entire kubernetes or at all, the issues find the ones that have the Sig auth label and it adds them to the GitHub project board for sagot.

A

So that way we don't have to go, find them ourselves and when people make random issues in like the cube, CTL repo, we actually noticed instead of ignoring it for months or years at a time, um and the reason that that's the GitHub action is even though we use the latest and greatest GitHub features in our project board. You can only tell a GitHub project board to automatically add issues from one repo. You can't tell it. I want everything from an org.

A

Yeah I have asked the GitHub project sport PM about this before by the way. So it's not that they're not aware, um but that's what it exists to do um for context. Yeah.

D

And this is great and actually I feel, like. You know like that. This. This will benefit like everything, because uh you know, like um you know like having everything in Just One dashboard. It's great. We had the same issue in release uh team and uh we had to go through like creating a new job. You know like uh with, uh with you know, like special straps, to run it in Pro, and you know like having it uh updated every every release, title but I believe we don't need that here, it's more easier.

D

You know like if we just have a GitHub, Action, Scrap, uh the whole org and just put the issues nprs in the dashboard.

C

um So one or a couple of thoughts uh does contribex have any repo that has like generic tools and helpful things for sigs to use.

D

Not yeah not yet, but uh we uh have been told that we can contribute this back to contribute X once we have it like. Generally. Okay,.

C

um Is the is the intent for this repo to evolve to be able to have more than one GitHub action like I? Think today is if I'm reading it correctly. It's like one action at the root yep.

C

um So would we want to I'm trying to understand if the goal is to have like a repo four actions, and this would be like the first action, uh in which case it might make more sense to start a repo four actions and like copy the code and its current state into that repo, rather than trying to like rename it and move it around. I I, don't know yeah.

D

This is my suggestion. Actually it's just to have a Depot with multiple actions. For now we have this reboot with just one action for now and uh a code that you know like uh script, that the organization uh so yeah, but it would be great if this is a good idea to generalize it, because we need it from time to time.

C

um The night, the second thought I had the nice thing about this repo is, we have exactly one consumer and it's all folks, and so the only people touching this are all folks, and if we break something, then it only affects our project board and like we're on the hook for noticing and fixing it as soon as you have one action being used by a bunch of cigs. Now it's like you have people contributing to that action and it impacting edge cases in other cigs, and so so you have a lot more requirements around like.

C

How do you test this thing? How do you notice that you broke everybody like um so.

A

I, like the idea, is no testing dude, it's like it's a ghost script and like, but.

C

That's the thing like it, it runs and if it breaks it, screws up our project board and we notice and we have to go fix it by hand like as soon as it's a thing that other people can contribute to now. I I, don't know if everyone who's contributing to a you know, shared thing even knows it's being used against the off board and is able or willing to go fix up the off board by hand if it breaks. You know.

D

I I guess your point: you'll have a total valid point, uh uh but again I I, just you know like trying to reduce the number of freebies that we are creating just for the same. The same thing it's like I will, just you know like Fork the reboot, rename them rename it and have to maintain it by myself. It's everything the same code, the same everything we can add. We can add like this is what you know like this.

D

This piece of code or this piece of script does one two three and you know like: if you wanted to create a new thing, you can, you can contribute a new one, but, and everyone can can create its own um uh set of GitHub actions and separate this folder under dot, GitHub folder and uh it's like maintained by the seglets or the SEC. uh um It's.

F

It's like yeah, it's it's a perfect.

D

C

A repo to have a structure like that, where, with a folder per Sig, where, like a home, a natural home for a code like that, makes sense to me, I'm, not sure that renaming this repo is the right way to get that or if creating a repo, a single repo like that and then having a folder per Sig and saying you can drop actions in here. And maybe if we had that we would drop, remove this action into there and turn down this repo I. Don't know.

D

Okay, so your suggestion is to start a new reboot, just you know like to hosts something like this and you can move if this is okay, but for now I will just create a new review right. Maybe.

C

uh Like a single repo that can be used by multiple cigs to run GitHub or host GitHub actions makes sense to me um instead of having to create one per action per Sig.

D

C

um Yeah the I would lean on, contributes and test in for folks I know. You said you had done this as a prop plugin before and it was painful.

D

It's not, but it's it's a long process uh and you know like um we can do that, but I feel like this is the the main thing for GitHub action. It's like like that and and I wanted to. You know like just revisit again that to open a door, for you know like GitHub action in a secure way to just start to use it and and the org, because it makes a lot of sense and it's it's easier to be honest, but again uh I I've done this already info.

D

So it's if this is the right way, I'm totally fine.

A

uh The other sort of data point I wanted us to consider is I, think they're at least for right now. The reason that we have this action is just because of the missing feature in GitHub project automation, presumably they'll eventually get to that and have it, and then we won't need this specific action anymore. uh How about do you have other things that you need to automate with actions that are like different from this one.

D

Right now, right now, no I just wanted to make sure, uh maybe maybe in the future, we can have like more automation, like you know like if you have this label uh move it to. You know like uh need, need review, or you know like. uh We need approval stuff like that. It's, like uh you, know like more more organized dashboard, but what have what we have today? This is more than perfect. This is all what we need right now, but again in the future. Yes, we we can, especially in sex.

D

You know like we have a lot of work groups and uh we might need it uh I, don't know, I, don't have anything in my mind. Right now,.

A

Okay, um yeah I, I, guess I I, don't know I, don't have a super strong opinion, I'm kind of happy with whatever uh it uh I I'm, basically happy that I got an issue to rewrite this from a bash script in the go code because to me bash makes my eyes bleed and go. It makes me happy so here we are I. I've already succeeded in the goal: I had yeah.

D

Yeah one more one more thing to you know like to love Anish, so yeah I love this uh okay, so I will go ahead and I will um propose this to contribute X and hopefully it will be okay, otherwise uh yeah I will just create my own.

D

A

Yeah, but we are over time, so thank you, everyone for your time and I. Guess we'll see you all in two weeks.