WEBVTT 00:00.000 --> 00:16.000 So, guys, now Mark, we'd present his topic about fine access, fine grain access control. 00:16.000 --> 00:19.000 Hi everyone, hello. 00:19.000 --> 00:25.000 My name is Mark, I'm a software engineer in the Lexsty team at Peronical. 00:26.000 --> 00:31.000 Today I'm going to talk about access management in Lexsty and in microcard as well. 00:31.000 --> 00:36.000 But before we get started, I'll just tell you a little bit about what Lexsty is. 00:36.000 --> 00:43.000 So, Lexsty is a hypervisor for containers and virtual machines. 00:43.000 --> 00:49.000 You can run it, it's quite easily just snap install Lexsty and then you can run your virtual machines. 00:50.000 --> 00:56.000 But it can also be clustered, you can use it for a home lab, for example. 00:56.000 --> 01:05.000 Or you can also deploy it as a very large data center on a server rack. 01:05.000 --> 01:12.000 And microcard is essentially a packaging of Lexsty with some other associated tooling. 01:12.000 --> 01:22.000 So, you can use oven or micro oven for software-defined networks and set for software-defined storage. 01:22.000 --> 01:36.000 And together, that comes together as a kind of multi-tented environment where you can have access control to manage different projects, different instances and so on. 01:36.000 --> 01:42.000 This is where we go through this talk, just trying to keep in mind this image. 01:42.000 --> 01:53.000 So, if you imagine Lexsty as sets of Raspberry Pi, so a small Raspberry Pi cluster, there's not really a lot of space to deploy in the extra services. 01:53.000 --> 01:59.000 So, you know, if you have micro oven, you have Lexsty, micro set, and you're putting your virtual machines on top of that. 01:59.000 --> 02:05.000 You don't really want to have a lot of bandwidth taken up by additional services. 02:05.000 --> 02:17.000 Now, we did have an existing method of authorization for users in next day. 02:17.000 --> 02:26.000 So, open-till before this open-fge work was implemented, authentication of the Lexsty was only with mutual CLS. 02:26.000 --> 02:38.000 And what we were doing was associating each user's certificate, their public certificate, with a particular project in next day. 02:38.000 --> 02:49.000 And as long as they were associated with that project, they could do anything inside that project, except for editing the project configuration itself. 02:49.000 --> 02:59.000 But it calls for that to improve the authorization process and improve the management and make this much more fine-grained. 02:59.000 --> 03:16.000 And so, to make this work, we look to open-fge. Open-fge is provides a framework in a set of modeling concepts, which makes it much more easy to reason about access control. 03:16.000 --> 03:21.000 And so, open-fge is a relationship based access control. 03:21.000 --> 03:31.000 And so, generally, you will model the relationships between different entities in your system in order to make a decision about, 03:31.000 --> 03:39.000 and, you know, this user X is user X able to perform action Y on resource, said. 03:39.000 --> 03:47.000 And so, with open-fge, we can ask the question, does user X have relation can exec with instance C1? 03:47.000 --> 03:55.000 So, in this case, we're asking the question, is someone able to get a shell, for example, inside that instance? 03:55.000 --> 04:07.000 And with open-fge is modeling language, you can have a direct association or a direct relation between the user, the instance, and the relation can exec. 04:07.000 --> 04:14.000 So, in open-fge is modeling system, it kind of looks a bit like this. 04:14.000 --> 04:23.000 They see, you have type identity, that's the user. You have type instance, and you have a set of relations, and then in the square brackets here, you have the identity. 04:23.000 --> 04:28.000 So, an identity can be directly related. 04:29.000 --> 04:35.000 That's good to an extent, but it's also going to be a bit of a headache to manage. 04:35.000 --> 04:45.000 For example, if you want to have some users where you want to give them access to all instances in a project, then you want to have some level of computer relations, 04:45.000 --> 04:57.000 and open-fge provides that as well. It's very nice. So, what you can do is define a relation between a project and an instance, 04:57.000 --> 05:04.000 and then you can inherit these relations down the chain. So, you can say, I have a project, that's related. 05:04.000 --> 05:16.000 I'm an instance, sorry, that's related to the project that sits for them, and then I might have can exec because I have can operate instances on the related project and so on. 05:16.000 --> 05:27.000 An open-fge server will compute all the different paths from which you're able to get these different relations. 05:27.000 --> 05:32.000 And that's great, but it's very complex. 05:32.000 --> 05:45.000 So, in order to be able to compute these different relations, you have to tell open-fge how these different entities in your system are related to each other. 05:46.000 --> 06:05.000 So, for example, you might say there's a project and that's has relation project to instance C1, and this is how open-fge is able to actually do these computer relations. 06:05.000 --> 06:14.000 But the problem that we had was that actually synchronizing all these relationships with the external open-fge server can actually get quite complicated, 06:14.000 --> 06:24.000 various situations where you might, for example, you go to create a network, you tell open-fge and create a network, or creating that network fails, 06:24.000 --> 06:31.000 and then you miss removing that talk or back from the open-fge database, and you can leave things hanging around. 06:31.000 --> 06:42.000 So, if essentially you've got an external cache of all the resources in your system, and that can get quite tricky to keep in the sink. 06:43.000 --> 06:55.000 Another thing was that open-fge requires a HHA Postgres to be, you know, for redundancy, and that's not something that we can really, 06:55.000 --> 07:00.000 feasibly deploy in our system of three or as repised. 07:01.000 --> 07:15.000 So, we need something that we can use in kind of airgaped environments or on a small system that would work for us, and we ended up using open-fge in quite an unconventional way. 07:15.000 --> 07:23.000 Open-fge itself is written in GoLand, and so is LexD, and so we were able to instantiate an open-fge server within LexD, 07:23.000 --> 07:30.000 and implement our own version of their Open-fge database store interface. 07:30.000 --> 07:36.000 And then data store interface is essentially just an interface that says, when I call this method, 07:36.000 --> 07:42.000 this is what these are the kinds of things that I want to return from the database. 07:42.000 --> 07:48.000 And so, ours just reads directly from decolite, decolite is our backing database for LexD. 07:48.000 --> 07:56.000 It's just SQLite, but distributed using the RAPD algorithm. 07:56.000 --> 08:05.000 So, just a couple of things about this Open-fge data store interface. 08:05.000 --> 08:12.000 There are two kind of primary methods that needed to be implemented. 08:12.000 --> 08:22.000 They really are called in different scenarios, or different methods that are called against the RAPD Open-fge server. 08:22.000 --> 08:31.000 One of them is called uncheck requests, where I'm checking does this identity specifically have this relation to this object. 08:31.000 --> 08:41.000 We have a method called Re-Use Set Supples, which basically says list all the Supples, where the user is a given type. 08:41.000 --> 08:47.000 And, yeah, related to a given object with a given relation. 08:47.000 --> 08:54.000 And, yeah, the next one, read starting from user, list all the Supples that are related to a given user. 08:54.000 --> 09:02.000 So, given a group, for example, what permissions does that group have. 09:02.000 --> 09:08.000 And so, to implement this, we had to add a couple of tables to LexD. 09:08.000 --> 09:11.000 One of them being the identity stable. 09:11.000 --> 09:20.000 So, every authenticated user in like Steve will go into the identity stable. 09:20.000 --> 09:23.000 For each identity, we have a list of groups. 09:23.000 --> 09:29.000 And for each group, we have a list of permissions. 09:29.000 --> 09:37.000 And, yeah, demo sign. 09:37.000 --> 09:56.000 So, I should have put my screen on duplicate, rather than present. 09:56.000 --> 10:11.000 Okay. 10:11.000 --> 10:22.000 Just give me one second. 10:26.000 --> 10:49.000 That's right. 10:49.000 --> 10:51.000 Okay. 10:51.000 --> 10:55.000 So, this is the LexD's user interface. 10:55.000 --> 10:59.000 Now, here, I'm able to view projects. 10:59.000 --> 11:03.000 I can create projects, for example. 11:03.000 --> 11:05.000 I can see whatever I like. 11:05.000 --> 11:12.000 And the reason for that is my identity here, me, is a certificate. 11:12.000 --> 11:19.000 And the groups that I'm a member of here, this one group and the group is admins. 11:19.000 --> 11:22.000 So, I go into groups. 11:22.000 --> 11:27.000 You can see that. 11:27.000 --> 11:31.000 In permissions, I have this server admin permission. 11:31.000 --> 11:35.000 So, I've just given myself full access to, actually, over the HTTPS API, 11:35.000 --> 11:40.000 but as if I was connecting over the unique socket. 11:40.000 --> 11:47.000 What I can do is now log in as. 11:47.000 --> 12:04.000 And now I just see user, so I'll just open a guest profile here. 12:04.000 --> 12:06.000 And we'll cancel that. 12:06.000 --> 12:16.000 And so, if I log in with SSO, 12:16.000 --> 12:24.000 let's give us. 12:24.000 --> 12:27.000 So, the first thing we can see, it just says project not found. 12:27.000 --> 12:31.000 And that's because when you first log in as an IDC user, 12:31.000 --> 12:34.000 you don't have any permissions in the system at all, 12:34.000 --> 12:39.000 because you're not related to any groups, so you're not a member of any groups. 12:39.000 --> 12:43.000 So, if we go back to our window where we're an administrator, 12:43.000 --> 12:48.000 and now going to identities, we can see that the IDC user is now present, 12:48.000 --> 12:51.000 so they've been saved in the database as a result of their login. 12:51.000 --> 12:56.000 And they're not a member of any groups. 12:56.000 --> 13:02.000 So, what I'll do is I'll create a group. 13:02.000 --> 13:08.000 I'm going to call it my group. 13:08.000 --> 13:21.000 I'm going to add my IDC identity to that group. 13:21.000 --> 13:25.000 And then I'll give it some permissions. 13:25.000 --> 13:37.000 So, the permissions I'm going to add to it are. 13:37.000 --> 13:46.000 So, I'm going to view on project default, so they'll be able to see the default project, 13:46.000 --> 13:50.000 but they won't be able to actually view any of the results that they're inside it. 13:50.000 --> 13:56.000 This is a very fine-grained entitlement, but it just means you can view the project and that's it. 13:56.000 --> 14:00.000 And then the next thing I'm going to do is, 14:01.000 --> 14:08.000 if the user role on instance normal. 14:08.000 --> 14:12.000 So, the user role is a built-in role that we created, 14:12.000 --> 14:20.000 and we've become and built-in roles because they're essentially defined by our OpenFGA model. 14:20.000 --> 14:23.000 Save. 14:23.000 --> 14:27.000 Okay, so the IDC user that's in the other window, 14:27.000 --> 14:40.000 is now a member of the group, my group, with those permissions. 14:40.000 --> 14:46.000 So, now should be able to see instance normal, great stuff. 14:46.000 --> 14:56.000 And then, if we go to configuration, name is normal, the description, let's try and edit the description. 14:56.000 --> 15:05.000 And I'm unable to update it as expected. 15:05.000 --> 15:08.000 However, I am able to get a thermal session. 15:08.000 --> 15:13.000 And so, that's the gist of how it works. 15:13.000 --> 15:16.000 Let's go back to our slides. 15:26.000 --> 15:41.000 So, just to recap why we did this. 15:41.000 --> 15:49.000 It was really the absolute requirement that we were able to deploy LXD on a set of Raspberry Pi's. 15:49.000 --> 15:54.000 I wouldn't necessarily recommend that you do this if you have a cloud deployment. 15:54.000 --> 15:57.000 You can use any variables of this to deploy Postgres. 15:57.000 --> 16:00.000 Find just use OpenFGA as necessary. 16:00.000 --> 16:04.000 But the pros are, where's out the box? 16:04.000 --> 16:08.000 No Postgres deployment necessary. 16:08.000 --> 16:15.000 Another great thing is, we don't really have to worry at all about synchronizing all the two pools for the system. 16:15.000 --> 16:18.000 And also, easier model migrations. 16:18.000 --> 16:22.000 So, model migrations in OpenFGA can get quite complicated. 16:22.000 --> 16:28.000 Generally, you will have to create a new store with a new model. 16:28.000 --> 16:32.000 And then you would, my great deal of it. 16:32.000 --> 16:33.000 There's it over. 16:33.000 --> 16:36.000 Or in the same store, you can add a new model. 16:36.000 --> 16:39.000 And you'd have to have a kind of intermediary model, 16:39.000 --> 16:42.000 while you migrate all these changes. 16:42.000 --> 16:51.000 But in our case, all we need to do is, essentially, just use the existing system of database migrations that we already have. 16:51.000 --> 16:54.000 Or patches. 16:54.000 --> 17:00.000 The cons are complexity, implementing the OpenFGA data store, and all the various different SQL queries. 17:00.000 --> 17:05.000 In order to query the deeper like that, this was quite complex. 17:05.000 --> 17:11.000 Additionally, you know, storing user information. 17:11.000 --> 17:16.000 Like, in order to be able to manage users in this way, we do have to store the email address, 17:16.000 --> 17:20.000 which is an additional place for, for example, 17:20.000 --> 17:25.000 GDR, GDR compliance for where to delete it. 17:25.000 --> 17:33.000 Yes, the OpenFGA data store in the first tends to get updated fairly regularly by the OpenFGA address. 17:33.000 --> 17:34.000 And that's nothing on them. 17:34.000 --> 17:37.000 They didn't intend for this to be used as a public API. 17:37.000 --> 17:39.000 Although they did expose it. 17:39.000 --> 17:41.000 And they're cool with it. 17:41.000 --> 17:42.000 We've had a meeting with them. 17:42.000 --> 17:45.000 Their communities is really lovely. 17:46.000 --> 17:54.000 And then also, just generally, this is much slower than the existing authorization mechanism that we had, 17:54.000 --> 17:56.000 because that one was fully cached. 17:56.000 --> 17:59.000 This one does have to call out to the database. 17:59.000 --> 18:07.000 And generally, OpenFGA is, they've optimized the database scheme or in such a way 18:07.000 --> 18:11.000 where these calls are at terrific, like tremendously fast, 18:11.000 --> 18:14.000 whereas we don't have the luxury of being able to do that. 18:14.000 --> 18:18.000 And so we have a few things to do to speed this up. 18:18.000 --> 18:23.000 It's already quite fast actually, we've done some work on caching to improve the speed. 18:23.000 --> 18:27.000 But, yeah, thank you very much. 18:28.000 --> 18:29.000 Thank you. 18:35.000 --> 18:36.000 Any questions? 18:39.000 --> 18:40.000 Nope.