 Hello. Hello, everyone. My name is Lenka. This is David and we work for Red Hat in the community platform engineering team. Our colleague Patrick was supposed to be here with us, but unfortunately couldn't make it. Today we'd like to talk to you about how we authorize OpenShift Hosted projects to the community members in Fedora. Why did we need to write a solution for authorizing OpenShift Hosted projects? Well, a couple of years ago we had a community facing OpenShift cluster called CommuniShift. Most of you probably remember it. Please, up your hands, don't remember of CommuniShift. Many, many people. That was supposed to serve for people to deploy, test apps, learn, experiment, get their hands dirty. And this cluster was retired as part of the data center move in 2020. And then in Q3, 2022, community platform engineering was tasked with solving a number of blockers, holding up the re-release of the CommuniShift cluster. This talk is not about CommuniShift as the cluster is not ready yet to be presented to the community. We're still trying to work through some legal blockers, which we as developers cannot influence. But while working on the CommuniShift, there were a couple of areas to solve and I would like to focus on the one, on the authorizing one. We needed the administration of projects to be self-service and with no or as little added work for the Fedora infra team as we had a lot of tickets being opened, regularly requesting access to systems. We also needed a way to sync Fedora account system and the cluster. And we needed this to happen automatically. Apart of that, we also needed the for the CommuniShift purposes. We needed to solve the storage and the quota, but that's not the aim of this work, of this talk. And the Fedora account system, API, requires Kerberos authentication, so we needed a keyed up. We decided to use the Ansible operator SDK, which provided us the structure of a Kubernetes controller. Then that we then completed with Ansible and Python that provided us the functions we needed. So operator SDK is a cooperative native application that consists of two parts. First is a container that handles the interface between OpenShift and operator and reacts to received events. The second one is the Ansible role and playbooks code which is run as required. These operators can then be managed by an open source toolkit called the operator framework. We named our operator CommuniShift authorization. It connects the FastJSON. Is all of you familiar with what FastJSON is? All right, so for those who don't know, I'll resume it. It's a JSON gateway, the query free IPA built for the Fedora account system. So the operator connects there through a keyed up file and retrieves all the CommuniShift dash something named groups and group members. Then it connects to the OpenShift API and ensures that all the data is synchronized. So it's one way sync from the Fast to the OpenShift API. Well, then we set it to reconcile every 20 minutes, so it's looping every 20 minutes. That can be changed if we need it later. Well, why did we go with the operator SDK? What advantages does create an operator offer? Well, several things. SDK is a framework that does a lot of things for us. All the structure, the loop logic, all the... When we run the operator SDK in it, it just provides us all the three of the files and the molecule tests, and we only set the reconcile period and also immediately we have access to any module that Ansible can run, including custom modules that we can write ourselves, which is what we did as part of the initiative. And it's also reusable. Once we created the CommuniShift authorization operator, we realized that we could reuse the solution for any other project, and that project emerged soon after. It was called Fast to Discourse. Fast to Discourse synchronizes the Fedora account system, group membership, the Fedora discussion, which is a discourse instance. I saw that Matthew Miller will have a talk about discourse after the lunch. And in the beginning of the Fast to Discourse, there was a ticket from Matthew who got inspired by David's solution of CommuniShift authorization operator to synchronize the fast groups and their members with the CommuniShift cluster. And he was thinking about using the same technical solution to sync fast groups with the discourse groups. And David will now describe the technical details. It's going to probably be a little bit of a repeat of what we already said. The Fast to Discourse operator, it's very similar to the CommuniShift authorization operator. We still have the Fedora account system. It's our single source of truth. It allows us to provide fine-grained access to various systems in the Fedora community. For example, as far as discourse is concerned, we can do things like members that are in a particular group that have particular privileges for posting in a certain area on discussion. And again, it's a one-way sync. So basically, from now on, if you want to add people to a particular area in discourse, you need to do a true noggin and basically IPA. And basically that's accounts.fedoraproject.org. You search for your particular group, you add or remove users there, and then this operator then will automatically synchronize the changes over. Don't do it the other way. Like if you make changes to discourse, it will be overwritten by the operator. And to activate this then, you activate it on a new group in discussion by basically creating the group. So if you create the group in discourse, the operator then will begin synchronizing it. Providing that the group exists in discourse and it's identically named to a group in FAS. And basically this approach then we've taken could be used for other services in the future. So on the last slide, it's a little demo. It just shows you, on the left you have the fedora account system FAS and here we're just adding a user to it. And in the background, sorry, on the right hand side then you can just see the... So this is the CommuniShift authorization operator. You can see that user then will be added to the particular group in OpenShift. So in the future, every project in CommuniShift will have its own group in FAS and basically the sponsors can decide in a self-service manner who gets access to it themselves. And it doesn't involve anything related to Fedora Infra. You don't have to open tickets, completely self-service. Yeah, so basically that's all in theory as we said because the CommuniShift cluster is not officially released perhaps in Flock 2024 or something. We'll be able to give a workshop on how to get access and get on board into CommuniShift. Yep, so just a quick lightning talk and just brief overview of what we did but if you're interested in digging deeper, there's a couple of resources there. I'm just thinking are they... Yeah, the links to the two operators if you want to look in. It's entirely Ansible and Python. It's pretty readable to most developers. That's pretty much all from us. So if you have any questions please feel free to ask but we've only got a 15 minute slot so we don't want to take up any time. Please enjoy the rest of Flock. So if you have any questions. I encourage anyone to look into the operator SDK and especially the Ansible operators that you can produce because you can pretty much access anything in the OpenShift API and it's a really nice framework. Potentially rather than creating or rolling your own API you could just use and extend OpenShifts or Kubernetes. And the operator SDK is a really nice way of doing it. So that's it. Thank you.