 Hello everyone. Let's get started. My name is Carlos Fanato. I work for Chenghua and in Kubernetes I work for SQL Release. SQL Release is the SIG that takes care about the release of Kubernetes and all the tooling around the release engineering, like for taking out the images, promotions, and all the tools that make everybody use the Kubernetes environment. My name is Carlos and I'm going to pass to my colleague. Yeah, my name is Adolfo Garcia and I am also a software engineer with ChengGuard. We originally had two more speakers scheduled to be here with us and for traveling problems they couldn't be here, so sorry you're stuck with us but we are both tech leads for SQL Release for the release engineering sub-project and we're going to do an update on the things we've been working on. Before that we have Sasha just to give you like a few words. Welcome to our talk from SQL Release about releasing Kubernetes as often insecure. Unfortunately I cannot attend this KubeCon in person but I'm absolutely sure that the both of Carlos and Steve will rock this session on behalf of Cherryby and myself. I really hope you enjoy this talk and always feel free to reach out if you have any questions or comments. Okay, today we're going to like give some updates and talk about what we did in like in the past release and let's say in the past year. We're going to like take like a quick look on the changes we made for the release caddes in the release cycle and some updates on the release engineer and we're going to like share about the work we have been doing like creating a whole map and vision in the SQL Release and like in the end some shots for the community. Last year we had like a release caddes of like a form release per year and we felt that it was too fast and like the release team that is formed for each cycle was like have like a hard time like to manage everything. Then we decided to send a release survey to see how the community feel about like having less or more releases and we find out that like the community prefer like to have three releases a year than we like that's some justification that we can think about and we decided to instead of four release per year now we were running three releases per year that makes like a pace more sustainable for not only for the release team but also for now the other things. Last year we introduced in the last cycle in the 124 the faster forward and this I'm going to give like some explanations. But a few cycles like I think till 121, 122 when we have the code freeze and create the release branch we always fast forward in the master branch to the release branch. Then this was a manual task and like sometimes like we forgot to fast forward every day and then we miss it and then some conflicts sometimes happen and then like we decided like not doing fast forward anymore and then doing the like when the cherry pick or the release branch was created we started doing the cherry pick like when we merge things to the main branch we cherry pick to the release branch. That causes a lot of like a overwork like a lot of overhead for the developer like for the contributors who every time we need to like approve that PR to get merged to the master branch and then like cherry pick, mainly cherry picking all the process. Right and then we think to reintroduce the fast forward and then in the last cycle we did like a like a mock job that is was running for the entire cycle after we have the release branch and everything was working and for this 125 release cycle we are going to like introduce the no mock in the no mock way that's going to be fast forward for it. We have the test grid everybody can take a look on the job is running and we also have a documentation regarding how that works and if people are interested like I strongly recommend taking a look on the documentation site. Okay yeah so another area of our work has been actually hardening a little bit the more the Kubernetes supply chain and since what about two years ago we started working on implementing some of the what are now common words in supply chain security like a response for the Kubernetes release process and also the big one around now is that we just finished signing all the images for Kubernetes with six stores so about what one year ago or so where we started right about the point when six store was just starting to form six stores like a distributed signing project for with a public transparency log and we started partnering with them to see and to try to find a way of how we could also implement signing our images for years there have been like issues open and gaps open trying to implement signing for the artifacts but we all know how GPG can be hard to secure to do the key handling sometimes so when we started seeing about what was going on with six store and their plans and it just seemed like the perfect fit for us so right since the beginning we started looking into how we could integrate the six store tooling and libraries and their infrastructure to secure a release so right so now Kubernetes 124 was just released and it's the first one to have its images signed and it was like a really huge effort it took a lot of contributors in fact since I joined six releases the project that has seen the most people contributing to a single project this is just the MVP because we only have the we only have like the basic initial tooling to sign the images there's still a lot of work that has to be done yet so you can see some brief facts about it we had like 55 PRs involving not only the sick release tooling but also dealing with in Kate's Infra so big thanks to Kate's Infra folks that really enabled us to get this going and also working on improving the six store tooling as we went because we also had needed the support from their side and to accommodate their needs but we finally got it ready some of the challenges to build that was the infrastructure was to make sure that all of the signatures could be propagated in a proper way like doing the impersonation flow because Kubernetes promotes its images and the image promoter wasn't ready yet to take on the impersonation requirements that we needed to have the available OIDC tokens to do the signing so we had to go do there and add up to the current image promotion process which we didn't want to disrupt any of the current process that we were using so it was like a really big deal I was really surprised to see how much fire it's got on all of the news outlets so thank you media for covering that I feel really humbled for that if you maintain a project in the Kubernetes community and you want to sign your images on your packets come to talk to us about where I plan to help and the image promoter also like if you use the image promoter the images across the case registry it also sign your image already then if you sign like three weeks if you start using that tool it signs the image for you as well there's a little bit more security that we can build into your project if you're interested in signing at build time and still propagating those signatures like we do in Kubernetes you can talk to us at any time show up on the sick release meetings and we can guide you to do that the other is when we build the Kubernetes S1 we produce a lot of libraries to be able to write the documents and that tool has been getting traction some other projects are already doing their S-bombs with our tool which is great and we've been getting more contributors and for example Istio recently started doing their S-bombs with our tool which makes me very happy and also this tool is now incubating in the automated compliance tooling tack with the Linux foundation also like a sense of it getting a little bit more mature and finally the other key milestone that we are trying to achieve is making the Kubernetes release process achieve Salsa level three so Salsa it's a supply chain framework to enable companies to start securing their workloads and their release process a little bit gradually so it gives you insight into observability and then making the artifacts ever more hard to personally forge and secure them so we are aiming to comply with Salsa level two right now the last cube gone in Los Angeles we announced that we have reached level one and now with assigning libraries almost done we are almost ready to start implementing Salsa level two we wanted to make it in Kubernetes 124 but well we simply didn't get the time but we're almost there we just have to finish signing the binaries the attestations and the S-bombs and then I think that those are the three remaining for reaching Salsa two that is release process and oh yeah this was it okay and next one okay this is another survey we have out like we have the inclusive name working group we are working to make out everything more inclusive and one of the fortresses changing the branch names across the Kubernetes community we are planning to change the KK the Kubernetes Kubernetes branch name from master to main and this is like a big thing that we are planning size end of last year there is a survey you can scan the QR code if you want to fill that survey and we are like collecting results like information because we would like to know the companies using Kubernetes downstream to see if they're going to be impacted and then we can plan accordingly for like changing the name how the most how the infrastructure for these changes are done we're just like waiting for these results they're going to close on May end of this month and as soon as the results we like got it is looking good for those persons like for those companies and we are planning to moving like the change is for the when we reach code 3 on 125 okay here I'm going to talk a little bit about how we built last year the roadmap and the vision you can scan this if you like check the repository I'm going to quickly show here we in the C-release we built like a roadmap and a vision that makes the community and the C-release team like everybody that contributes to C-release see what's the vision for the C-release and what are we going to focus in then we have like the primary focus is the consumable introspective and secure each one we like drill down and open in deliverables we are looking for for example we like define some deliverables you want to achieve that is the Salsa compliance the sign release effects enhance the Kubernetes artifacts management like we like we are working in some improvements on the artifact management as well and be available in the other providers as well and we highly recommend for the other SIG chats and techniques for the other SIGs to have a whole map and a vision as well for the SIGs and if you need help like we also we are here like to help to create the whole map and a vision and just a small thank you for everybody that worked like in the past cycle in the past year helping us to achieve the signing the Salsa, the boom and the other tools we are using like to make the Kubernetes release easily for everybody if you want to find us and we want to contribute like find us like we Steven and Sacha the SIG chats myself although for Jeremy the techniques for the SIGs as well you can find us like we have weekly meetings on Tuesday I forgot the time I know the time only in the Central Europe time as well which is 4.30 I don't know the others but I figured it out and you can find us also in the SIGs that we have the SIG release channel and if you are more interested in the SIG release engineer in the engineer part we have the release engineer channel and Sacha Thank you for listening to our talk I truly believe that we will have a bright future of SIG release with all those enhancements and improvements I wish you a happy concurrence and see you on upstream Kubernetes Thank you The question is what the challenging about renaming the branch for Kubernetes itself if you think about the only Kubernetes we have like we can check I think we have more than 50 PRs open on KK or I think is much more than that and renaming like changing the the branch name it's kind of easy just go and go to the sets and change and they do everything for you but the problem behind that is if we do this we're going to pro, we're going to kick out all the jobs for the open PRs and then we're going to be like a big kill whether it might be we have some hard time cleaning up we don't want to put this high load on the pro and have the people try to figure out there's some workarounds for that we're going to move everything that open PR to draft and draft to the pro doesn't trigger we need to trigger mentally and then we're going to like ask for the persons that review like move back to red to review and then we're going to kick the specific one we're not going to move to draft and then move everybody we're going to just move one by one as needed for downstreams we can block the CI but Github offers the follow the right directions but you need to certify in your downstream if you can follow that right direction usually just change the branch name but might block CI for the companies like we're not sure how they are consuming the Kubernetes when do you plan to do that branch? when we reach code 3 is only 125 it also going to depend of the survey results but so far the results they are like the people are responding match the time frame we are looking for any other questions? nope ok thanks so much