 Okay, so next up we have Rita and she's going to be talking about some really cool stuff with Kubernetes. So a round of applause for her. Hey everyone, I'm Rita. This is my first Fossum, so yay. So thank you for inviting me. So I know this talk is about Kubernetes and GRPC, so I kind of want to talk about why I submitted this talk, because prior to working on this project I knew how GRPC worked in theory, but then I didn't actually saw a lot of implementation in the wild. So I was like, okay. And then as I looked at this project, I realized actually Kubernetes used GRPC quite a bit. So just to recap, right, so what is GRPC? Well, when I first started, I knew that a lot of people really liked it to build distributed services because of its ability to simply define a contract and enable developers to sort of have their client application to invoke methods from a server application, regardless of where the application is running, what language you actually write it in. So it's quite powerful. And then I started looking at Kubernetes, and as it turns out, Kubernetes used this a lot in the code base. And one of the actually benefit of it is, as we just talked about how big the Kubernetes code base is, so one of the benefits of using GRPC is actually now Kubernetes can have this one single contract and have all the providers to write the implementation of the server side application individually, regardless what language they want to use, and they don't have to all live in the same repository. So that is really, really, really nice for the Kubernetes maintainers. So that's sort of what I'm going to talk about, and specifically I'm going to use the encryption, like how Kubernetes actually used GRPC to invoke external key management services to provide the encryption of its Kubernetes data. So what is key management service? So key management service is cloud operated managed service. So you think of your Google KMS, Azure Key Vault. So these are sort of managed Key Vault solutions that a lot of enterprises use. It's enterprise grade, and a lot of them offer hardware, security module, protected keys, so that a lot of the companies can just go ahead and use these managed keys for encryption and decryption. So a little bit about myself, I'm a software engineer at Microsoft. I'm based out of San Francisco, so I'm still a little jealous, so just bear with me. So pretty recently, I joined the Azure Kubernetes service team, and specifically my job is to bring Azure features upstream to Kubernetes. So when you guys run it on Azure, you have a good experience. So I'm also the core maintainer for the solution that I'm going to talk about today, which is basically the Kubernetes KMS plugin for Azure Key Vault. So maybe let's start with the problem. Why do we even do this, right? So I don't know how many you use Kubernetes in your company. Okay, cool. So I don't know if you remember this happened pretty much early last year. Apparently some hackers got their hands on Tesla's Kubernetes cluster, and when they got their hands on their Kubernetes secrets, as it turns out, a lot of people like myself actually store our cloud credentials as Kubernetes secrets, because that's how the cloud providers can actually create resources, whether that's your load balancers or your VMs, or maybe like you want to store some of your stuff in S3 or something, right? So this is a very common practice, right? So this is exactly what happened, right? The hackers got their hands on it, and then they were able to basically use Tesla's money. They were basically able to like mine cryptocurrency with Tesla's dime, so it sounds pretty cool, right? No, no, not really, so don't do that. So of course now you say, well, how could this even happen? This is like enterprise like stuff, right? This shouldn't happen, right? Well, let's go to some of the basics. So what is a Kubernetes database, right? So Kubernetes actually uses SCD to persist a lot of the Kubernetes objects, so think of your secrets, your config maps, they're actually stored in SCD, and I don't know if you guys know this, but a lot of the content, specifically Kubernetes secrets, are actually stored as base 64 encoded plain text, so if you look at SCD just plainly, they're actually stored as plain text, even though when we do kubectl get secret you can see it looks like maybe it's encrypted, no, it's just base 64, right? So a lot of people didn't actually know this. Now let's talk about SCD. So I didn't know this until this guy wrote this really insightful blog post, and he basically talked about out of the box, SCD, especially before SCD 3, you didn't even actually need a client or key just to talk to the API. So anybody who had access to your SCD on port 2379 and know the API, they could pretty much look at all of your stuff that you're storing in SCD. And that's basically what he did. So he basically did a search on Shodan. So what is Shodan? Shodan is like this crazy search engine that basically goes across all the endpoints, a popular like port on the internet, and I highly recommend that you do that too just so that you can see how crazy this stuff is. So anyway, so in his blog post he wrote like he did this whole thing and he wrote some scripts that basically just aggregated all the data that he found, and sure and behold, there's like all these AWS secrets, right? And then you could like not to mention like cloud resources, but these are probably also like confidential like user data, right? So I got curious, I was like, what if I did it myself, like would people still, are people still this dumb, like do they still do this? Well, yes. So I did this query like a couple weeks ago, but basically I used Shodan to search on 2379 and this is like some poor guy's like cluster and you can see like this is like Docker registry keep like password. So yeah, really scary stuff. So in summary, right? If an attacker can somehow successfully get to your SCD database, whether that's through API or the SCD CTL, you can pretty much access like a lot of the data in there and specifically your cloud resources. Now you might say, okay, this is really, really bad, what am I supposed to do? So there are definitely some things you can do to keep your data safe. So as I mentioned before, make sure you're running SCD v3, make sure you're using like client service and keys just so that your operators have those things in place when they actually authenticate themselves. But what I'm going to talk about is the reason why we wrote this thing in GRPC is like the community basically came up with like a KMS provider plugin mechanism and it's designed with GRPC implementation such that you can actually use like the latest and greatest enterprise grade level KMS services that are offered by these giant companies and you can basically use that to encrypt and decrypt your data in SCD. So even if your operator actually gets, somehow they get access to the data, it's actually not plain text, it's actually encrypted and only if you have the key then you can decrypt. So let's talk about like how does it actually work, right? So let's talk about what happens when you create a Kubernetes secrets. So when you run this command, traditionally what happens is this data basically gets stored in your SCD via the API server. Now with the KMS provider, what ends up happening is instead of having the API just storing it in SCD, what it does is it basically hands off that encryption mechanism off to the KMS provider. And as I mentioned earlier, this process is written with GRPC. So in this case, the API server is the client application. And then the provider, whether that's Google KMS or Azure Key Vault or AWS, they all write their own provider. And that provider is its own implementation and they can write it however they want, right? As long as we all use the same contract. So once that request is offloaded to the KMS provider, then the KMS provider handles the authentication and the actual encryption and decryption methods. And then after all that happens, then the encrypted data gets stored in SCD. So here's an example of what your configuration file looks like. So you basically just have to tell Kubernetes, hey, I want to use KMS provider for encryption and the endpoint for that particular plugin lives on this unit socket, right? So this is how you tell Kubernetes to talk to this endpoint for the server application. Okay, so let's look at the implementation. So this is the GRPC design, right? And as I mentioned earlier, as long as the server side and the client side agree upon some contract, the actual implementation, as you can see, can be in whatever language they want. And they don't even need to be on the same machine. And so for this particular solution, what ends up happening is, again, the API server acts as the GRPC client. It says encrypt and then it actually invokes the encrypt method in the KMS provider, which is reachable via the unit socket. And then the KMS provider then hands off the request to the external KMS, lives in the cloud somewhere. All right, so here are some of the components. As I mentioned earlier, so you have the contract, which defines what the particular, what are the methods, what are the APIs that you want to offer, right? And that's defined in this proto file. And then you have the server application, which acts as the GRPC server. And then the client code, which in this case is actually the Kubernetes API server. So if you want to write your own KMS provider, what you end up doing is you basically write a new GRPC server. You define how this particular code is supposed to connect to the external KMS. You provide the mechanism to authenticate. You tell the KMS which keys you want to use for encryption and decryption. And last but not least, expose yourself on that unit socket. So yeah, so let's look at the code. I can't find my mouse. Okay, so as I mentioned earlier, so inside of Kubernetes, this is basically the contract, right? And then as you can see here, this is where we define, here are the methods that this API, this service should have. And then the same contract also lives on the server side. So in this case, as I mentioned earlier, this KMS provider lives completely off of Kubernetes in its own like repo. And as long as the two have the same contract, they're able to invoke each other. And here is the, and here inside of Kubernetes, this is basically where the API service is acting as a GRPC client and connecting to that endpoint via that socket that we provided in the configuration file. And then once it's connected, then it can basically do decrypt and encrypt and all these will basically be triggering the remote KMS provider. And then here on the server side, on the KMS provider side, this is actually what is happening when encrypt is called. And it basically does a handoff to the remote KMS. So yeah. And then this is where the server actually gets instantiated and actually listens on that endpoint. All right. All right. So just to show you what the data actually looks like. So this is a cluster without encryption. So as you can see, when I created this secret with Qubectl, I said, okay, the value is my data. And then here with the SCDCT command line, I'm basically able to look at the raw data. And as you can see, it's stored as plain text. And here is the plain text, right? And then here in a different cluster where encryption is enabled. And as you can see here, it's already enabled. And then it tells Kubernetes where the endpoint is. And then when I use SCDCTl to look at that raw data, as you can see, this is encrypted data. All right. So in conclusion, so this again is a demonstration of how GRPC was used inside of Kubernetes to basically offload a lot of the provider-specific logic, not in tree but out of tree, right? And then again, the nice thing about this is you can keep all of the provider-specific logic separate that from Kubernetes. And this is some links in case you want to check it out. And then just see how it's actually done at the code level. That's it. So we do have time for some questions. So any questions? Raise your hand. I'll come find you. Oh. GRPC scares me. How do I debug this? Because it looks like it, like, I used to see JSON, but there's no JSON. So if I, like, debug this, what would I see instead? So the question was, like, how do you debug this? So one thing I do is, like, I actually write my own client just so that I can look at, like, all the transactions that's happening. So my unit test, like, my end-to-end test actually includes a client. So I'm actually, like, acting as Kubernetes in this case. Yeah. I hope that answers your question. Really cool presentation. I like seeing the code examples. One thing I noticed during the code examples is that you have the proto file in both the Kubernetes repo and in the repo of the plugin. How do you keep those in sync? That's actually a really good question. And one of the, like, documentation, so, like, in Kubernetes documentation, this is, like, telling you how to, like, write a KMS provider, and they literally say take that proto file and, like, generate your own, like, service files. So I don't know if that answers your question in terms, like, how to sync it, but in theory, though, like, to write one, you would have to, like, get it from source. And one thing that I know will happen is, like, when we change a version of the thing, we will need to, like, keep that in sync. And so I think the provider will have to do that. It is a contract after all, right, so. Hi. Thanks for the talk. I would like to ask, do you pass the whole data to the KMS to be encrypted, like the whole content, or just create a random key in front of it and just encrypt it, like a master key? That's a really good question. Oops. Okay, it's okay. I wanted to, like, show you the code. So this actually calls the, like, the Azure Key Vault SDK. And as you can see, it gets the key. And then here it, so it's using the Key Vault, like, Go Client to, like, encrypt. And then that's the result here. Hold on. And then here, as you can see, it's the value, like the data is in the value. So it does, yeah. Sorry? That's right. Yeah, but, yeah. But that's how the SDK will handle, like, that's what it expects. Yeah, yeah. Any more questions? Nope. Okay, so thank you very much. Ronald Vlaspar. Great talk. Okay, and in 10 minutes we're going to start with the landing talks. So if you're a landing talks speaker, please calm down and sit there because we're going to go quite quick. A proof for, so do you have, we're going to follow it here real quick, if you want to. Is it something that we get it, or instead of this one, right? Yeah, but I think it's a little, kind of, it is English type. It's faster. Otherwise we're going to have to do switching again. Cool. All right, so I'm just going to do that, go get on that too. So now if I do a present, is that a thing? Yes. And then we're going to go to this. All right, so, all right, so that's not there, so, all right. So that works. We'll present and then open that. And then examples, talk to class. Cool. Oh, yeah. This is not the correct one. Oh, yeah. So when is your talk? Your talk is? So it's the first one. Okay, so let's see. Examples, this one, of he, me, made it. And tricked them all. Possessed, unobstructed, unobstructed. Unobstructed is not a, I think it's a word. JavaScript, JavaScript, is not the full of our emphasis. Function, fun, coroutine, coroutine, coroutine, coroutine, coroutine, coroutine. You good? Cool. All right, so then I'm going to change that way. I'm going to do a present. And then, again, this open it instead of the PDF. And then go. Yeah. And then we can switch. For all of the Lightning Todd speakers, you're going to be using my laptop. I have yours lights. So, except for you, because you're special. We know that. It's fine. Oh, okay. I'll see the numbers. I'll help you. I need your help with something. I'm sure you can help with it. Is it? I always, I've mispronounced your name for several years. I can't do it anymore. Is it? Okay. So I, I'm kind of close. I accept everything you say. I understand that. So I, I'm kind of close. I accept everything you say. I understand that. It's not about that. It's about I can't take it anymore from myself. Some after. Yeah. Yeah. Okay. So for the Lightning Todd speakers, this is the order we're going to be going. So I don't know. Do whatever. Like that is the order. And we're going to be starting very soon. We're going to be starting in four minutes. Actually, we might start like two minutes early or something. So the first speaker, Rashminak Ba. I'm going to need you here. And we're going to start in a second. I was going to say if they're late, I will throw them a gopher, but that one looked dangerous. So no, you can come here. Even if we start a little bit early, it's very fine. Because that way we have more time. So if you're very, very sorry. Timer, four minutes and a half. Okay. Whatever. Cool. So run of the plus for the first talk. Rashmin in the slides are here. Hi, everyone. I'm Rashmi and I'm a software engineer based in India. So my top title is go for the JavaScript developers. So let's get started. Go is like the sea and the python has a kid. So it's a common saying that go possesses the confidence and athletic ability like a sea and it has the good looks and the pleasant eminor like a python. Okay. Okay. So what exactly is go? It's an open source compiler and garbage collected concurrent system programming language which has blazing fast because it has a young compiler with minimal speed optimization so it has a strict compiler and so it's something like the things like unused imports and the unused variables or hard compile errors in go and it possesses clean and elegant syntax. So what are the similarities between the go and the JavaScript? So both uses the garbage collection and the variables and the functions they have a specific scope and in similar fashions they define the variable structures and for loops and if statements. What are the major differences between the go and the JavaScript? So JavaScript is a single threader that has the main thread which does this event loop and there are several other threads which do the external input output while in the go the concurrency is the king in the sense that it has the go routines and the JavaScript is interpreted language the code is compiled before it's trans while go is a compile language and also in go we can have multiple return statements that is if you have let's say an error called 500 internals of error or something like that particular functions can return the multiple error codes so it's very consistent and it's easy to maintain so basic rules that the lines don't end with the semi-colon and so it's a a very simple example is the declaration of the array of size 3 which has integer values 1, 2 and 3 and there is a comma at the end of the 3 and the basic types like where num end is equal to 5 so it says that the variable name that is num it's been declared before the data type itself so in similar fashions the for loop and the by loop the similarity between C and those of them is they don't have the parentheses and in the same way the flow control that is there is no parentheses in the if statement it returns false when the age is less than 18 so there are some of the advanced features in go that are the go routines which I already talked before that concurrency is the king in the go routine is basically a lightweight thread which is managed by the go runtime and so here go function and the ABC are the 3 parameters so what happens is the function and the evaluation of the ABC will happen in the same thread itself while the function the function will be executed in the different thread and the channels they can be thought of as the pipelines or the pipes like in which the go routines themselves communicate and they also possess a type associated with it that is the data which is allowed to transport to that particular channel and it's been declared using this operator that is a channel operator here we can see in an example that channel V is being sent to the channel CH and similar way and how we are assigning the value to the V is I mean that channel received the value from that particular channel and assigned it to do a variable that is V and the personal take away is that those have not yet started with the go it's never too late to start something a new fresh all it takes is practice patience and perseverance I really want to thank Arlan, Rita and Mathiche for helping me I mean getting introduced to the go language and thank you for inspiring me a lot