 Hello, good morning. I'm Irene Diaz, a software engineer at Red Hat. And this is my colleague, Sarita. Hello, everyone. Good morning. And thank you for getting up early in the morning to come for our presentation. And today, we are going to talk about two onboarding options, that one with ignition and other being FDO, and other being ignition for IoT devices. So this is today's agenda. We are going to discuss what is onboarding in broad terms. Then we are going to present to you what are the options that Fedora IoT has for onboarding, as well as future steps on what is coming up for Fedora. So what is device onboarding? What do we care and so on? So device onboarding happens after we make an image, provision it, and then we have to give the devices all the configurations and secrets that they need in order to perform its final need. During this onboarding process, we also hope to get a connection from the device to the final IoT platform. The platform is what the device needs in order to get updates and some other software and so on. This whole process, of course, needs to be secure in its steps. And there shouldn't be a need for human intervention, so the whole process would be hands off. So if you can imagine, if we are trying to onboard a thousand devices in the middle of a mountain, an engineer cannot be bothered to go to the onboarding side. We simply need someone to ship the devices over there, power them on and everything else would be automatic, secure, and no need for human intervention. Fedora has two different options in order to do this, so Salida is going to give an overview about them. Yes, so let's get a brief introduction to these two options. What is FDO? It's basically FIDO device onboarding protocol. It's an open industry standard protocol developed by FIDO Alliance. FIDO Alliance is basically formed by a couple of tech-leading companies, such as Intel, Google, and many to name. A little bit of history to FDO. FDO was initially known as SDO, which is the secure device onboarding developed by Intel. Later, it was contributed to FIDO Alliance to become FDO with the announcements. Whereas Ignition, it's a part of Koro's ecosystem, which is internally developed by In-House and Red High, and maintained by a group called Koro's working group. The basic difference between the two options, I think it's in their infrastructure because of the distributed nature of FDO, it requires a proper complex infrastructure, maybe a server-side and the client-side implementations, which we will see in details later. Comparatively, I would say Ignition has a simpler infrastructure, which basically revolves around one configuration file. Although this configuration file, it can be linked to other configuration files, which will be merged at the runtime. That's the basic difference, but we'll see the more details as we go ahead. So how do FDO and Ignition fit with Fedora IoT? So in order to make a Fedora IoT image, you would be using Image Builder. There have been previous talks in this conference about what is Osbley Composer, Image Builder, and so on, so if you haven't seen them, I would recommend you to check those other talks. So you would use a blueprint in order to make a Fedora IoT simplified installer or a raw image, then use Image Builder to produce that image. And then, once the image has been provisioned, you would use either FDO or Ignition, probably both at the same time, and at first boot, the devices would be onboarded. And Serita is going to explain a little bit more about Ignition, about FDO. So let's see some of the key features of FDO. The whole idea of FDO, it works around providing maximum security during the end-to-end onboarding process. So of course, the first thing comes is no manual intervention, there comes a zero touch, where are the maximum possibilities that security threats can be there. FDO works by the principle of establishing a chain of trust. To explain this a little bit more, I would like to go to the next slide, where we have the whole, this is the FDO protocol, which is going to tell us about in a bit, about the flow and how it works. But a few of the concepts to explain the chain of trust. So FDO can be seen or divided into two phases. One happens at the device manufacturing site, and the other, it happens at the onboarding site. So at these two phases, they can be in different timelines. So there has to be security in terms of its ownership, which is provided at each step. The ownership of the device, it can change during the whole time, a number of times. So apart from this, one of the features that's most spoken about FDO is lead binding, which solves a lot of problems related to onboarding in the industry. So what is lead binding is, so when the device is manufactured, device does not know that which platform it is going to get onboarded, or the configuration that it is going to onboard it with. This can be decided at later stages when the device actually goes to the onsite and that's when this feature allows flexibility in terms of device management, which is very useful. And yeah, that's the feature. And apart from this, FDO has other features such as reliability in terms of, if there are a number of devices, every time FDO works, it works the same way for all the devices. And even though the protocol is pretty complex for the end user, it's very simple to use. Even a simple worker can power on the device at the onboarding site and doesn't need to know what happens inside. It is platform independent and cost saving, I would say. I mean, the infrastructure does take, is expensive since it's complex and it has hardware software requirements, but it's a one-time job and it saves a lot of manual processes and even simplifies the errors that could possibly happen when a traditional manual onboarding is there. So yeah. So now FDO, in a little more detail, Sarita said there are two places where the hold onboarding process happens. On the left side of this slide, you see the device initialization part which happens at the manufacturing site and then we have the on-site onboarding part. So during device initialization, there are two entities that are important. First of all, the device and then the manufacturing server. The device would contact the manufacturing server in order to get a good ID and two different, I guess, documents would be generated. One are the device credentials will be hosted in the device and those device credentials tell the device where it would find the rendezvous server later on in the process, which is on the onboarding site. The manufacturing server would get an ownership voucher. This ownership voucher is a cryptographic document and using that document, which is a 509X certificate, the FDO protocol allows you to verify that you are the owner of the device at the current point in time. So in this point in time, the owner of the device is the manufacturing server. The onboarding is still going on, so the device would be moved to the onboarding site and meanwhile, the manufacturing server would transfer this ownership voucher to the owner onboarding server. So that right now, at this point in time, the owner of the device would be the owner onboarding server. As you can see in these lights, the communication starts, I mean, the device contacts the manufacturing server. That is what the arrow means, but the connections are uncertain and so on. So the device reaches the final point and then the owner onboarding server would transfer this ownership voucher to the Rendezvous server and in the Rendezvous server, we would have a mapping from a device UID to an IP and that IP is what the device will let it on use to contact the owner. So the device finally reaches its final step and it would use the device credentials in order to find where its Rendezvous server is. So it would contact the Rendezvous server, the Rendezvous server would check if that guy UID makes sense to him and if so, it would tell the device where its owner is. Then the device will contact the owner, they would establish a chain of trust based on the keys that the device has in its device credentials and the keys that the owner has in the ownership voucher. The owner would transfer some keys to the service info API server and the device would then contact the service info API server in order to do these final onboarding steps which is where the device would get all the configurations and keys that it needs in order to work. So how does it fit with the, you know, how does, I mean, how do we do this? So as we said before, in order to build the Federal IoT image you would need a blueprint. In order to use FDO, you need a simplified installer blueprint and the only thing that you need to add to this configuration apart from any other configuration that you might need is customization.fdo, I guess, part where you would place what is the URL to your manufacturing servers because as we said before, the only thing that the device needs is just an IP to get to the manufacturing server and everything else would be automatic from that point on. So we would use Image Builder. If you're using the command line you would run Composer CLI, Compose Start Over Tree and then the name of your blueprint which is a Tommel file. Then you would select the type of image that you need, any other further parameters. Since Fedora IoT is an OSC based operating system which means that it has a immutable file system, you would need a commit in order to fetch the file system and so on, so you would use that and then the Image Builder would speed Federal IoT Simplified Installer Image, which is an ISO. You would provision the device, it would boot and the whole process that we saw in the previous slide would happen and the device would know what to do and so on. So, but I mean, we are onboarding the device. How do I get the configuration and so on? The FDO standard has a normative part which are the service info modules. Its service info module is a configuration, I guess, module where you can put some atomic instructions and it works with a key value protocol. So in this slide, you can see that we have a couple of configuration things. This is a YAML file. So we can, for instance, establish an initial user. As you see there, I'm creating a user and giving it a password and some SSH keys. We can also move, I mean, copy files from the service info API server to the final device. We can run some commands. We can establish this encryption in a given this level and we can also specify if we want that the device wants to be rebooted after the onboarding process has happened or not. You have an URL over there where you can see which are the F-SIMs that the FDO Alliance is working on. Red Hat has a couple which haven't been published there but we are working towards making them part of the standard. And if you are interested, you can go to Federal IoT, FIDO, then by support RS because our implementation is in Rust in order to contribute or find any more information. And now with Ignition. So let's see some of the features that, what is Ignition, what it can do and how does it work. Ignition can be described as the first boot configuration tool, although it can be used for provisioning purposes. It basically runs in the NITRA-MFS at the first boot. The things that you can do with Ignition involves things such as configuring users, disk manipulations which you can create partitions and enabling the system deservices. All of these features, they are supported by CoreOS but Federal IoT only supports a part of Ignition. So not all the features that you can do with Federal IoT will see in details what Federal IoT can perform to. And Ignition's configuration file, basically it's JSON document which can be embedded inside the ISO or it can be kept at a remote location where it can be fetched during the onboarding process. Ignition follows a declarative pattern. That means Ignition knows what stage it is going to be rather than how to do those things. So for example, if it's going to get some disk manipulations done, it knows that it has to partition the disk or what to do, but the how to do part, it gets it done by the OS, underline OS tools and utilities. So Ignition doesn't have to worry about how to do part. The nature of Ignition, it promotes immutable infrastructure, meaning that the configurations once provisioned or after the first boot cannot be changed. If user needs to do some changes in the configuration, reprovisioning has to be done. This part is a bit expensive in terms of reprovisioning compared to FDO, if after updating configurations at runtime, new configurations can also be applied. There is no need of reprovisioning the device. Also the automatic configurations are deleted once successful provisioning is done from the VM data which is useful because the sensitive information is not accessible once the device is provisioned. It does support STTPS and config verification that's a useful tool too. So how would you configure Ignition in order for a device to be onboarded? As Alita said, you simply need a JSON configuration file. The current version is free for zero. And as we said before, in Fiber IoT, we don't support all the features that Ignition has. In our case, we enable file links and directories creation. We also can create system units, users and groups, as well as the other Ignition metadata configurations, such as retrieving a remote file and so on. As you see there is a JSON file and this might cause a problem because as you know, JSON files are not human friendly. So in order to avoid using JSON files, you have butane. So butane is a source to, is a transpiler which is a source to source compiler. Butane would take a butane configuration file written in YAML which is more human friendly and then you would use the butane transpiler in order to get the JSON configuration file. And why would we, I mean, why would we do that? Because while we are transpiling one configuration file to another, we would get any, I mean, we would get warnings if there are any errors. And we also check based on the variant that we are defining over there. I don't know if you can see it, but we are using the RedForge variant. If the options that we are given to the butane configuration file are supported by the variant that we want. And yeah, currently the RedForge variant is on version 110. And we are targeting Ignition 330. Yeah, so some examples. If everything goes well, you would run Ignition as shown in the first example. And butane would speed a JSON Ignition configuration file. In something goes wrong. For instance, in the second example, I forgot to establish an install section in the unit. So butane would tell me, hey, we've got an error there. And if I'm using something that is not supported altogether in the bottom sample, you would see that butane would simply give an error saying that, hey, the file system configurations are not enabled for this variant that you are using. So how would you use butane in order to onboard that device? You have two different options. As I said before, you can either copy the whole JSON file into a section in the image builder blueprint. But instead of using JSON, you would have to transform it to base 64. And then if you want to do that, you would only have the option to use, I mean, to produce a simplified installer. So you would simply call Composer CLI, choose the image type that you want. For instance, the IoT simplified installer in this case. And then you would get the image. The other options that you have is to specify, as I said before, a remote URL with the ignition configuration file with effects at first vote. So if you choose to do that, you can either produce a simplified installer, which is an ISO or a raw image, which is a, yeah, compressed raw image. In the case of the raw image, you would run the command that is there and then you would have the image. In both cases, you would have to provision the device and then at first vote, yeah, ignition would work and the device would get onboarded. So after seeing FDO and ignition, you must be wondering which one to go for, which is the option. But to be honest, it's not the one-to-one comparison. It's rather two options that you can choose based on the project requirements. What security features are to be used in the project and, of course, the infrastructure. We are based on the differences between the two options. So it's up to the requirements of the project. And yes, the combination of the both can also be used together. For example, some of the features or some of the things that you can do with FDO and ignition or you can create the user part or disk manipulation or others that can be kept for ignition and the rest of the protocol stays with FDO. So some of the future enhancements that are coming with FDO, one of them being the service info per device feature. So what's this? Irina earlier explained about the service info modules that we have for FDO. Currently, what happens is all the devices get onboarded with the same configuration file. That's, we call it the base of the default configuration. But with this feature, it will be possible for the user to onboard different devices with different settings if they want service-specific configuration. For example, for SSH key, we have started with that. And if the user doesn't want the device-specific one, it still has the option to get onboarded with the default ones. Another thing is that we are trying to move to database storage. Currently, what we have is all the files, configuration file, which is ownership vouchers and the other configuration files are being stored at the file system, which is really not feasible when considering a number of devices. So database will be a good option. We are working on that. One of the things that we are trying to do is moving from VARP to AXEM. VARP is a web framework that we use in FDO. But it does not comply to FIPS. FIPS is basically a cryptographic standard that we use. And VARP internally uses trust DLS, which uses string that ring rate does not comply with FIPS. So we are moving to AXEM. And we are missing a bit on the left side of the slides, but forget us. This is related to the future of Ignition. So Ignition is developed by the CoreOS team. As you saw, we don't support everything that Ignition does. So we are working towards enabling a file system customizations after, I mean, during the onboarding process, because right now you would do that in the image building process. And we have aesthetic partition tables, so you cannot change that unless you change the code in OSB Composer. So yeah, all that you have been seeing right now, it will be coming for Fedora 38 as soon as we get back from this conference. That is the soonest part. Yeah, but it would definitely be for Fedora 39. Yeah, that's all. And we'll have to take your questions now if you want. That's all. Thank you. Oh, yeah. So we've been asked, where can we get those documentation or information? So, where? So, but I think that he's asking, where would I configure this? Am I right? Okay, we do have our documentation in the link that I showed you in the next slide. There is a file which is called the how to. You have examples over there in order to know how to configure this. And if you are interested in how the protocol works for our specific FDO F-SIMS because some of them are not part of the standard. Under the same repo, there is a docs folder where you have docs F-SIMS and you have the specification over there. If you are looking for the F-SIMS that are going to be part of the standard, which are the ones about the file copying, the commands and some other one that I'm forgetting about, those things are in the FIDO Alliance F-SIM repo in GitHub. Does that dance? Yes, yes, each F-SIM has a set of configuration things that you need to configure. It's not the same to create an user to create a file. So, for users you have, can I set a password? Can I set a SSH key? Whereas with files you have the options to set permissions and yeah, that is the difference. Each F-SIM has its own configuration parameters and so on. Okay, another one. So, we've been asked whether we... For ignition. Yeah, so... Let me check if I understood. You are asking whether we have thought about signing the ignition configuration file so that we know that the device would get the configuration file that it needs. We haven't thought about it to the best of my knowledge. So, we'll take up that with the team and with the CoreOS... Yeah, and we'll tell you when we have the opportunity. Are we good? Thank you. Thank you.