 We're going to have over two more, so we're going to take care of that, I think, for asking. So, come on off our next speaker. Yeah, hi guys. How are you doing? Good. Okay, that's great. It's a bit rainy. So, okay, you know, I'm really glad to be here. This is my first Kubernetes Meetup in Singapore. So, and I'm twice proud to stand in front of you and start speaking about your topic. So, according to my plan, I decided to talk about HELL and is a reasonable tool in general. So, I decided to use the Shakespeare's classic and use this title like, to HELL or not to HELL, it's kind of a question for us. And I hope we will find the answer for it. And then, you know, I realized, we have some issues with liquor. Liquor is not working. Okay, okay. And you will next page? Yes, please, yes, yeah, yeah, yeah. So, you know, emoji is always fixing the problem in general. So, and then I realized that the topic for this Meetup is security and Kubernetes, and then I decided to focus on security in HELL. So, today we will talk more about security in HELL and how to make your HELL more secure. So, my first question, and by the way, I have this nice sticker spec, and I will share with you for the rights or just for answers. So, feel free and don't be shy to answer the questions. So, I will try to ask a few questions during my talk. So, the first question is for stickers. How many of you have used HELL in general? Let's try it. Wow, wow, it's a lot, really a lot. And how many of you use HELL in production? Wow, fantastic guys, fantastic. Okay, so, we're ready to share stickers. The next question. Okay, so, as mentioned, so my name is Alex and I am development lead here in Singapore in Chainstack. And, you know, DevOps is my passion. So, for more than eight years in IT and software development, I fully realized that DevOps is a really nice thing which help us to bring a better software for our customers. Yeah, that's really great. And I want to say a few words about our company, Chainstack. So, Chainstack, it's a multi-protocol blockchain and multi-cloud platform as a service which allows you rapidly create, manage, and deploy your decentralized solutions. And for this experience, our dev team use Kubernetes and HELL. So, it helps us to provide the service and, of course, we really love HELL and Kubernetes. And that's why I'm here and talking with you. So, by the way, we're searching for talents and hiring. So, if you're a system engineer or if you like DevOps, so feel free to find me or I don't DM me in Twitter or GitHub, so don't be shy. So, let's go to agenda. As I mentioned, we will focus on security topic, right? But before I decided to revise all information about functional HELL because I guess it's quite usual. Of course, I see that you heavily use these tools, but let's repeat it. Then I will show you and share with you some thing that I called hidden gaps in HELL. So, it's nice tips and ideas that you can try today. Then we'll focus on security. And finally, I will wrap up my talk with the future of HELL and we'll mention a few alternative tools. And, of course, we'll be happy to answer any questions at the end. So, HELL, right? I guess you know what will be next. Who can guess? And I will share sticker part. So, just raise your hand. Oh, I see, I see. Till then. It's maybe wrong, but you will have a sticker part. Like a first person, you know, first time, first household. By the way, it's crude, I mean. So, let's start from Joe. I guess you know that what is Kubernetes. Let's improve the problem. What is Kubernetes? Who knows, guys? Don't be shy. Okay, see? Yeah? What is it? Okay, that's good, that's good. Thank you. So, okay, the correct answer. What is Kubernetes? Kubernetes is, okay, we have another option. No, no? Yeah, please. It's super complicated, but you're right, I guess. Okay, okay. So, yeah? Well, that's great, yeah. So, okay, finally, correct answer. What is Kubernetes? Kubernetes is another abstraction physical level to deploy your WordPress. I guess, I guess you get it, I guess you get it. So, yeah, let's go to, no, let's go to Helm. Let's think about it. Let's talk about Helm. So, this is obviously package manager, right? So, it's covered by cloud native computer foundation. And, you know, it's quite interesting and popular tool right now. If you go to the GitHub, you will see that it's about one key stars. Okay, it's not a React or Vue.js, but it's one key stars for DevOps tool. I guess it's a nice, but it's not only a package manager. Helm addressed several needs. So, I tried to split it into four different categories or groups. So, the first is all solvers. It's packaging, you know. So, the next thing I call complexity management. How you can fight with all complicated things in Kubernetes partyfests. So, the next thing, it's a huge thing. So, it's application management in general. And how you can create your life cycle. And last, I call it batteries included. If you're not familiar with it, what is it? So, it came from Python and Django world. By the way, I really love Python, awesome and willing. So, it means that Django ships a lot of nice tools around the library in general and help you to resolve a lot of routine stuff. So, Helm also provides some nice ecosystem around command plan. Talking in details, of course, packaging, it's about creating your application and packaging. Packages, it's called charts. You know, you can create your chart, you can upload your chart to repo and you can download a lot of charts. So, finally, you can create your sophisticated application and define different package dependencies for it. So, that's it. Talking about complexity, of course, we have templating and parameterization, right? To improve the manifest of Kubernetes. So, talking about life cycle, finally, you've got your chart and you want to deploy it to the cluster. So, all you need is revisions, right? Because you want to repeat the section and sometimes you need to roll back it. So, the next thing is Hoops and application props. These guys help you to improve the control of your application life cycle. And talking about batteries, of course, it's a plugin system. So, Helm has a lot of, let's say, has not a lot, many different useful plugins and I will show one of them. But we will start with some real example. What if I decide to install some popular application to my new cluster? For example, Grafana. I guess you and you guys and me will go to Helm charts on the GitHub and try to find from the list Grafana, right? Maybe you will use some search, maybe you're like a guru on the GitHub and, you know, it provides you about 270 charts right now. So, they located in two different namespaces, stable and incubator. By the way, you need to, of course, enable incubator to make sure that you can search it using CLI. But, you know, I really love GitHub, but sometimes it's technically not so convenient way to find your charts. So, let me introduce Helm Hub. Who knows about Helm Hub? Wow, that's nice, that's nice. That guy's quite experienced, I guess. So, yeah, Helm, Helm Hub, what's it? First of all, it's a gorgeous interface. You see? You see? It looks really nice. So, you have search bar and the main thing that it brings you more than 460 plus charts from 15 different outside reapers. And really great news that you can suggest your own public reaper to this Hub. So, all you need is create a PR with your reaper, createreaperweathers.yaml in the Helm project on the GitHub and you can join this nice Hub. I guess it's really cool, so try it. It's really nice. So, another thing, it's Helm integrated with Open Service Broker. Who knows what is Service Broker? Wow, more people, that's nice. So, yeah, of course, the first question is what are Service Brokers? Okay, I will also show you the example. So, as you remember my job about Kubernetes, it's all about deploying your WordPress, right? So, we want to deploy WordPress in our brand new cluster and we have a problem. So, the problem is that we need to decide which type of my SQL and how are we going to deploy. So, the first option is to use Helm, of course, and find chart and install this chart to your cluster. But the question is, who will, let's see, operate and maintain this stateful thing inside your cluster? So, another option is to create something from your service provider or cloud provider, for example, you can ask for manage my SQL, right? But the problem is that we need to manually create this instance and then somehow store the credentials and put these credentials during the Helm installation. So, here is our hero. It's a service broker, plus some plug-in for your cloud provider. By the way, you can find service broker on Helm Hub and install it into your cluster because, literally, it's just another application for your cluster. So, service broker can, using plug-in to your cloud provider like GCP, Azure, or Amazon, for example, you can create and provide some flavor, what you need. Store credentials and then use it automatically when you want to deploy your WordPress. So, you don't need to create your own database inside your cluster. You can utilize cloud provider and reduce your manual work. So, somehow Helm helps to glue service broker and your cloud provider resources. I guess it's also a nice new thing. So, you also can try it. Just Google for service broker API integration and Helm. And the last thing about hidden gems, it's about repositories. I guess you know that Chart Museum is a default thing to create your public or private repository for Helm. But I want to introduce you a new tool, or kind of plug-in. It's Helm GCS. This plug-in can provide the ability to create your own repo and you can utilize authorization using Google service account or default credential. So, how it works. You can install plug-in from GitHub with standard command like plug-in install. Then you need to set up your GCloud and provide your service account to Google Packet or Google Storage. Then you can create and init this storage and then add repo. And that's it. I mean, then you can work it like with Chart Museum. So, also try this thing. Sometimes it's really nice when you don't want to spend a lot of time setting up Helm, setting up Chart Museum. So, it's really interesting. And now we're ready to go to security topic guys. So, every security topic, I guess it starts with architectural diagrams. And I guess it's a good tradition because we need to know about all components and how they interact each other. So, here we have a lot of arrows and I want to start with Helm Client. I guess you know this is your utility on the laptop, for example. And Helm Client fetched charts from Chart Rehab, right? Another thing that's hosted in your cluster, it's called tiller. So, Helm Client point through config and talks with your cluster with tiller. So, today we'll talk about these arrows and try to secure these communications. And now we'll talk about this in details. So, we're going to start with the first and super important thing. It's a hardback. So guys, you need to turn your hardback on. That's kind of mandatory stuff. I know it's kind of pain and yes, it can be really problem, I mean in general. But you need to do this and tiller of course supports service accounts and by default it runs with your default service account. But you can create your own service account for tiller. But one of the problem that you need to start with creating roles and role bindings manually. So, tiller will use already created roles and roles binding into service account. So, this is how you can change the permissions of your tiller because tiller connects and interacts with Kubernetes and there inside your cluster. So, continue this topic. You can ask the question, how can I create more than one profile for my tiller? And for example, I want to use more than one service account with different permissions. So, unfortunately, tiller doesn't provide your multi-tenancy by default. So, the solution is to create as many tillers as you want. So, you can place your tiller into specific namespace and then configure your Helm client, for example, for TMX to point to the specific tiller in the specific namespace with of course defined service account. So, you can create as many profiles and tillers as you want per developer, per team or in general per environment. So, the next thing, how we can secure release information. I guess you know that Helm stores the information about the release in objects called config map. So, by default, it's not super secure to use this. So, you can change this behavior and define the storage type secret and tiller and Helm will automatically use secrets instead of standard config maps. And here I have another question for my last ticker pack. So, the question is, why we have this limit about one megabyte in size for secrets and config maps? Sorry? Yes, you're right. So, yeah, that's really nice unsparing. So, technically, of course, in each CD we can specify more space. But one megabyte is quite a nice, let's say, number to work in efficient way with this data in general in GERPCs. So, they decided to use one megabyte. By the way, we'll have the same limit also for secrets, not for config maps. Okay, so it's pretty easy. Just define new type of storage during the process of it and tiller will use secrets instead of config maps. So, okay, let's talk a little bit about Charged Reapers. How to connect and communicate with Charged Reapers. Of course, you need to use HTTPS connection and expose your public reaper using HTTPS. So, the next interesting thing that you can sign your charts like you sign your, I hope you sign your pull requests in GitHub. So, it's pretty easy also. It's a PGP, so you can install this infrastructure and use sign charts. Also, tiller supports TLS, and you can define TLS certificates during communication with Charged Museum, for example. And Charged Museum supports basic auth. So, you can add extra layer of auth using basic auth. And as I mentioned, Helm GCS supports GCP auth. So, you can use this plugin to have your own private repo with auth. So, this is kind of my heart of Helm in general. So, this is tiller, and tiller supports native TLS or GRPC. So, by default, it runs without TLS. So, you can create your own VQI infrastructure, right? Create your certificate authority. You can use it by default and, of course, define these parameters in the client. So, it's also easy, and it looks native. So, please use it, and you will cover all scenarios where your tiller communicates with Helm client or Helm client communicates with tiller. It's more correct. And when your microservice from cluster communicates with tiller, also it's possible. Some guys use this technique to manipulate data during the continuous integration process. So, it's super important also. And finally, we see the secured picture. So, all of this arrow is secured. So, we can tune every communication. And it will be nice to do all this stuff. So, finally, that's it. And I want to mention a few words about the next version of Helm because it's really interesting. So, it looks like Helm 3 is the next big thing. I mean, community and guys after Simon decided to create a new document and proposal. So, first huge item. It's a single server design. So, no more tiller. I guess it's a great news in general. So, the next thing that Helm becomes more native for Kubernetes is, you know, CRD. Who knows, by the way, what is CRD? I don't have... Oh, okay. I don't have stickers, but I guess somebody knows. Okay. So, it's custom resource definition, right? It's the way how you can store your data by releases natively in Kubernetes. So, the next huge thing. It's supporting embedded log engine instead of golden templating. So, it's also, I guess, a great thing to try. Finally, we will have the ability to define the types of values. For example, you can say that my value, like, I don't know, it's a string or number, for example, it's quite useful. And finally, guys decided to refactor the whole model and use single event-driven model to different events. I guess it's a super nice. And finally, this is really great. But unfortunately, right now, the status is kind of design proposal document. You can read it. You can contribute it in GitHub, but there is no version. So, we need to wait a little bit to try the new version of help. And finally, I guess you know something about alternative tools and utilities. So, I want to be short and show you my, let's say, picture how it looked like in general. So, I tried to create some picture with the tool in two dimensions. So, one dimension is kind of your control. How you can control and integrate all these tools like Helm and Ksonet, for example, with the infrastructure. So, the other dimension is how it's native for Kubernetes. So, we'll start with Helm number two. This is the initial position for our graphic. So, the next big thing, it will be Helm three. It's more native and more control for you. Little bit more control. So, as you know, Ksonet will be somewhere here, I guess. It's just in my opinion. So, somewhere here near Helm two. So, your configuration management, I guess it's a quite typical solution to use Ansible Terraform or something with plugins to manage your Kubernetes and create applications. Of course, it provides you more control, but it's absolutely native for Kubernetes. And important player here. It's a core-res community kind of child. So, it's called Operator Framework. And I highly recommend you to Google it if you don't know about this and treat and try. So, it's also kind of the first step of Operator Framework. But it's more than one key start on the GitHub. So, it will be more native, I guess. And you will have little bit more control than Helm version two. And finally, of course, we have some add-ons like draft and scalp, for example. So, they, of course, improve the control of how you can integrate with your pipelines, with your continuous integration. So, they will add some more control. And it looks like this is the picture for alternative and Helm version two and three. And you can choose what to use in general. Yeah, and that's it. Thank you, guys. I'm happy talking to you. And by the way, sorry, sorry. I need to make a photo because my wife she asked me to provide some kind of proof that I'm not drinking beer. Sorry, sorry. It's just a formal thing. Just smile, Lent, I don't know. Raise your hand, something. It should be more than a selfie. Ah, yeah, yeah, because, yeah. That way should go. Yeah, thank you, guys. Thank you. Yes. Do you have any experience using Tiller's integration with HashiCode Vault? Oh, it's a great question, by the way. Yeah, I missed this thing. So when I mentioned that you can switch or try, let's say, using Compic Max with Secrets, the main idea that Secrets, technically I guess you know that it's also insecure at all. I mean, in general, the same idea. So nothing special, it's just the idea how to have one more name space for future to create some integration. So we start using HashiCode Vault to secure our Secrets. So technically it's integration with between, let's say, Kubernetes and HashiCode Vault. It's not about Helm in general. So the idea to provide Helm storage like a HashiCode Vault. So that's the idea. I think we got time for one more question before we move on to our next speaker. Do you have any? We got some Secrets. By the way, guys, we have more speakers. I guess so fine, guys, with a t-short chain stack. Ask them, please give me a sticker or just give me a sticker. Take it from them. They're going to eat all the well. Okay, so we got out of here.